Originally published on xroot.dev.
The post on what is native and what is a third-party layer drew the same follow-up in three different ways: if the confidential features are native, can they be turned off?
Yes. Every confidential operation on a Token-2022 mint depends on one on-chain program, the ZK ElGamal proof program, and the validator carries two feature gates for it: one that disables it and one that re-enables it. Both switches have been used. This post is what each one does to a confidential balance, what a proof costs in compute and bytes, and why the biggest proofs need the new transaction format.
One Program Underneath Every Confidential Operation
A confidential transfer does not hide an amount by magic. The token program stores balances as ElGamal ciphertexts, and every operation that changes them — deposit into confidential form, transfer, withdraw back to plain — must be accompanied by zero-knowledge proofs that the amounts are well-formed: non-negative, within range, consistent between sender and receiver.
The token program does not verify those proofs itself. It calls the ZK ElGamal proof program, a separate native program whose only job is proof verification. If that program is unavailable, no confidential operation can be completed, because the token program cannot confirm the proofs it is handed.
That dependency is the kill switch.
The Two Gates
The validator's feature set carries disable_zk_elgamal_proof_program and reenable_zk_elgamal_proof_program, both live in the current feature snapshot. The first removes the proof program from the set the runtime will execute; the second puts it back. They are ordinary feature gates, activated at an epoch boundary after 95% of stake adopts each, and they have been used in that order once already. A flaw in the verifier's Fiat-Shamir transcript was found on 10 June 2025; the disable gate activated on 19 June 2025 at the start of epoch 805 (slot 347,760,000), and after audits the re-enable gate activated on 4 June 2026 at the start of epoch 982 (slot 424,224,000), with Token-2022 redeployed with its confidential instructions later that month. The proof program has been live on mainnet since that day, and as of 17 September 2026 the disable gate has not been used again.
What "disabled" means for a holder:
- Plain balances are untouched. A mint with the confidential-transfer extension still transfers, mints and burns normally in its public balance.
- Confidential balances are frozen in place. The ciphertexts remain in the account, provably yours, and no operation that needs a proof — including withdrawing back to a plain balance — can execute.
- Pending confidential deposits stay pending. Applying them needs a proof.
"Re-enabled" restores all of it with no state migration; the ciphertexts were never modified.
Worth knowing: an older program, the ZK Token Proof program, still exists as an address. It was never activated on any cluster and is now a stub that returns success while doing nothing and charging no compute. A transaction that calls it succeeds silently and proves nothing. Tooling that still references it is verifying against a program that verifies nothing.
What a Proof Costs, in Compute
The proof program charges a fixed compute-unit price per proof type, and the base instruction cost is zero. From the source:
Batched range proof, 64-bit — 111,000 units
Batched range proof, 128-bit — 200,000 units
Batched range proof, 256-bit — 368,000 units
Public key validity — 2,600 units
Zero-ciphertext — 6,000 units
Ciphertext-to-ciphertext equality — 8,000 units
Ciphertext-to-commitment equality — 6,400 units
Percentage with cap (confidential fees) — 6,500 units
Grouped-ciphertext validity, 2 / 3 handles — 6,400 / 8,100 units
Grouped-ciphertext validity, batched — 13,000 / 16,400 units
Closing a context-state account — 3,300 units
A confidential transfer needs several of these. The range proof dominates: a 256-bit batched range proof alone is over a quarter of the 1.4-million-unit per-transaction ceiling and about half a percent of an entire block — 0.49% of today's 75-million-unit block limit at 300 ms slots, and 0.59% of the 62.5 million that applies from epoch 1037, when slots drop to 250 ms. Compared with a plain token transfer of a few thousand units, a confidential one is two orders of magnitude more compute — and the priority-fee arithmetic, rank equals fee divided by requested cost, punishes that accordingly.
What a Proof Costs, in Bytes, and Why v1 Transactions Matter
Proofs are large. A 64-bit range proof is 672 bytes; 128-bit is 736; 256-bit is 800. A transaction has historically been capped at 1,232 bytes total, including signatures, accounts and every other instruction. Fitting a transfer's full proof set into one legacy transaction was the reason confidential transfers were awkward to use at all.
The program offers two workarounds and the network now offers a third:
- Proof-in-account. If the instruction data is exactly five bytes — a discriminator and an offset — the program reads the proof from an account instead of the instruction. You write the proof on chain first, verify against it, then close it.
- Context-state accounts. Verify a proof once into a dedicated account whose size must match the context exactly, reference that account from later instructions, and close it afterwards. Closing reassigns the account to the system program, so its address is reusable.
- Transaction v1. The new format raises the ceiling to 4,096 bytes, enough to carry a full proof set inline. Confidential transfers are one of the explicit motivations in the proposal, and v1 activated on mainnet on 15 September 2026 (epoch 1035), so the multi-transaction dance is now optional.
Each workaround leaves accounts behind. Context-state and proof accounts hold rent, and closing them returns it — a small, recurring reclaim that the confidential-transfer tooling of the future should do for its users automatically.
Reading Your Own Balance
A confidential balance is decryptable only by the holder's ElGamal key, and decrypting an ElGamal ciphertext is not a single operation: the implementation recovers the amount with a 32-bit baby-step giant-step search, with a precomputed table, bounded so that a phone can do it in around a second. Wallets that show a confidential balance instantly are showing a cached value. The honest number is the decrypted one, and it costs a moment.
Confidential Transfers: Questions People Actually Ask
Can Solana confidential transfers be disabled?
Yes. A feature gate removes the ZK ElGamal proof program, which every confidential operation depends on, and a second gate restores it. Both have been used: disabled on 19 June 2025 at the start of epoch 805, re-enabled on 4 June 2026 at the start of epoch 982.
What happens to my confidential balance if the proof program is disabled?
It stays encrypted in your account and cannot be moved or withdrawn to a plain balance until the program is re-enabled. Plain balances on the same mint are unaffected.
How much compute does a Solana confidential transfer use?
The range proof alone is 111,000 to 368,000 units depending on bit width, plus several smaller proofs. A plain token transfer is a few thousand units.
Why do confidential transfers need transaction v1?
A range proof is 672 to 800 bytes and a legacy transaction is capped at 1,232 bytes. Version 1 transactions allow 4,096 bytes, enough for a full proof set in one transaction.
What to Decide Before Using a Confidential Balance
- Understand the dependency. Your confidential balance is safe in either state of the switch, and inaccessible in one of them. If you need the ability to exit at any moment, keep part of the position plain.
- Budget the compute. A confidential transfer costs a hundred times a plain one in units; set the limit from a simulation and expect the fee to reflect the space.
- Prefer v1 transactions, live on mainnet since 15 September 2026, and reclaim the proof and context accounts either way.
— Two Gates, One Consequence —
The day either flips, every confidential balance changes state at once.
Both the disable and the re-enable gate are feature accounts like any other. The upgrades tracker reads them from the chain every minute and shows which state each cluster is in.
Compute prices and sizes read from the Agave validator source at commit beee69b958: programs/zk-elgamal-proof/src/lib.rs and feature-set/src/lib.rs. The disable and re-enable dates are read from the two feature accounts on mainnet-beta, checked on 17 September 2026; the incident that prompted the sequence is covered in the native-vs-rings post.
