XRP Confidential Transfers Sidestep Zcash but Miss the Vote

XRP Confidential Transfers cannot hide fake tokens the way Zcash’s Orchard pool did, RippleX engineering head J. Ayo Akinyele said on June 5, 2026. The claim followed an AI-assisted audit that found a four-year soundness flaw in Orchard.

The upgrade he pointed to still is not live. XRPSCAN showed 10 of 35 trusted validators, 28.57%, voting for the ConfidentialTransfer amendment on September 11.

Akinyele Answered Zcash With a Supply Rule

Akinyele was quoting Zcash founder Zooko Wilcox’s disclosure when he wrote that counterfeit bugs in shielded pools were an old worry, and that a missing-constraint bug lasting four years did not shock him. He then moved the argument off Zcash and onto how bugs get found.

The bigger takeaway is that AI models may be drastically changing the discoverability curve for hard-to-find vulnerabilities. More importantly, security assumptions that held yesterday may not hold tomorrow.

J. Ayo Akinyele, Head of Engineering, RippleX, on X

He put the warning on X the morning after ZEC’s crash, and he tied it to work already running inside RippleX, including AI-assisted reviews he called non-negotiable.

Counterfeit Zcash bugs have been a concern around shielded pools for a long time, so I'm not surprised a missing-constraint bug in a ZK circuit went undetected for 4 years.

The bigger takeaway is that AI models may be drastically changing the discoverability curve for… https://t.co/UL7yVpVvy1

— J. Ayo Akinyele (@ja_akinyele) June 5, 2026

A UNL validator, Vet, asked in the same thread how upcoming shielded balances for Multi-Purpose Tokens would keep track of supply. Akinyele’s answer is the whole design bet. He wrote that XRPL does not have a global shielded pool in the Zcash Orchard sense, that validators keep supply state on each confidential MPT transaction, and that ConfidentialOutstandingAmount is a plaintext ledger field anyone can check.

That reply is narrower than the June headlines that treated it as a shield for XRP the asset. The IACR paper by Murat Cenk, Aanchal Malhotra, and Joseph A. Akinyele, posted in late March, is explicit: the construction is confidential balances with public supply checks for Multi-Purpose Tokens, with sender and receiver identities left public.

What the Orchard Bug Allowed

Taylor Hornby, a security researcher working with Shielded Labs, found the Orchard flaw on May 29 while running a custom audit agent on Anthropic’s Claude Opus 4.8. The bug sat in the Halo 2 circuit that had been live since Orchard activated in May 2022. Hornby showed in a local test that invalid inputs could pass a multiplication check and mint ZEC the network would treat as real.

Orchard hides notes inside a shared pool. If someone had used the bug on mainnet, there would have been no public running total that proved the extra coins. Shielded Labs said it found no evidence of exploitation and also said Orchard’s privacy means that cannot be proved.

THE ORCHARD WEEK

1. May 29, 2026: Hornby confirms a soundness flaw in the Orchard circuit with Opus 4.8 and discloses it to Zcash developers.
2. June 2, 2026: An emergency soft fork at block 3,363,426 turns Orchard transactions off.
3. June 3, 2026: The NU6.2 hard fork at block 3,364,600 ships a corrected circuit and turns Orchard back on.
4. June 4, 2026: ZEC trades as high as $624. Arthur Hayes exits, saying a privacy coin cannot live on a patched circuit that still cannot prove the pool was clean.
5. June 5, 2026: ZEC prints $309. The drop from $624 is nearly 50%. Akinyele posts the XRPL supply argument the same day.

No funds were reported stolen. The market still treated “we cannot prove it was unused” as a broken promise, and that is the part that jumped chains. People who hold XRP asked whether the next AI pass would do the same to XRPL’s privacy work.

The Supply Number That Stays Public

XLS-0096, Confidential Transfers for Multi-Purpose Tokens, was opened on January 15 and marked Final in a September 10 update. Cenk, Malhotra, Akinyele, Peter Chen, Shawn Xie, and Yinyi Qian are listed as authors. The spec’s hinge is boring on purpose. Individual balances and transfer amounts are encrypted. The cap is not.

Validators still enforce the public cap because OutstandingAmount stays publicly enforceable on every mint, burn, and transfer. ConfidentialOutstandingAmount tracks the hidden slice of that total. The invariant is OutstandingAmount at or below MaximumAmount, checked without decrypting any wallet.

Issuers cannot park confidential balances on the issuer account itself. They fund a second account, convert a public balance there, and only then distribute hidden amounts. The ledger treats that second account as a holder, so its coins count toward OutstandingAmount. That is how the spec tries to make silent minting visible even when the amounts on the wire are ciphertext.

Each confidential balance is split so incoming payments cannot break a proof that is already in flight. Spending balance is the stable side used to build outgoing proofs. Inbox is where receipts land, and a holder has to merge it before spending. A version counter ticks when the spending balance changes, so an old proof dies instead of being replayed.

ORCHARD VERSUS CONFIDENTIAL MPTS

The table is the argument Akinyele made in one sentence. Hide the wallets. Leave the mint meter in the open. If a proof lies about a single account, the open meter is supposed to fail the transaction anyway.

Native XRP Never Enters the Private Pool

Official docs are blunter than the June recaps. Confidential Transfers apply to Multi-Purpose Token holders. They use EC-ElGamal encryption and zero-knowledge proofs to hide amounts, and they leave sender and receiver accounts on the public ledger. Native XRP is not in that set.

