The XRP Ledger has changed 93 times by consensus. Not by a company shipping an update, and not by a foundation announcing one. Each change was proposed as an amendment, voted on by validators, and switched on only after it held more than 80% support for two continuous weeks.
This is the complete list of all 93 amendments currently enabled, from 2016-05-19 to 2026-07-29, with the activation date and ledger number for each. Every fact on this page was read off the validated ledger rather than copied from a summary, and the last section shows you how to check any of it yourself in about a minute.
What an amendment actually is
Most blockchains change through a hard fork: a new version of the software ships, operators upgrade, and if enough of them disagree the network splits. The XRP Ledger uses a different mechanism. A change is written into the server software in a disabled state, and it stays disabled until the validators vote it on.
The rule is specific, and it is documented in the protocol’s own amendment reference. An amendment must hold more than 80% support from trusted validators for two continuous weeks. If support drops to 80% or below at any point, the two-week clock restarts. An amendment can gain and lose majority any number of times before it activates. The ledger marks each swing with a tfGotMajority or tfLostMajority flag, so the whole approach run is visible in the ledger history rather than in a company’s changelog.
When it finally passes, the ledger records an EnableAmendment pseudo-transaction, and from the next ledger version onward the new rules apply to everyone.
The path from idea to activation
A change passes through four stages, and each one is public.
- A standard is drafted as an XLS in the XRPL Standards repository, where it is discussed and revised in the open.
- It is implemented in the server software, shipped in a release, and left switched off.
- Validator operators independently choose whether to vote for it.
- If it holds more than 80% for two weeks, it activates for the whole network at once.
Stage two and stage three are the part worth understanding. Shipping the code and enabling the code are separate events performed by different people, and the gap between them is often long. The 40 feature amendments in this list arrived across 36 distinct server releases, and several sat in shipped software for a year or more before validators switched them on.
What happens to a server that disagrees
It stops. A server that does not recognize an enabled amendment becomes amendment blocked: it refuses to process transactions or report ledger state, and it stays that way until it is upgraded. Notably, this has nothing to do with how the operator voted. Voting configuration does not affect whether a server becomes blocked, so an operator who voted against a change and lost is blocked exactly like one who never voted.
This is the mechanism that prevents forks, and it is a deliberate tradeoff rather than a free win. The network prefers halting a server over letting it disagree about what happened. The cost is that an operator who falls behind is offline rather than degraded.
What the record actually shows
Holding the full verified set makes a few things visible that a list of names does not.
Activity is accelerating. 2025 was the busiest year in the ledger’s history with 17 amendments enabled. On 2025-01-30 alone, 6 activated together.
It has not been steady. The longest gap ran 326 days, from 2021-11-21 to 2022-10-13, with nothing enabled at all. Development on this ledger moves in bursts rather than at a constant rate, and any narrative built on a single year is reading noise.
Most recent work is maintenance. Of the 40 amendments enabled since the start of 2024, 26 were fix corrections rather than new capability. That is worth stating plainly rather than burying: a rising share of corrections is what a codebase looks like when it has recently added a lot of surface area, and the automated market maker in particular has needed several rounds of it.
The standards process is younger than the ledger. Only 16 of the 40 feature amendments carry an XLS specification number. The rest predate the formal standards process, which is why the early entries below have no spec link. The ledger acquired its governance paperwork some years after it acquired its features.
Two consequences matter for anyone deciding whether to put real money on this ledger.
The first is that no single party ships a change. Software authors write the code, and validators decide whether it takes effect. Those are different groups, and the separation is the point.
The second is that changes are slow and visible. There is no emergency path, no way to skip the two weeks, and every approach run leaves a record in the ledger that anyone can read afterward. For an institution assessing protocol risk, the absence of a fast path is the feature.
The 40 feature amendments
Of the 93 enabled amendments, 40 added or changed a capability. They are grouped below by what they do rather than by date, because the story of this ledger is easier to read as seven parallel threads than as one long list. Names link to a full article where one has been published.
Read in order, these seven threads are the story of a payment network growing into an institutional finance stack: first the ability to move value, then to price it, then to restrict who can touch it, and most recently to represent assets other than currency.
Access control and identity
Who is allowed to interact with whom, and on what evidence. This thread is the ledger’s answer to on-chain KYC and credentials.
| Amendment | Spec | Activated | Ledger | First shipped |
|---|---|---|---|---|
| TrustSetAuth | – | 2016-07-19 | 22,721,281 | 0.30.0 |
| DepositAuth | – | 2018-04-06 | 37,753,345 | 0.90.0 |
| DepositPreauth | – | 2018-10-09 | 42,114,049 | 1.1.0 |
| DisallowIncoming | – | 2023-08-21 | 81,986,305 | 1.10.0 |
| DID | XLS-40 | 2024-10-30 | 91,778,561 | 2.0.0 |
| Credentials | XLS-70 | 2025-09-04 | 98,615,297 | 2.3.0 |
| PermissionedDomains | XLS-80 | 2026-02-04 | 102,017,793 | 2.4.0 |
| PermissionedDEX | XLS-81 | 2026-02-18 | 102,328,065 | 2.5.0 |
Issuer control and regulated assets
The controls an issuer of a regulated instrument is required to have.
| Amendment | Spec | Activated | Ledger | First shipped |
|---|---|---|---|---|
| Clawback | XLS-39 | 2024-02-08 | 85,829,633 | 1.12.0 |
| AMMClawback | XLS-73 | 2025-01-30 | 93,814,273 | 2.3.0 |
| DeepFreeze | XLS-77 | 2025-05-04 | 95,893,505 | 2.4.0 |
| MPTokensV1 | XLS-33 | 2025-10-01 | 99,226,369 | 2.3.0 |
| TokenEscrow | XLS-85 | 2026-02-12 | 102,204,929 | 2.5.0 |
Markets, liquidity and pricing
How trades are matched, priced and routed.
| Amendment | Spec | Activated | Ledger | First shipped |
|---|---|---|---|---|
| Flow | – | 2016-10-21 | 24,970,753 | 0.33.0 |
| TickSize | – | 2017-02-21 | 27,841,793 | 0.50.0 |
| FlowCross | – | 2020-08-04 | 57,286,657 | 0.70.0 |
| FlowSortStrands | – | 2021-11-11 | 67,639,809 | 1.7.0 |
| ImmediateOfferKilled | – | 2023-08-21 | 81,986,305 | 1.10.0 |
| AMM | XLS-30 | 2024-03-22 | 86,795,265 | 1.12.0 |
| PriceOracle | XLS-47 | 2024-11-02 | 91,831,297 | 2.2.0 |
Payment primitives
Ways to move value other than a simple payment, including escrow and payment channels.
| Amendment | Spec | Activated | Ledger | First shipped |
|---|---|---|---|---|
| CryptoConditions | – | 2016-12-20 | 26,388,481 | 0.50.0 |
| Escrow | – | 2017-03-31 | 28,685,313 | 0.60.0 |
| PayChan | – | 2017-03-31 | 28,685,313 | 0.33.0 |
| Checks | – | 2020-06-18 | 56,219,905 | 0.90.0 |
| CheckCashMakesTrustLine | – | 2023-01-23 | 77,310,209 | 1.8.0 |
Native tokenized assets
Non-fungible tokens as a ledger primitive rather than contract code.
| Amendment | Spec | Activated | Ledger | First shipped |
|---|---|---|---|---|
| NonFungibleTokensV1_1 | XLS-20 | 2022-10-31 | 75,443,457 | 1.9.2 |
| NFTokenMintOffer | XLS-52 | 2025-02-15 | 94,166,785 | 2.3.0 |
| DynamicNFT | XLS-46 | 2025-06-11 | 96,724,737 | 2.4.0 |
Accounts, keys and custody
Authorization policy, signing, and account lifecycle.
| Amendment | Spec | Activated | Ledger | First shipped |
|---|---|---|---|---|
| MultiSign | – | 2016-06-27 | 22,178,817 | 0.31.0 |
| MultiSignReserve | – | 2019-04-17 | 46,599,937 | 1.2.0 |
| DeletableAccounts | XLS-7 | 2020-05-08 | 55,313,921 | 1.4.0 |
| RequireFullyCanonicalSig | – | 2020-07-03 | 56,564,737 | 1.5.0 |
| TicketBatch | XLS-13 | 2021-11-18 | 67,785,985 | 1.7.0 |
| ExpandedSignerList | – | 2022-10-13 | 75,035,393 | 1.9.1 |
Network integrity and economics
Spam resistance, liveness, safety guarantees and fees.
| Amendment | Spec | Activated | Ledger | First shipped |
|---|---|---|---|---|
| FeeEscalation | – | 2016-05-19 | 21,225,473 | 0.31.0 |
| EnforceInvariants | – | 2017-07-07 | 31,054,081 | 0.70.0 |
| SortedDirectories | – | 2017-11-14 | 34,256,897 | 0.80.0 |
| HardenedValidations | – | 2021-04-08 | 62,759,681 | 1.6.0 |
| NegativeUNL | – | 2021-11-21 | 67,849,217 | 1.7.3 |
| XRPFees | – | 2024-03-25 | 86,860,289 | 1.10.0 |
The 53 maintenance amendments
The remaining 53 amendments are corrections. They carry a fix prefix and they exist because something in the protocol behaved differently from how it was specified, or because a change needed a follow-up.
It would be easy to leave these out. They are unglamorous and several of them describe bugs. Including them is the more useful choice, because the interesting fact is not that the bugs existed. It is that fixing them required the same 80% validator vote as every headline feature. A protocol-level bug on the XRP Ledger cannot be patched by the people who found it. They have to convince the validators, in public, and wait two weeks.
The automated market maker in particular has needed several rounds of correction since it went live, and that history is visible here rather than buried.
| Amendment | Activated | First shipped |
|---|---|---|
fix1368 |
2017-03-31 | 0.60.0 |
fix1373 |
2017-07-07 | 0.70.0 |
fix1528 |
2017-11-14 | 0.80.0 |
fix1201 |
2017-11-14 | 0.80.0 |
fix1523 |
2017-11-14 | 0.80.0 |
fix1512 |
2017-11-14 | 0.80.0 |
fix1513 |
2018-04-06 | 0.90.0 |
fix1571 |
2018-06-19 | 1.0.0 |
fix1623 |
2018-06-20 | 1.0.0 |
fix1543 |
2018-06-21 | 1.0.0 |
fix1515 |
2018-10-09 | 1.1.0 |
fix1578 |
2019-03-23 | 1.2.0 |
fixTakerDryOfferRemoval |
2019-04-02 | 1.2.0 |
fixMasterKeyAsRegularKey |
2019-10-02 | 1.3.1 |
fixCheckThreading |
2020-05-01 | 1.4.0 |
fixPayChanRecipientOwnerDir |
2020-05-01 | 1.4.0 |
fixQualityUpperBound |
2020-07-09 | 1.5.0 |
fixAmendmentMajorityCalc |
2021-04-08 | 1.6.0 |
fix1781 |
2021-04-08 | 1.6.0 |
fixSTAmountCanonicalize |
2021-11-11 | 1.7.0 |
fixRmSmallIncreasedQOffers |
2021-11-18 | 1.7.2 |
fixRemoveNFTokenAutoTrustLine |
2022-10-27 | 1.9.4 |
fixUniversalNumber |
2023-08-21 | 1.10.0 |
fixTrustLinesToSelf |
2023-08-21 | 1.10.0 |
fixNonFungibleTokensV1_2 |
2023-08-21 | 1.10.0 |
fixReducedOffersV1 |
2023-11-24 | 1.12.0 |
fixNFTokenRemint |
2023-11-27 | 1.11.0 |
fixInnerObjTemplate |
2024-04-08 | 2.1.0 |
fixAMMOverflowOffer |
2024-04-11 | 2.1.1 |
fixFillOrKill |
2024-04-11 | 2.0.0 |
fixDisallowIncomingV1 |
2024-04-11 | 2.0.0 |
fixNFTokenReserve |
2024-04-12 | 2.1.0 |
fixAMMv1_1 |
2024-09-24 | 2.2.0 |
fixPreviousTxnID |
2024-09-27 | 2.2.0 |
fixEmptyDID |
2024-09-27 | 2.2.0 |
fixReducedOffersV2 |
2025-01-30 | 2.3.0 |
fixAMMv1_2 |
2025-01-30 | 2.3.0 |
fixEnforceNFTokenTrustline |
2025-01-30 | 2.3.0 |
fixInnerObjTemplate2 |
2025-01-30 | 2.3.0 |
fixNFTokenPageLinks |
2025-01-30 | 2.3.0 |
fixInvalidTxFlags |
2025-05-15 | 2.4.0 |
fixFrozenLPTokenTransfer |
2025-05-15 | 2.4.0 |
fixAMMv1_3 |
2025-08-29 | 2.5.0 |
fixEnforceNFTokenTrustlineV2 |
2025-08-29 | 2.5.0 |
fixPayChanCancelAfter |
2025-08-29 | 2.5.0 |
fixDirectoryLimit |
2025-12-18 | 2.6.2 |
fixTokenEscrowV1 |
2026-01-27 | 3.0.0 |
fixAMMClawbackRounding |
2026-01-27 | 3.0.0 |
fixIncludeKeyletFields |
2026-01-27 | 3.0.0 |
fixPriceOracleOrder |
2026-01-27 | 3.0.0 |
fixMPTDeliveredAmount |
2026-01-27 | 3.0.0 |
fixCleanup3_1_3 |
2026-05-27 | 3.1.3 |
fixCleanup3_2_0 |
2026-07-29 | 3.2.0 |
Verify any of this yourself
Two checks, neither of which requires trusting this page.
The amendment ID is derived from the name. An amendment’s 64-character ID is the first half of the SHA-512 hash of its name in plain ASCII. So AMM hashes to 8CC0774A3BF66D1D22E76BBDA8E8A232E6B6313834301B3B23E8601196AE6455, and any name that does not produce a matching ID is wrong. This is how the names on this page were confirmed, rather than by trusting a list.
The enabled set is a single ledger object. The full list of enabled amendments lives in one Amendments entry on the validated ledger, at index 7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4. A ledger_entry request to any public node returns it, along with any amendment currently holding a majority but still inside its two-week window. If a source disagrees with that object, the source is wrong.
That is how this page was assembled. The names were confirmed by hashing, the enabled set was read from the ledger object, and each activation date was re-read from the close time of the ledger containing its EnableAmendment transaction. Where a secondary source disagreed, the ledger won.
The governance question, stated fairly
The obvious objection to everything above is that 80% of trusted validators is not the same as 80% of anybody. Validators earn no reward, hold no stake, and appear on a server’s list because an operator put them there. Most operators use a default list, and that concentrates real influence in whoever publishes it.
This is a genuine limitation rather than a smear, and it is worth being precise about what it does and does not threaten. The protocol’s consensus mechanism has been analyzed formally: the 2018 paper Analysis of the XRP Ledger Consensus Protocol describes it as a low-latency Byzantine agreement protocol that can reach consensus without full agreement on network membership, and derives the conditions under which safety and liveness hold. Those conditions are real constraints, not marketing. The honest summary is that the protocol has stated assumptions, they are published, and whether the live validator set satisfies them comfortably is a matter of ongoing and legitimate debate.
What the amendment record does establish is narrower and still useful: all 93 of these changes took at least two weeks, happened in public, and left evidence in the ledger. That is a weaker claim than decentralization and a far easier one to check.
Where this index is limited
It covers what is enabled, and nothing else. Amendments that were proposed and abandoned, vetoed, or removed before activation do not appear, and neither does anything currently open for voting, which changes on its own schedule.
Activation dates are the date the ledger switched the rules on. That is often months or years after the feature was written, and it says nothing about when anyone started using it. An amendment being enabled means the capability exists. It does not mean the capability has meaningful volume, and for several of the items above it does not.
Nor does this page argue that any of it makes XRP valuable. That is a separate question, and one worth reading about separately: what the ledger’s native asset actually does inside these mechanisms is a different discussion from what the mechanisms are.
Common questions
How many amendments does the XRP Ledger have?
93 are currently enabled: 40 that add or change a capability and 53 maintenance corrections. The count only moves when validators enable another one.
Who votes on XRP Ledger amendments?
Validators, through the trusted validator lists that servers configure. Holding XRP does not grant a vote, and neither does running a non-validating node. This is a genuine and frequently debated limitation of the model rather than a settled question.
Can an amendment be reversed?
Not by unvoting it. Once enabled, an amendment applies permanently to all subsequent ledger versions. Changing the behavior again requires a new amendment through the same process, which is why several entries in the list above are corrections to earlier ones.
What happens to a server that does not support an enabled amendment?
It stops. Rather than continue on rules it does not understand and produce a divergent view of the ledger, the server declares itself out of sync and waits to be upgraded.
Does an enabled amendment mean the feature is being used?
No. Activation means the rules changed. Adoption is a separate question, and for several recently enabled amendments the honest answer is that real usage is still small.
Educational only, not tax, legal, or investment advice. Nothing here is a recommendation to buy, sell, or hold any digital asset. Check primary sources and speak with a qualified professional before making financial decisions.
Background: what XRP is and how it is used.
Part of our guide: XRP Explained.
