Confidential Balances research
Current official network status, visibility boundaries, and future integration requirements.
Confidential settlement is explicitly deferred. The current expansion adds factory, curve, swap modes, and zaps using classic SPL reserves. This page preserves research and does not advertise confidential AMM support.
Research checked 2026-10-08. Unsupported by grapl. The current program accepts classic SPL Token accounts only. A Token-2022 Cargo feature used by Anchor macros does not enable Token-2022 settlement, confidential transfers, or hidden AMM state.
Current official status
The current Solana technical guide explicitly says the ZK ElGamal Proof Program is enabled on mainnet and devnet. It also distinguishes local runtimes: a stock solana-test-validator does not enable it. The Token-2022 status page says the latest program, including confidential transfers, is deployed on all clusters and requires that proof program. These are current technical documentation statements, rather than an inference from an older launch announcement. Solana runtime requirements, Token-2022 project status.
This is a dated documentation finding. No confidential transaction, mainnet deployment, live feature-gate inspection, or grapl compatibility test was performed for this page. Before implementing against a cluster, verify its runtime/program state and execute the exact proof/transfer flow on an authorized isolated environment.
Names and responsibilities
Confidential Balances is the feature name in current documentation; ConfidentialTransferMint and ConfidentialTransferAccount remain extension/state names. The Token-2022 program applies token state transitions. The native ZK ElGamal Proof Program verifies proofs concerning encrypted values and commitments; it is not a generic private AMM executor. Solana overview, Anza proof-program reference.
| Layer | What it establishes | What it does not establish |
|---|---|---|
| Confidential transfer | Correct encrypted token movement with the required proofs | Anonymous participants or hidden transaction participation |
| Token account | Public, encrypted pending, and encrypted available balances | Immediate spendability of pending credits |
| Optional mint auditor | Ability to decrypt transfer amounts under its key | Spending authority or full account-balance disclosure |
| grapl CLMM | Public price, ticks, liquidity, positions, and ordinary token settlement | Encrypted reserves, private ranges, or a confidential quote path |
Token account addresses, mints, owners, and participation remain public. Encrypting token amounts does not automatically hide the application's other state. Solana overview.
The token flow
The ordinary confidential flow configures the mint and accounts, deposits public tokens into pending balance, applies pending credits, transfers from available balance, applies the recipient's credits, and optionally withdraws to public balance. Pending credits cannot be spent directly. Token-2022 usage.
Proof generation requires client-side secret material. Verification may use inline proof instructions or verified context-state accounts; the exact transaction plan depends on supported clients, format, and budgets. Deposits and withdrawals expose amounts. Confidential mint/burn changes the boundary further by disabling the public deposit/withdraw path. Integration guide.
Compatibility with the current pool
All Token-2022 accounts are outside the present settlement contract, including their public balances. Withdrawing a confidential balance to a public Token-2022 balance does not make that account a classic SPL account. An extension-enabled mint cannot be treated as a different token program by changing a client flag.
Even a future public Token-2022 settlement path would expose the traded amounts and CLMM state at the pool boundary. Hiding reserves, positions, or price transitions would require a different state/verification design and an explicit quote-availability model. That conclusion is an architectural inference from the current public state and the extension's documented scope, not an advertised grapl feature.
Future adapter boundaries — design only
The proposed separation is between custody/balance handling and transfer settlement. No adapter API or implementation is claimed here.
| Responsibility | Required design |
|---|---|
| Custody and balances | Separate public, pending, available, withheld, and fee-debt amounts; define spendability |
| Key control | Define who can decrypt and produce proofs; a PDA signature alone is not a confidential decryption key |
| Transfer adapter | Bind mint/program, source, destination, amount/commitment, proofs, and authorization |
| Proof lifecycle | Validate context ownership and operation binding, freshness, cleanup, replay behavior, and budgets |
| Public AMM boundary | Explicitly state what becomes visible and require compatible token settlement |
| Quote adapter | Preserve deterministic executable pricing; reject unknown balances/policies instead of guessing |
| Accounting | Reconcile actual settlement with LP principal, fees, beneficiaries, and failed-transaction rollback |
Custody providers and wallet clients need an explicit key recovery and authorization model. Do not store decryption keys or derivation signatures in logs, fixtures, or documentation. The issuer's auditor policy is a separate trust decision. Issuer guide.
Verification gates
Any future support needs isolated proof lifecycle tests, public/confidential boundary tests, token-extension composition tests, solvency and rollback checks, and quote/execution parity for every advertised path. Network availability and an upstream audit do not establish any of those properties for grapl.