XRPL FixCleanup3_3_0 Reaches Majority, but Activation Is Still Pending

Direct answer: the majority is recorded, but the rule is not live

[Confirmed fact] The XRP Ledger's `fixCleanup3_3_0` amendment has entered the pending-majority state: the validated Amendments object records it with a majority timestamp, while fresh Ripple endpoints show it supported but not enabled. [Independent snapshot] XRPScan reports 29 of 35 validations, or 82.86%. Activation remains contingent on holding that threshold for 14 days. [1][2][3][4][6]

This is a meaningful governance milestone, but it is not the same as an activation transaction. XRPL's amendment process separates software availability, validator support, the two-week majority period, and the ledger state that finally enables the amendment. The distinction matters because `xrpld` 3.3.0 was released on August 6, yet the six amendments bundled into that release still required their own network vote. [1][2]

The current story is therefore narrow and specific: fixCleanup3_3_0 appears to have crossed the support threshold and started its waiting period. It does not mean every 3.3.0 feature is close to activation, that every validator is running the same binary, or that an application using AMMs, vaults, lending, or permissioned domains has already received new behavior. [2][5][7]

Section sources[1][2][3][4][6][7]

The primary ledger record is stronger than a headline

[Primary record] A validated-ledger query to Ripple's public s1 endpoint at 2026-08-28 22:12 Central time returned ledger index 106613624 and an `Amendments` object whose `Majorities` array contains the fixCleanup3_3_0 amendment ID. The object reports `CloseTime: 841230900`. XRPL's reference documentation defines that field as the close time of the ledger where the amendment most recently gained a majority. [3][4]

[Derived timestamp] Converting that XRPL epoch value places the majority record at August 28, 2026 at 11:15 UTC. The conversion does not add a new network event. It simply puts the primary ledger field into a date readers can compare with independent trackers. The relevant fact is that the amendment is in `Majorities`, not in the active `Amendments` list. [3][4]

The same s1 feature response, checked at a later validated ledger index of 106613629, returned `name: fixCleanup3_3_0`, `supported: true`, and `enabled: false`. A parallel query to Ripple's s2 endpoint at ledger index 106613632 returned the same support and enabled states. Two endpoints do not prove that every public or private server agrees, but they provide a direct operational check that the amendment has not activated on the queried network state. [4][5]

An independent XRPScan API snapshot checked at 22:12 Central time returned `count: 29`, `validations: 35`, `threshold: 28`, `majority: 841230900`, `supported: true`, and `enabled: false`. The arithmetic is straightforward: 29 divided by 35 equals 82.857%, rounded to 82.86%. The `threshold: 28` field represents the tracker boundary, while XRPL's documentation describes the requirement in words as more than 80% support. [2][6]

The evidence hierarchy is important. The ledger object establishes a pending majority, and the feature RPC establishes that the amendment is still disabled. XRPScan supplies the current 29-of-35 count, which is not exposed as a per-validator tally by the public RPC. XRPLDashboard independently displays the same count and a conditional September 11 projection. [2][3][4][6][7]

Section sources[2][3][4][5][6][7]

Why September 11 is a conditional window, not a launch announcement

XRPL's documented process runs around flag ledgers, which occur every 256 ledgers. Validators communicate amendment votes, servers interpret those votes, and an `EnableAmendment` pseudo-transaction can mark an amendment as having gained or lost a majority. The `tfGotMajority` flag means support is above the activation line; `tfLostMajority` means support has fallen to 80% or less. [2]

The network must maintain more than 80% support for two weeks. If support falls to 80% or less before activation, the amendment is removed from `Majorities` and the waiting period starts again when it later regains a majority. If the support remains in place for the full period, an unflagged enable transaction moves the amendment from the pending-majority record into the active list. [2][3]

XRPLDashboard uses the primary `CloseTime` value of 11:15 UTC on August 28 to project September 11 at 11:15 UTC, conditional on the vote holding. The official documentation adds another nuance: activation takes effect for subsequent ledger versions after the enabling step. Readers should therefore treat September 11 as the earliest useful checkpoint, not as a guaranteed exact second when every client changes behavior. [2][3][7]

[Independent context] Crypto.news reported on August 12 that fixCleanup3_3_0 had 8 of 35 votes and was below the threshold at that time. TokenPost reported on August 28 that the amendment had reached 29 of 35 and entered the two-week interval. These reports are independent context for the change in observed support, not substitutes for the current primary ledger state. [8][9]

