RADIX WikiRADIX Wiki

Introduction

Every transaction on Radix pays a fee in XRD, and every manifest you write has to say where that XRD comes from. That is what the lock_fee call at the top of most manifests is doing. Two things about the Radix model differ from what you may expect coming from an EVM chain, and both change how you design a dApp.

First, the fee is not attached to the signer. XRD is held in vaults owned by components, so a fee is paid by whichever component locks it — which may be the user's Smart Account, your dApp's component, or both. Second, the total fee is not a single gas number: it is a network cost, an optional user tip, and any royalties the code you called charges, each with different destinations.

What Makes Up a Fee

The fee model prices each transaction in three parts:

  • Network fee — the cost of executing and storing the transaction. The system applies a fee table that assigns cost units to each operation, sums them, and multiplies by a fiat value multiplier to reach an XRD amount. The multiplier exists so that fees stay roughly stable in fiat terms as the XRD price moves; changing either the table or the multiplier requires a coordinated protocol update.
  • Tip — an optional percentage the submitter adds when demand exceeds capacity. It amplifies only the network portion, never royalties, and goes straight to the validator leading the round.
  • Royalties — amounts set by a package publisher or component instantiator, charged whenever a transaction calls that code. Royalties are part of the fee the user pays, but they are not burnt or shared with validators; see Events, Metadata, and Royalties for how to configure them.

Because royalties are counted inside the fee, a transaction that touches an expensive component costs more than an identical transaction that does not — and the user sees the total before signing, in the wallet's transaction summary.

Locking a Fee

A transaction pays from a fee reserve, which is established by calling lock_fee on a component that owns an XRD vault. In practice this is the first instruction in most manifests:

CALL_METHOD
  Address("account_rdx...")
  "lock_fee"
  Decimal("5")
;

The amount is a ceiling, not a charge. Whatever the transaction does not spend is returned to the vault it was locked from. Locking too little is the failure mode to guard against: if the reserve runs dry mid-execution the transaction fails, and the fees already consumed are not refunded.

Multiple Payers

More than one vault can lock a fee in the same transaction, and later locks are used preferentially. That is what makes fee sponsorship straightforward on Radix: a dApp component can lock part or all of the fee so the user does not need XRD to interact with it, and a profit-taking application can chip in a share of each trade. Nothing about this requires a meta-transaction relayer — it is a normal manifest instruction.

The Bootstrap Loan

The instructions that run before the first lock_fee still cost something. The network covers them with a small automatic loan of cost units, which must be repaid the moment the reserve is established. A transaction that burns through the loan without locking enough is rejected outright and leaves no ledger record. One that repays the loan and then fails is committed as failed: the state changes roll back, but the fees spent up to the failure are kept.

Where Fees Go

Spent fees are split by type:

  • Base network fee — 50% is burnt. Of the remaining half, 25% goes directly to the validator that led the round and 75% joins a pool shared across the validator set at the end of the epoch, weighted by participation and reduced for missed proposals, in the same shape as network emissions.
  • Tips — paid immediately and entirely to the round leader.
  • Royalties — deposited into a system-generated vault owned by the component (or, for package royalties, by the package). The instantiator or deployer claims them with a badge the system creates automatically at instantiation or deployment.

The burn is why fee revenue is deflationary for XRD supply, and the epoch pool is why validator income tracks participation rather than luck of the round.

Practical Guidance

  • Lock generously. The unspent portion comes back, so a reserve that is too high costs nothing and a reserve that is too low burns fees for a failed transaction.
  • Estimate before you submit. Preview the transaction through the Gateway API to get a fee estimate rather than guessing, especially for manifests whose cost varies with input size.
  • Sponsor deliberately. If your component locks the fee, anyone who can call it can spend your XRD — gate the sponsoring method with a badge or a business rule, not just goodwill.
  • Price royalties as user cost. A royalty is invisible in your own testing but appears in every user's fee summary.

Next Steps

  • Radix Engine Toolkit — build and sign transactions from your own code, with no wallet in the loop