The XRP Ledger’s 3.3.0 release introduced six amendments. As of today none of them are enabled on mainnet. One, a maintenance fix, reached the 80 percent validator threshold on 28 August 2026 and is scheduled to activate on 11 September. The five substantive ones, including confidential transfers and atomic batching, are still waiting for votes.
That distinction gets lost constantly. An amendment shipping in a rippled release means the code exists. It does not mean the feature is live, and on the XRP Ledger the gap between those two things is decided by independent validators rather than by the company that wrote the code.
| Amendment | Introduced | Mainnet status |
|---|---|---|
fixCleanup3_3_0 | 3.3.0 | Majority reached 28 Aug 2026, activates 11 Sep |
ConfidentialTransfer | 3.3.0 | Not enabled |
BatchV1_1 | 3.3.0 | Not enabled |
PermissionDelegationV1_1 | 3.3.0 | Not enabled |
DynamicMPT | 3.3.0 | Not enabled |
Sponsor | 3.3.0 | Not enabled |
Verified against the validated ledger directly. The on-ledger Amendments object currently lists 93 enabled amendments and exactly one entry in its Majorities array: 3298D47E1F3A8A24FECAA30F699B8FE1DD234E072834BA099AD8180FFCE0FEC4, with a close time of 28 August 2026 at 11:15 UTC.
How an XRPL amendment actually goes live
An amendment needs support from at least 80 percent of trusted validators, continuously, for two weeks. If support drops below the threshold at any point the two-week clock resets. When the window completes, the amendment activates automatically at a specific ledger.
The two-week hold is the part worth understanding. It is not a delay for its own sake. It gives operators who disagree, or who simply have not upgraded, a fixed period to act before behavior changes underneath them. A validator that has not upgraded to a version containing the amendment cannot vote for it, so the vote doubles as a measure of how much of the network has actually deployed the code.
This is why the single majority right now is the maintenance fix rather than a feature. Cleanup amendments are uncontroversial and get support quickly. Features that change what institutions can do with assets attract scrutiny, and scrutiny takes longer than two weeks.
What the five pending amendments would add
Read as a group, the 3.3.0 feature set is aimed squarely at institutional use rather than retail. That is a coherent direction, and it is fair to say it lines up with what the ledger has been building toward for two years.
ConfidentialTransfer would encrypt balances and payment amounts for Multi-Purpose Tokens. A fund or bond issuer that cannot publish every holder’s position on a public ledger currently has no good answer. This is that answer.
BatchV1_1 would let several transactions execute atomically, all or none. That is the primitive underneath any multi-leg settlement where a partial execution is worse than no execution.
PermissionDelegationV1_1 would let an account grant narrowly scoped signing authority to another account without handing over full control. For an institution, the ability to delegate one specific action instead of the keys is the difference between a workable operating model and a compliance problem.
DynamicMPT would allow certain Multi-Purpose Token properties to change after issuance, which matters for instruments whose terms are not fixed for life. Sponsor would let one account pay another’s fees and reserves, removing the requirement that a new user hold XRP before doing anything.
Together they extend the tokenization work described in asset tokenization and the identity plumbing in the Credentials amendment. None of it is live.
Why “not enabled” is the honest headline
There is a real story here and it does not need embellishment. Six amendments in one release, five of them institutional features, is a substantial body of protocol work. The ledger has 93 enabled amendments today, which is a long record of shipping changes through the same validator process.
But an amendment that has not reached majority has no activation date, and there is no rule that says it eventually will. Amendments have sat unvoted for long periods, and some have been withdrawn after problems surfaced. The 3.2.0 cleanup fix is enabled today; the 3.3.0 one is two weeks out. Everything else in that release is a proposal with code attached.
Anyone can check this in a few seconds rather than taking a summary on faith. The Amendments ledger object holds both the enabled list and the pending majorities, and it is readable from any public node. The complete verified amendment index tracks the full history the same way.
Common questions
Are confidential transfers live on the XRP Ledger? No. ConfidentialTransfer shipped in rippled 3.3.0 but is not enabled on mainnet and has not reached validator majority.
What does 80 percent for two weeks mean? An amendment must hold support from at least 80 percent of trusted validators continuously for two weeks. If support lapses, the clock restarts. On completion it activates automatically.
How many amendments are enabled on the XRP Ledger? 93 as of the validated ledger checked for this article, with one further amendment in its majority window.
Can I verify amendment status myself? Yes. Query the Amendments ledger object at index 7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4 on any public XRPL node. It returns the enabled list and any pending majorities with close times.
Educational only, not tax, legal, or investment advice. Amendment status changes; verify against the ledger before relying on it. Nothing here is a recommendation to buy, sell, or hold any digital asset.
Sources
- XRP Ledger, Amendments
- XRP Ledger, Amendments ledger object
- Chase and MacBrough, Analysis of the XRP Ledger consensus protocol
Part of our guide: XRP Explained.