The earlier AllAboutXRP report on the August 6 release covered why the six 3.3.0 amendments were not immediately live. This article updates only the governance state of fixCleanup3_3_0. It should not be read as a rewrite of that release report or as evidence that BatchV1_1, ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, or Sponsor have crossed the same threshold. [1][2]

Section sources[2][3][7][8][9][1]

What fixCleanup3_3_0 changes across the XRPL stack

[Confirmed fact] fixCleanup3_3_0 is a bundled maintenance amendment, not a single consumer-facing product. The official August 6 release notes group changes across Single Asset Vaults, the Lending Protocol, Automated Market Makers, the permissioned decentralized exchange, Checks, and pseudo-account authorization. The package changes transaction outcomes and invariant checks at protocol boundaries. [1]

For pseudo-accounts, the release notes unify freeze and deep-freeze checks across `VaultDeposit`, `VaultWithdraw`, `AMMDeposit`, `AMMWithdraw`, `LoanBrokerCoverDeposit`, and `LoanBrokerCoverWithdraw`. The same bundle causes pseudo-account signatures to fail with `tefBAD_AUTH` and rejects pseudo-account targets in `CredentialCreate` and `DepositPreauth`. These are authorization and state-integrity rules. They do not create a new wallet feature or prove that a particular application will be compatible on activation day. [1][8]

For Checks, an all-zero `CheckID` is rejected during preflight with `temMALFORMED` instead of reaching processing and returning `tecNO_ENTRY`. For the permissioned DEX, hybrid offers should no longer disappear from the open order book merely because the placing account loses access to the permissioned domain. The release also keeps AMM liquidity out of quality estimates for permissioned DEX order books. [1][8]

For AMMs, the bundle changes one `AMMWithdraw` divide-by-zero edge case into the explicit `tecAMM_FAILED` result, adds precision-loss checks to deposit, withdrawal, and clawback paths when `fixAMMv1_3` is enabled, and strengthens the `ValidAMM` and `ObjectHasPseudoAccount` invariants. The package also includes further precision and rounding fixes for Single Asset Vaults and the Lending Protocol. [1][8][9]

The common thread is predictable rejection or accounting at unusual boundaries. That is useful for developers and operators because a malformed or impossible state should produce a defined protocol result instead of an exception or an incomplete object relationship. It is not a promise that AMM losses disappear, loans perform, vaults are solvent, or every downstream integration has passed its own tests. [Bounded inference] The likely user benefit is more deterministic edge-case behavior after activation, but the sources do not quantify incident reduction or economic impact. [1][2][8]

Section sources[1][8][9][2]

Affected paths and their practical change

The table below translates representative release-note changes into operational language. It describes what the amendment would do after activation. It does not describe a new product launch, a security certification, or an investment thesis. [1][2][8]

Section sources[1][2][8]

Implications for operators, developers, and XRP holders

[For validator and infrastructure operators] The immediate task is evidence tracking, not a premature production switch. Operators should record the `xrpld` version they run, whether the amendment is supported, the current `Majorities` entry, and whether the feature is enabled. The official 3.3.0 release instructs server operators to upgrade for service continuity, but that instruction is separate from the amendment's activation state. A server that lacks the code for an enabled amendment can become amendment-blocked and lose the ability to validate or participate normally. [1][2][4]

[For application developers] Test the explicit result-code changes and the precision-sensitive paths before relying on the conditional date. An integration that currently treats `tecNO_ENTRY`, `temMALFORMED`, `tefEXCEPTION`, and `tecAMM_FAILED` as interchangeable may produce the wrong user message or retry behavior after activation. AMM, vault, and lending builders should also test pseudo-account freeze behavior and rounding against the release that actually carries the amendment, rather than against a tracker label alone. [1][2][8]

[For permissioned-market builders] The relevant effect is not simply that an offer exists. Domain membership, hybrid offer retention, and AMM quality estimation can affect which liquidity is eligible for a permissioned order book. Builders should verify their own pathfinding, quote, and order-state assumptions against the eventual activated rules. The amendment does not itself announce a new permissioned market, new liquidity, or a new institutional partnership. [1][8]

