Institutional Privacy on Solana: Confidential Transfers, Prop AMMs

TL;DR

• Solana privacy consists of two things: hidden transaction data (Confidential Transfers) and hidden trading intent (proprietary AMMs). 
• Privacy could range from pseudonymity (public addresses and amounts) through confidentiality (amounts hidden, participants visible) to anonymity (identities and links obscured). 
• Confidential Transfers encrypt token amounts using twisted ElGamal plus Pedersen commitments. The amount is hidden, while the sender, recipient, timing, and fact of each transfer stay public, so this is confidentiality without anonymity.
• Because addresses and timing stay public, base-layer confidentiality alone cannot hide who is paying whom. That is why it fits regulated stablecoin issuers but not, on its own, private payroll.
• The ZK ElGamal Proof program was feature-gated off at epoch 805 in June 2025 after a proof-forgery flaw, with no exploit in the wild. The patch shipped in Agave v2.1.21, and reactivation is scheduled for the Agave 4.x window in Q3 2026, so verify against mainnet before relying on it.
• Proprietary AMMs hide order flow and inventory while settling publicly on-chain. Their share of Jupiter-routed volume rose from roughly 40% in mid-2025 to more than 80% by late 2025, though they are a smaller 20% to 40% of total Solana DEX volume.
• Everstake operates institutional Solana infrastructure, including Blockspace, certified under SOC 2 Type II and ISO 27001:2022.

Why confidential transfers are becoming important now

Solana is increasingly being positioned as infrastructure for institutional finance and payments, and that exposes a fundamental problem with fully transparent blockchains.

Institutions generally do not want anonymous transactions. They want confidential transactions: the ability to prove that a transaction is legitimate while keeping commercially sensitive information private.

Two Kinds of Privacy on Solana: Hidden Data and Hidden Intent

Privacy on Solana can be divided into data privacy and market privacy. Data privacy concerns what is hidden inside the transaction record, such as the amount moved between two accounts.

Market privacy concerns what is hidden in order flow and trading intent before a trade ever settles.

Calling Solana‘s privacy “confidential transfers” describes only the data side, while the market structure is where more than half of the real privacy activity happens, measured by volume. Most privacy on Solana today lives in how trades are routed and quoted.

Dimension	Data privacy (Confidential Transfers)	Market privacy (proprietary AMMs)
What is hidden	Transfer amounts and balances	Order flow, inventory, trading intent
What stays public	Addresses, timing, fact of transfer	On-chain settlement of each fill
Mechanism	Twisted ElGamal plus zero-knowledge proofs	Single-operator private liquidity
Compliance hook	Auditor or viewing keys	Operator policy and venue selection
Primary user	Regulated token issuers	Market makers and large traders

How Confidential Transfers Encrypt Amounts

Confidential Transfers hide token amounts while proving every transfer is valid. The extension is part of Token-2022 and keeps an encrypted state on the tokens themselves.There is no separate privacy network, and the assets never leave the base layer.

The encryption uses twisted ElGamal over curve25519, paired with Pedersen commitments. The “twist” makes balance updates homomorphic, meaning the network can add to or subtract from an encrypted balance without ever decrypting it.

The value moved between two accounts is encrypted, so the network cannot see the amount to check whether the transfer is valid. The three zero-knowledge proofs let it verify correctness without revealing the number.

Each guarantees a different property, and all three are required for a valid transfer:

1. Validity proof confirms the ciphertexts are well-formed and decryptable by the correct keys.
2. Range proof confirms the hidden amount is non-negative and within bounds, blocking a secret overflow.
3. Equality proof confirms the new balance ciphertext matches its Pedersen commitment after the transfer.

The user-facing lifecycle moves through four stages. Funds start public, become encrypted, move under encryption, then return to public form:

1. Deposit moves public tokens into the confidential balance.
2. Apply finalizes pending credits into the available encrypted balance.
3. Transfer sends an encrypted amount to another configured account.
4. Withdraw converts the confidential balance back to a public one.

Confidential Transfers hide the amount, while the sender address, the recipient address, the timing, and the fact that a transfer happened all stay public on-chain.

Issuers can also designate an auditor key that decrypts amounts for oversight.

The Reactivation Story: From Disabled to Live

The ZK ElGamal Proof program is currently disabled on mainnet, here’s why:

