Special costs and fee voting
4 minDifficulty Checked 2026-11-10- Some transactions cost more: multi-signed ones, account deletion and creating an AMM.
- Validators vote on three numbers: the reference fee, the base reserve and the owner reserve.
- The network adopts the median of trusted validators' votes.
Most transactions cost the same 10 drops. A few cost more because they ask more of the network.
- A transaction signed by several keys costs more for each extra signature.
- Deleting an account costs 200,000 drops, which is 0.2 XRP.
- Creating an AMM pool costs the same 200,000 drops.
One costs nothing. If the key you use every day is stolen, you can replace it once with your master key for free. That works even when the thief has drained the account.
Who decides that the base cost is 10 drops and the reserve is 1 XRP? Not a company. The validators vote.
Each validator operator sets three numbers they prefer: the base fee, the base reserve and the owner reserve. About every 15 minutes the validators share their preferences. The network settles on the middle value, the median. One extreme vote does not decide the outcome.
The votes are a balancing act. The fee protects servers from being flooded with transactions. The reserves protect them from storing junk forever. Set them too low and spam gets cheap. Set them too high and ordinary people are priced out. Operators are advised to change reserves cautiously, because raising them later can leave some accounts short.
Fees are burned. Reserves are not. A reserve is XRP that stays in your account, locked. See Accounts and reserves.
Special transaction costs, before load scaling, with a 10 drop reference cost:
| Transaction | Cost |
|---|---|
| Reference transaction (most types) | 10 drops |
Key reset (SetRegularKey, conditions below) | 0 |
| Multi-signed | 10 drops × (1 + number of signatures) |
EscrowFinish with a fulfillment | 10 drops × (33 + fulfillment bytes ÷ 16) |
AccountDelete | 200,000 drops |
AMMCreate | 200,000 drops |
Batch | 10 drops × (2 + signatures) + the inner transactions' fees |
Key reset. A SetRegularKey signed by the master key pair can pay a Fee of 0 while the account's lsfPasswordSpent flag is off. Sending it turns the flag on. The flag clears when the account next receives a Payment of XRP.
Fee voting. Validator operators set preferences in the [voting] stanza of xrpld.cfg.
| Parameter | Controls | Recommended |
|---|---|---|
reference_fee | Reference transaction cost | 10 drops |
account_reserve | Base reserve | 1000000 drops (1 XRP) |
owner_reserve | Owner reserve per object | 200000 drops (0.2 XRP) |
The cycle. Every 256th ledger is a flag ledger, about every 15 minutes.
- Flag ledger − 1: validators whose preferences differ from the current settings send votes with their validations.
- Flag ledger: validators tally the votes of the validators they trust.
- Flag ledger + 1: validators insert a
SetFeepseudo-transaction into their proposals. - Flag ledger + 2: new settings apply if
SetFeereached consensus.
Each validator takes the median vote of its UNL for each setting. If the median falls between two votes, it picks the one closer to the current value.
Where the values live. The FeeSettings ledger entry holds the current settings. server_info reports them as base_fee_xrp, reserve_base_xrp and reserve_inc_xrp under validated_ledger.
Why the caution. The reference cost protects CPU and bandwidth, since every server processes and relays every transaction. Reserves protect RAM and disk, since every server keeps the full current state. Lowering reserves frees locked XRP. Raising them can leave some accounts unable to send many transaction types.
Related: Consensus, validators and the UNL, How amendments happen.
- Transaction CostRead 2026-11-10
- Fee VotingRead 2026-11-10
- Fees (Disambiguation)Read 2026-11-10
