---
title: "Component Royalties"
path: "/contents/tech/core-concepts/component-royalties"
version: "1.3.0"
author: "Hydrate"
createdAt: "2026-02-18T22:38:09.732Z"
updatedAt: "2026-07-22T07:09:32.274Z"
---

# Component Royalties

<Infobox>
| **Mechanism** | Per-method royalty fees set by blueprint authors |
| **Enforced By** | [Radix Engine](/contents/tech/core-protocols/radix-engine) |
| **Currency** | XRD |
</Infobox>

## Overview

**Component Royalties** allow [Scrypto](/contents/tech/core-protocols/scrypto-programming-language) blueprint authors to earn fees whenever their deployed components are used. This is enforced at the [Radix Engine](/contents/tech/core-protocols/radix-engine) level — not by application logic — creating a sustainable business model for open-source [DeFi](https://en.wikipedia.org/wiki/Decentralized_finance) developers.

Authors set per-method royalty amounts in XRD. When a [transaction manifest](/contents/tech/core-protocols/transaction-manifests) calls a royalty-bearing method, the fee is automatically collected. This solves the open-source sustainability problem: developers can share their code openly while earning from its usage.

## Package vs. Component Royalties

Radix supports royalties at two levels, both declared in [Scrypto](/contents/tech/core-protocols/scrypto-programming-language). **Package royalties** are defined inside a blueprint with the `enable_package_royalties!` macro and are fixed for every component instantiated from that blueprint. **Component royalties** are configured per instance at instantiation with `enable_component_royalties!`, letting the owner set — and later change — the fee on individual methods. Both are documented in the Radix [Using Royalties](https://docs.radixdlt.com/docs/using-royalties) guide.

## Denomination and Collection

A royalty is always *charged* in [XRD](/contents/tech/core-protocols/xrd-token) as part of the [transaction fee](https://docs.radixdlt.com/docs/transaction-costing), but the author may specify the amount either as a fixed quantity of XRD or as an [approximate USD-equivalent](https://docs.radixdlt.com/docs/using-royalties), in which case a network constant converts it to XRD at charge time. Because collection is enforced by the [Radix Engine](/contents/tech/core-protocols/radix-engine) rather than application logic, it cannot be bypassed by the calling transaction — the fee accrues automatically into the component's royalty vault.

## Claiming and Access Control

Accumulated royalties are held by the protocol until the owner claims them, gated by dedicated roles — `royalty_setter`, `royalty_locker`, and `royalty_claimer` — that map onto Radix's native [badge-based authorization](/contents/tech/core-concepts/asset-oriented-programming). An owner can also *lock* a royalty so it can never be raised again, giving downstream builders a credible guarantee about the long-term cost of composing with a component. Together these turn open-source publication into a first-class, on-ledger business model for DeFi developers.