Skip to content
Blockchain Posts

protocol

XRPL fixCleanup3_4_0 slips to November 4 after validator support dipped to 26 of 35

The two-hour drop below the 80% threshold reset the fourteen-day countdown. The patch is now expected to activate at 14:46 UTC on November 4; support is back to 31 of 35.

by 3 min read
protocolxrpripplegovernanceinfrastructure

XRPL's fixCleanup3_4_0 amendment missed its original 09:34 UTC October 23 activation after validator support fell below the 80% threshold for about two hours on Wednesday. The amendment's fourteen-day countdown restarted at 14:46 UTC, pushing its earliest activation on mainnet to 14:46 UTC on November 4, per CoinDesk, with the delay also reported by Crypto Briefing.

What slipped

At the 12:54 UTC validator checkpoint on Wednesday, support for the amendment dropped to 26 of 35 trusted validators, below the 29 needed to clear the 80% threshold under XRPL's amendment-vote rules. Backing recovered to 29 by 14:46 UTC, but the brief dip reset the fourteen-day countdown that governs how long an amendment must hold the threshold before activation. By the next checkpoint the yes tally had climbed back to 31 of 35, per the public tally on XRPL Dashboard cited by CoinDesk alongside XRPLWin.

The amendment ships in the xrpld 3.4.0 release, as noted in the XRPLF release post.

What the patch actually fixes

Three fixes are bundled under the one amendment, as covered when the vote began in our October 19 piece:

  • Burn-permission loophole. An account authorized only to burn a token could, under specific conditions, create new units of that token. The authorization check is tightened.
  • Vault rounding. Single Asset Vault accounts rounded flows in a way that could accumulate error across many operations.
  • Loan default rules. The rules deciding when a loan under the Lending amendment is late or in default are rewritten.

Both the LendingProtocolV1_1 (XLS-66) and SingleAssetVault (XLS-65) amendments the patch repairs are themselves still short of the 29-validator threshold on mainnet; neither has triggered its own fourteen-day countdown.

Numbers

  • Threshold to pass: more than 80% of trusted validators voting yes.
  • Trusted validator set: 35.
  • Required yes votes: 29.
  • Wednesday 12:54 UTC checkpoint: 26 of 35 (dip).
  • Wednesday 14:46 UTC checkpoint: 29 of 35 (restart).
  • Current tally: 31 of 35 (margin of two above threshold).
  • New activation target: 14:46 UTC on November 4 (fourteen days from restart).

Source: XRPL Dashboard, as cited by CoinDesk.

What to watch

  1. The 31-of-35 margin. Any three validators dropping support between now and November 4 would reopen the gap and reset the countdown again. The patch ships with a DefaultNo vote under XRPL's newer governance convention, so individual operator decisions still move the number.
  2. Lending and Vaults. XLS-66 and XLS-65 need their own 29-yes counts to begin counting down. Neither has, and fixCleanup3_4_0 is explicitly a prerequisite for Lending to run safely.
  3. Validator identity. The public dashboards show the tally but not the identity of the three validators currently voting no; XRPL Foundation operator notes typically surface the reasons after a slip.

Context

This is the second time in two weeks the XRPL amendment system has stalled on a patch for code that already shipped. In early October the Foundation disclosed the rippled 3.4.1 payment-engine overflow — a ten-year-old bug fixed under a separate validator-signed amendment. The pattern is a lending-and-vaults rollout where the amendments landed in client releases ahead of the fixes that make them safe, so each slip in the fix amendments pushes the mainnet lending launch further out.

A fourteen-day re-counting rule applied to a tally that moves daily means a single validator going offline or voting no at the wrong checkpoint can erase two weeks of progress. The November 4 target assumes the current 31-of-35 count holds across every checkpoint between now and then.

Related stories