Xahau Network
Testnet FaucetExplorerHooks API Docs
Xahau Network
Xahau Network
  • 🪝Xahau Documentation
    • XRPL/Xahau: What is Different?
  • 🪝Hooks
  • 🚨Concepts
    • Introduction
      • Example Usage
      • Xahau Testnet
      • Xahau Testnet Explorer
      • Examples (source code)
      • Blogs (concepts)
    • Terminology
    • Loops and Guarding
    • Compiling Hooks
    • Chaining
    • Weak and Strong
    • Collect Call
    • SetHook Transaction
    • Parameters
    • Namespaces
    • Grants
    • HookOn Field
    • Reference Counted Hook Definitions
    • Hook Fees
    • Execution Metadata
    • Debugging Hooks
    • State Management
    • Slots and Keylets
    • Floating Point Numbers (XFL)
    • Emitted Transactions
    • Serialized Objects
  • Features
    • Public Nodes (RPC)
    • Amendments
    • Transaction Signing
      • Transaction Fees
    • Developer Tooling
      • Curated Tooling
      • Client Libraries
      • Developer Tricks
    • HTTP / WebSocket APIs
      • Request Formatting Guide
      • Response Formatting Guide
      • Considerations
      • Public API Methods
      • Admin API Methods
    • Network Features
      • Account Managment
      • Balance Rewards
      • Check
      • Escrow
      • Hooks
      • Offer
      • Payments
      • URIToken
    • Faucet & Explorers
    • Data API's
  • Infrastructure
    • Node Requirements
    • Running a Node
      • Running a Mainnet Node
      • Running a Testnet Node
    • Building Xahau (Dev)
      • Ubuntu - 22.04
      • Mac OS - 15.3.2 (24D81)
  • Technical
    • 📐Hooks Functions
      • Overview
        • Hook API Conventions
        • Return Codes
      • Developer Defined
        • hook
        • cbak / Callback
      • Control
        • accept
        • rollback
      • Utilities
        • util_raddr
        • util_accid
        • util_verify
        • util_sha512h
        • util_keylet
      • Serialization
        • sto_subfield
        • sto_to_json
        • sto_from_json
        • sto_subarray
        • sto_emplace
        • sto_erase
        • sto_validate
      • Emitted Transaction
        • etxn_burden
        • etxn_details
        • etxn_fee_base
        • etxn_nonce
        • etxn_reserve
        • etxn_generation
        • prepare
        • emit
      • Float
        • float_set
        • float_multiply
        • float_mulratio
        • float_negate
        • float_compare
        • float_sum
        • float_sto
        • float_sto_set
        • float_invert
        • float_divide
        • float_one
        • float_exponent
        • float_mantissa
        • float_sign
        • float_int
        • float_root
        • float_log
      • Ledger
        • fee_base
        • ledger_seq
        • ledger_last_hash
        • ledger_last_time
        • ledger_nonce
        • ledger_keylet
      • Hook Context
        • hook_account
        • hook_hash
        • hook_param
        • hook_param_set
        • hook_skip
        • hook_pos
        • hook_again
      • Slot
        • slot
        • slot_clear
        • slot_count
        • slot_set
        • slot_size
        • slot_subarray
        • slot_subfield
        • slot_type
        • xpop_slot
        • slot_float
      • State
        • state
        • state_set
        • state_foreign
        • state_foreign_set
      • Trace (Debug)
        • trace
        • trace_num
        • trace_float
      • Originating Transaction
        • otxn_burden
        • otxn_field
        • otxn_generation
        • otxn_id
        • otxn_type
        • otxn_slot
        • otxn_param
        • otxn_json
        • meta_slot
      • Websocket APIs
        • account_info
        • account_namespace
    • Protocol Reference
      • Transactions
        • Transaction Common Fields
        • Transaction Types
          • AccountDelete
          • AccountSet
          • CheckCancel
          • CheckCash
          • CheckCreate
          • ClaimReward
          • DepositPreauth
          • EscrowCancel
          • EscrowCreate
          • EscrowFinish
          • GenesisMint - (Emitted Txn)
          • Import
          • Invoke
          • OfferCancel
          • OfferCreate
          • Payment
          • PaymentChannelClaim
          • PaymentChannelCreate
          • PaymentChannelFund
          • Remit
          • SetHook
          • SetRegularKey
          • SignerListSet
          • TicketCreate
          • TrustSet
          • URITokenBurn
          • URITokenBuy
          • URITokenCancelSellOffer
          • URITokenCreateSellOffer
          • URITokenMint
        • Pseudo Transaction Types
          • EmitFailure
          • UNLReport
          • UNLModify
          • SetFee
          • EnableAmendment
        • Transaction Results
          • TES Codes
          • TER Codes
          • TEM Codes
          • TEL Codes
          • TEF Codes
          • TEC Codes
        • Transaction Metadata
      • Ledger Data
        • Ledger Objects Types
          • AccountRoot
          • Amendments
          • Check
          • Deposit Pre Auth
          • Directory Node
          • Emitted Txn
          • Escrow
          • Fee Settings
          • Hook
          • Hook Definition
          • Hook State
          • Import VL Sequence
          • Ledger Hashes
          • Negative UNL
          • Offer
          • Pay Channel
          • Ripple State
          • Signers List
          • Ticket
          • UNL Report
          • URIToken
        • Ledger Header
        • Ledger Object IDs
      • Data Types
        • Currency Formats
        • Base 58 Encodings
      • Binary Format
    • Balance Adjustments
    • Governance Game
    • Burn 2 Mint (B2M)
    • Versioning Process
  • Compliance
    • Security Audits
      • Responsible Disclosure
  • Support
    • Help Us
