Skip to content

Amendments

Jump to bottom
Elliot. edited this page Aug 20, 2025 · 2 revisions

When running your own rippled node, there are some configuration options relating to amendments.

You can query a public server, such as s1.ripple.com, to see what the current state of the network is.

As an individual node, you don't have control over the network's enabled amendments. The enabled amendments are determined by votes from trusted validators (i.e., those on UNLs). Enabled Amendments are a property of the network, not a node. Any active amendment is always active across the entire network. You just need to run code the understands (has code for) the active amendments; otherwise your node will report that it's amendment blocked.

In other words, node operators do not enable amendments. Validators do - by proposing EnableAmendment pseudo transactions. Tx submission nodes are separate from validators.

If your node's purpose is to submit transactions to Mainnet, then there is no need for the [features] or [amendments] sections in rippled.cfg.

Typically, there is no need for rpc_startup either.

[features] and [amendments]

These sections can be useful when running independent test networks or using standalone mode. These are important for testing and debugging.

What are "Obsolete" amendments?

"Obsolete" amendments have had their conditional code removed. In some cases (like "Escrow"), this means the amendment is permanently enabled (and cannot be vetoed). In the "feature" API response, "enabled": false is misleading; the amendment could actually be permanently enabled, but retired. In other words, the code is always-on because the pre-amendment code has been retired.

Considerations when developing amendments

  1. Does this change affect transaction processing?
  2. Does this change affect ledger objects?
  3. Does this change affect anything else about the binary format and hash of the ledger?
  • Remember, the only way to change the ledger is with a transaction (including pseudo-transactions)
  1. Does this change affect which transactions get into the consensus set?
  2. What should be invariants for the ledger entries?
  3. How much computation does the transaction consume?
  4. How much data space does the transaction use?
  • Based on the above, what should the fee for the new/modified transaction(s) be?
  1. Does any transaction involve transferring funds from one party to another?
  • Consider Deposit Auth
  1. Should any transaction be disallowed from inclusion in a Batch transaction?
  • Currently, only Batch transactions are disallowed, so you can't nest them
  1. Should any transaction be excluded from account permissions delegation?
  • Currently, AccountSet, SetRegularKey, SignerListSet, and AccountDelete are excluded
Clone this wiki locally