[For vault and lending participants] The additional rounding, precision, and pseudo-account checks may reduce ambiguous transaction outcomes, but they do not replace credit underwriting, custody controls, legal review, liquidation design, or application-level monitoring. A protocol rule that prevents one inconsistent state is narrower than a guarantee that a vault is solvent or a loan will be repaid. The separate AllAboutXRP coverage on [XRPL lending amendment voting](/news/xrpl-lending-protocol-vote-consensus-2026) remains useful background for those broader activation questions. [1][2]

[For XRP holders and market readers] No source reviewed for this report establishes a causal XRP price response, new XRP demand, a new lending market, or an adoption milestone from the pending majority. fixCleanup3_3_0 primarily changes transaction processing and integrity behavior. Treating the vote as a price signal would add an unsupported inference to a governance record. [Unresolved uncertainty] Any market effect would require separate dated market data and a defensible causal analysis. [1][6][8]

Section sources[1][2][4][8][6]

Confirmed facts, bounded inference, and unresolved uncertainty

[Confirmed fact] The primary validated `Amendments` object contains the fixCleanup3_3_0 ID in `Majorities` and records the majority-gaining close time as XRPL epoch 841230900. Ripple's s1 and s2 feature responses, checked August 28, report the amendment as supported but disabled. The official release identifies the amendment as part of `xrpld` 3.3.0, published August 6. [1][3][4][5]

[Independent snapshot] XRPScan returned 29 validations out of 35, a reported threshold of 28, and `enabled: false`. XRPLDashboard displayed the same 29-of-35 support and classified the amendment as in a 14-day countdown. TokenPost reported the August 28 milestone, while Crypto.news provides a dated August 12 baseline of 8 of 35. These are useful corroborating observations, but public trackers can refresh at different times. [6][7][8][9]

[Bounded inference] Because the primary object records the amendment in `Majorities` at 11:15 UTC and the independent dashboard projects 14 days from that point, the earliest defensible activation window is around September 11, 2026 at 11:15 UTC if support does not fall to 80% or less. The exact activation ledger remains future evidence, not a fact available in this report. [2][3][7]

[Unresolved uncertainty] The public feature RPC does not publish a full per-validator vote table, the XRPScan count can change as its snapshot refreshes, and the official human-facing tracker may not update at the same instant as the ledger. The primary evidence resolves the most important question, which is disabled versus enabled, but it does not establish the future vote path, the identities behind every validation, or the behavior of every downstream client. [2][4][6][7]

[Unresolved uncertainty] The reviewed records also do not establish a stable 3.4.0 release boundary, complete application compatibility, independent audit coverage of the final activated behavior, or any price, adoption, lending-volume, or partnership outcome. Those claims require new primary records and should not be inferred from a pending amendment majority. [1][2][8]

Section sources[1][2][3][4][5][6][7][8][9]

How the next activation record will be proven

The next primary confirmation is not another headline. It is a validated-ledger change in which fixCleanup3_3_0 leaves `Majorities` and appears in the active `Amendments` list, accompanied by the feature RPC changing from `enabled: false` to `enabled: true`. Until that record exists, the amendment is pending. [2][3][4]

Watch the next flag-ledger decisions for evidence that the majority is being maintained. A `tfLostMajority` event or removal from the `Majorities` array would mean the two-week clock has not completed and must restart after a later majority. A countdown page that continues to show September 11 is useful context, but the ledger transition is the decisive record. [2][3][7]

Watch release provenance separately. The official 3.3.0 release contains the code for the package, yet operators and application teams still need the exact binary, build, SDK, Clio, wallet, indexer, and test-network combinations they support. A new tag can establish code availability; it cannot by itself prove Mainnet activation. [1][2]

Watch the affected result codes and invariants in real integration tests: pseudo-account freeze checks, all-zero CheckID preflight, permissioned-domain offer retention, AMM precision-loss handling, AMM deletion invariants, and vault or lending rounding. These are the practical checks that can turn a protocol change into a compatibility issue for software that assumed the earlier behavior. [1][8][9]

Finally, watch future claims about XRP demand, institutional deployment, lending volume, or price only when they arrive with a dated, attributable record. fixCleanup3_3_0 is a governance and transaction-processing milestone. Its activation could matter to infrastructure, but this report does not establish a market outcome. [Unresolved uncertainty][1][2][6]

Section sources[2][3][4][7][1][8][9]