Powered by GitBook
On this page
  • Amendment Process
  • Amendment Voting
  • Amendment Blocked Servers
  • Retiring Amendments

Was this helpful?

Edit on GitHub
Export as PDF
  1. Features

Amendments

Amendments represent new features or other changes to transaction processing.

The amendment system uses the consensus process to approve any changes that affect transaction processing on Xahau. Fully-functional, transaction process changes are introduced as amendments; validators then vote on these changes. If an amendment receives more than 80% support for five days, the amendment passes and the change applies permanently to all subsequent ledger versions. Disabling a passed amendment requires a new amendment to do so.

Note: Bug fixes that change transaction processes also require amendments.

Amendment Process

The Contributing Code to Xahau topic walks through the workflow to develop an amendment from an idea to activation on Xahau.

After the code for an amendment is built into a software release, the process to enable it happens within the Xahau network, which checks the status of amendments every flag ledger (typically about 15 minutes apart).

Every 256th ledger is called a flag ledger. The flag ledger doesn't have special contents, but the amendment process happens around it.

  1. Flag Ledger -1: When xahaud validators send validation messages, they also submit their amendment votes.

  2. Flag Ledger: Servers interpret the votes from trusted validators.

  3. Flag Ledger +1: Servers insert an EnableAmendment pseudo-transaction and flag based on what they think happened:

    • The tfGotMajority flag means the amendment has more than 80% support.

    • The tfLostMajority flag means support for the amendment has decreased to 80% or less.

    • No flag means the amendment is enabled.

    Note: It's possible for an amendment to lose 80% support on the same ledger it reaches the required five day period to be enabled. In these cases, an EnableAmendment pseudo-transactions is added for both scenarios, but the amendment is ultimately enabled.

  4. Flag Ledger +2: Enabled amendments apply to transactions on this ledger onwards.

Amendment Voting

Each version of xahaud is compiled with a list of known amendments and the code to implement those amendments. Operators of xahaud validators configure their servers to vote on each amendment and can change it at any time. If the operator doesn't choose a vote, the server uses a default vote defined by the source code.

Note: The default vote can change between software releases. [Updated in: rippled 1.8.1][]

Amendments must maintain five days of support from more than 80% of trusted validators to be enabled. If support drops below 80%, the amendment is temporarily rejected, and the two week period restarts. Amendments can gain and lose a majority any number of times before they become permanently enabled.

Amendments that have had their source code removed without being enabled are considered Vetoed by the network.

Amendment Blocked Servers

Amendment blocking is a security feature to protect the accuracy of Xahau's data. When an amendment is enabled, servers running earlier versions of xahaud without the amendment's source code no longer understand the rules of the network. Rather than guess and misinterpret ledger data, these servers become amendment blocked and can't:

  • Determine the validity of a ledger.

  • Submit or process transactions.

  • Participate in the consensus process.

  • Vote on future amendments.

The voting configuration of a xahaud server has no impact on it becoming amendment blocked. A xahaud server always follows the amendments enabled by the rest of the network, so blockages are based solely on having the code to understand rule changes. This means you can also become amendment blocked if you connect your server to a parallel network with different amendments enabled. For example, the Xahau Testnet typically has experimental amendments enabled. If you are using the latest production release, your server likely won't have the code for those experimental amendments.

You can unblock amendment blocked servers by upgrading to the newest version of xahaud.

Retiring Amendments

When amendments are enabled, the source code for pre-amendment behaviors remain in xahaud. While there are use-cases for keeping old code, such as reconstructing ledger outcomes for verification, tracking amendments and legacy code adds complexity over time.

Last updated 1 year ago

Was this helpful?

The defines a process for retiring old amendments and associated pre-amendment code. After an amendment has been enabled on the Mainnet for two years, it can be retired. Retiring an amendment makes it part of the core protocol unconditionally; it's no longer tracked or treated as an amendment, and all pre-amendment code is removed.

XRP Ledger Standard 11d