• In June 2025, researchers found that a component was omitted from the Fiat-Shamir transcript hash.
• That omission let a party construct forged proofs that would pass verification.
• A forged proof could, in principle, mint tokens without backing or drain a confidential balance. Out of caution, the program was feature-gated off at the start of Mainnet-Beta epoch 805 in June 2025.
• No exploit occurred in the wild, and no user funds were impacted or lost.
• The practical impact was limited by how little the feature was used. The confidential extension had been initialized by an issuer (Paxos) but was not open to general users.

The vulnerability patch already shipped and is resolved across the major clients:

• Agave at v2.1.21 or later
• Jito-Solana at v2.1.21-jito or later
• Firedancer at v0.411.20121 or later

What remains pending is the feature-gate reactivation of the program itself. Reactivation is scheduled in the Agave 4.x window during Q3 2026, tracked separately from the exact timing of Alpenglow.

Support for ZK ElGamal in Web3.js was only added in July 2026, so full executability is close but unconfirmed. Currently, the code is patched and hardening toward re-enable, and it is not yet executable for users.

Confidentiality Without Anonymity: Why Regulated Issuers Prefer It

Confidential Transfers give regulated issuers a feature, and the design choice is deliberate. Amounts are hidden from the public, while participants stay visible, disclosing just the right amount of information. 

The selective-disclosure hook is the auditor or viewing key. An issuer designates a key that can decrypt transfer amounts for an auditor or regulator, without exposing those amounts to anyone else. Read more about it in the article on why privacy is the financial default for institutions.

Only future transfers are affected by key rotation. Historical amounts stay encrypted under the prior key, so rotating a key does not retroactively expose or re-lock old records.

Paxos offers a worked example with its USDP stablecoin. A regulated issuer can pair confidential amounts with the Permanent Delegate extension for clawback and freeze authority, aligning with obligations such as NYDFS oversight of a New York-regulated stablecoin.

The design has one ceiling worth stating plainly: the transaction graph of who paid whom, and when, stays visible on-chain even though amounts are hidden.

That graph is the public record of which addresses sent funds to which others, so patterns of activity remain traceable even when the sums are secret.

Configurable Privacy: Rings and Private Rollups

When base-level confidentiality is not enough, an application layer lets an operator tune the confidentiality and compliance tradeoff per deployment. Two systems show this pattern on Solana above Confidential Transfers.

Helius Privacy Rings expose a per-ring policy with a non-custodial operator model. A ring can be configured in a confidential mode, where amounts are hidden, or an anonymous mode, where links between participants are obscured as well.

The operator does not take custody of user funds.

MagicBlock private ephemeral rollups take a different route to the same goal. They run private execution inside a trusted execution environment (TEE), a hardware-isolated area of a processor that keeps computation confidential even from the machine’s operator, before results settle back to Solana.

Privacy on Solana is becoming configurable per deployment and not at the protocol level. So each operator sets its own confidentiality and compliance rules.

These systems also expose compliance hooks such as:

• allow and block lists
• know-your-transaction (KYT) screening
• geographic controls

Proprietary AMMs: Privacy as Market Structure

Proprietary AMMs are the largest privacy story on Solana by real volume. A proprietary or “dark” AMM is single-operator private liquidity that settles on-chain the same way as any other trade.

A pricing curve is the formula an ordinary AMM publishes to set its prices, and hiding it is what makes a proprietary venue “dark.” It publishes no public pricing curve, so competitors cannot read its quotes off-chain.

The privacy here is pre-trade. Order flow, inventory, and intent are hidden before execution, while the settlement of each fill still lands publicly on-chain.

The protected thing is information asymmetry, which is why this counts as privacy at all.

Proprietary-AMM share of Jupiter volume ran near 40% in mid-2025, per The Defiant and Delphi Digital.

By late 2025 it rose above 80% on Jupiter at its peak, per SolanaFloor.

In core SOL-stablecoin pairs the proprietary-AMM share exceeds 80%, per Gate Research in 2026.

Leadership among venues also rotates quickly, with BisonFi overtaking HumidiFi as the top venue by early 2026.

Why Prop AMMs Exist: MEV, Spreads, and Information Leakage

Proprietary AMMs exist to solve information leakage in public trading. A public pricing curve lets anyone read a market maker’s quotes and act against them.

Proprietary AMMs withhold that information, which reduces the flow that works against the operator.

