Component Royalties

Overview

Component Royalties allow Scrypto blueprint authors to earn fees whenever their deployed components are used. This is enforced at the Radix Engine level — not by application logic — creating a sustainable business model for open-source DeFi developers.

Authors set per-method royalty amounts in XRD. When a transaction manifest 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. 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 guide.

Denomination and Collection

A royalty is always charged in XRD as part of the transaction fee, but the author may specify the amount either as a fixed quantity of XRD or as an approximate USD-equivalent, in which case a network constant converts it to XRD at charge time. Because collection is enforced by the 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. 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.