The feature also refuses to mix with the rest of the ledger’s money tools. Confidential payments are direct account-to-account transfers. They do not run through the DEX, escrows, or checks. Public and confidential balances can sit on the same MPT, and a holder can convert back and forth, including a convert of zero just to register a key.

That last detail has a hard edge. If a holder loses the ElGamal private key, the confidential funds are gone. Issuer and auditor keys cannot be rotated once they are registered. Clawback, when an issuer uses it, burns the holder’s entire confidential balance after a proof that the plaintext matches the encrypted mirror, and the docs warn issuers to lock the token first so the proof does not go stale.

The same page says the encryption is not considered quantum-safe, and that any move to lattice schemes is still research. A design sold as the answer to an AI auditor is already carrying a known limit against a later class of machine.

A Six-Week Audit Found Three High-Severity Holes

Trail of Bits reviewed the confidential-transfer stack for Ripple Labs in April, over six weeks, and published 17 issues: 3 high, 3 medium, 3 low, 7 informational, and 1 undetermined. The high titles are the ones that rhyme with Orchard, because they sit on range proofs and the counters that stop replay.

THREE HIGH FINDINGS FROM APRIL

• Bulletproof range: Aggregated Bulletproofs cannot handle certain in-range values.
• Overdraft path: One high finding was titled missing range proof enables confidential overdraft.
• Version counter: ConfidentialSend increments the receiver’s version counter.

A missing range proof is the cousin of a missing circuit constraint. Both are ways a prover can talk the verifier into accepting a balance that should have been impossible. The public OutstandingAmount field does not save you if the proof that feeds it is unsound, which is why the audit list matters more than the marketing line that AI attacks are blocked at the math layer.

The spec on GitHub now carries a full proof map, including a 192-byte compact send sigma proof and a 754-byte aggregated Bulletproof meant to show the transfer and the leftover balance sit in range. Those sizes are an engineering choice, not a verdict. They show the team is still in the same proof family Opus 4.8 just learned to read.

Far Short of the 80 Percent Bar

Code and a live rule are different things on XRPL. Support for Confidential Transfers landed in the rippled develop branch on June 27. The xrpld 3.3.0 release on August 6 bundled it with Batch, Dynamic MPT, Permission Delegation, Sponsor, and a cleanup fix. An amendment still needs more than 80% of trusted validators for two straight weeks before it turns on. The default vote in the stable release is No.

XRPSCAN’s table on September 11 listed 35 trusted validators and nine amendments still in the vote. Only the cleanup item had crossed the line.

THE 3.3.0 VOTE ON SEPTEMBER 11

• ConfidentialTransfer: 10 of 35, 28.57%, still voting.
• BatchV1_1: 26 of 35, 74.29%, still voting.
• fixCleanup3_3_0: 31 of 35, 88.57%, activated September 11.
• The bar: more than 80% of trusted validators, held for two weeks.

On September 11 the explorer listed ConfidentialTransfer still at 28.57 percent support. Batch was closer and still short. The cleanup amendment was the one that actually changed the live ledger that day. Anyone treating 3.3.0 as the week privacy went live on XRPL was reading a software tag as a network vote.

Zcash did not wait on a slogan. Ironwood, the pool built to replace the broken Orchard circuit, activated on July 28 at block 3,428,143, and Orchard was sealed to new deposits. XRPL’s privacy feature, the one used in June to say a Zcash-style inflation collapse could not happen here, was still a ballot three months after that post.

The Next Bug Hunt Will Not Need a Human First

Akinyele’s useful sentence was not the immunity line that got copied. It was the one about Opus 4.8 and later models reading ZK circuits, primitives, and protocol designs, not just application code. That is already how Orchard fell. Hornby’s agent produced a working local mint. Human review had sat on the same circuit since 2022.

RippleX was not asleep on that date. Staff software engineer Mayukha Vadari wrote on May 29, the day Hornby found Orchard, that the ledger’s AI red team had been running for two months, with tools, bugs already fixed, and a public write-up. The same thread that carried Akinyele’s supply lecture also carried a sharper question from the replies: had AI found a way around XRPL’s invariant checker, the thing that makes a plaintext supply field worth anything?

That is the second-order risk the June recaps skipped. A public OutstandingAmount is a strong design if the proofs that update it are sound. It is a false comfort if a model can mint a proof that the checker accepts. Confidential Transfers still use compact sigma proofs and Bulletproofs. They still need validators to opt in. They still do not cover XRP itself.

So the live fact is smaller than the claim that traveled with it. XRPL’s privacy work tries to keep a mint meter in the open while it encrypts MPT amounts. Zcash paid nearly 50% of ZEC’s price, then replaced Orchard. On XRPL, the amendment that was supposed to close that class of scare remains a 10-of-35 vote.

Disclaimer: This article is news reporting and analysis of public protocol documents, an engineering thread, a security review, and market prices. It is informational only and is not investment advice, trading advice, or a recommendation to buy, sell, or hold XRP, ZEC, Multi-Purpose Tokens, or any other asset. Readers should consult a licensed financial adviser who understands digital-asset risk before making any investment decision. Figures, amendment tallies, and software statuses reflect the cited sources as of the dates named above and can change as validators vote and as networks ship new code.