Hiding order flow defends against:

• MEV extraction, where a searcher reorders transactions for advantage.
• Front-running, where an observer trades ahead of a visible order.
• Sandwich attacks, where an order is bracketed by trades that move the price.

Tighter quoting is the visible result for users with slippage as low as 0 to 0.5 bps (basis points, where one basis point is 0.01%) on major pairs through proprietary AMMs, a level that rivals centralized order books.

Large orders can also execute without sweeping a public curve, which reduces market impact.

Proprietary AMMs are the market’s answer to the same transparency problem that Confidential Transfers solve cryptographically. One hides amounts with encryption, and the other hides intent with private liquidity.

Both address a single institutional need to trade and transact without broadcasting sensitive information.

For Solana MEV tools suite for searchers and validators, explore Blockspace.

Where Encryption Meets the Order Book: FHE Dark Pools

Fully homomorphic encryption (FHE) dark pools point to where the two kinds of privacy start to merge. Proprietary AMMs solve leakage by trusting an operator to hold private inventory and quotes.

An FHE-based dark pool removes that trust assumption by processing encrypted orders inside the contract itself.

The mechanism is the difference. Orders arrive encrypted, the matching logic runs over ciphertext without decrypting, and the venue never sees the raw order.

Data privacy and market privacy combine in one system when this works.

NOTE: This category is emerging. Treat FHE dark pools on Solana as a forward-looking design direction rather than production infrastructure available today.

What Validators Handle as Privacy Grows

Validators take on new responsibilities as privacy features expand across Solana. Encrypted mempools and private relays move order flow off the public path at the network level, so pending transactions are no longer broadcast in the open for anyone to inspect before they confirm.

Zero-knowledge verification adds computational overhead to block production, which, as we expect, would raise the bar on validator performance.

Everstake has operated institutional-grade Solana infrastructure since the network’s testnet. Our Solana expertise spans beyond securing the network.

Everstake holds SOC 2 Type II and ISO 27001:2022 certifications, maintains GDPR compliance, and runs regular smart contract audits, with independent audit work conducted by Prescient Security.

These standards, alongside frameworks such as NIST CSF, address the security and governance controls institutions require. For institutions weighing Solana infrastructure, the compliance posture and the low-latency execution products are the two important things that relate to the privacy changes described here.

FAQ

Are Solana confidential transfers live right now?

Not yet for general users, as of Q3 2026. The ZK ElGamal Proof program that verifies Everstake-relevant Confidential Transfers was feature-gated off at epoch 805 in June 2025 and remains disabled on mainnet.

The vulnerability patch shipped in Agave v2.1.21, and reactivation is scheduled for the Agave 4.x window, so verify the live status against mainnet before relying on it.

What is the difference between a prop AMM and a privacy protocol?

A proprietary AMM hides trading intent and order flow, while a privacy protocol hides transaction data such as amounts. A proprietary AMM on Solana still settles every fill publicly on-chain, so it delivers market privacy over trading intent.

Do prop AMMs hide my transaction on-chain?

No. A proprietary AMM hides the operator’s inventory and quotes before a trade, while the settlement of your fill lands publicly on Solana.

Is Solana private enough for institutional payroll?

Partly. Confidential Transfers can hide salary amounts, while sender and recipient addresses, timing, and the fact of each transfer stay visible on-chain.

For payroll that also needs to obscure who is being paid, base-layer confidentiality alone is not sufficient, and the feature is not yet live as of Q3 2026.

What happens when the ZK ElGamal program reactivates?

Reactivation re-enables on-chain verification of the proofs that make Confidential Transfers work. Once the feature gate flips in the Agave 4.x window and client support such as Web3.js, updated in July 2026, is in place, issuers and users can encrypt token amounts on mainnet again.

Disclaimer:
Everstake is a software platform that provides infrastructure tools and resources for users but does not offer investment advice or investment opportunities, manage funds, facilitate collective investment schemes, provide financial services or take custody of, or otherwise hold or manage, customer assets. Everstake does not conduct any independent diligence on or substantive review of any blockchain asset, digital currency, cryptocurrency or associated funds. Everstake’s provision of technology services allowing a user to stake digital assets is not an endorsement or a recommendation of any digital assets by it. Users are fully and solely responsible for evaluating whether to stake digital assets.