Feature Proposal: Confidential Permanent-Delegate Extension

[wowinter13]

Recreated from solana-labs/solana-program-library#6880

(Reopened this one as it looks promising and is still missing)

Proposed feature

Token-2022 adds the token-extension of confidential transfers. For normal token transfers Token-2022 further adds the permanent-delegate extension, which allows granting a signer the authority to move tokens from any token account belonging to a mint at will. This functionality is however not present for confidential balances.

Adding an authority with "root-access" should also be possible for the confidential balances of a mint.

Proposed solution

A confidential-permanent-delegate extension, which adds an authority with the ability to move tokens in the confidential balance of any token account from the mint.

There is one main problem to adding this logic, which is that to move funds in a confidential balance the balance encryption keys (ElGamalKeypair & AeKey) are required to generate the relevant zk-proofs. So in order for the permanent delegate to be able to move funds, these secret keys have to be shared with the holder of the authority.

The proposed solution to the secret sharing issue is to by default set the approved flag on the confidential balance to false if the confidential-permanent-delegate is activated on a mint. The normal Approve instruction would then also be disabled and the approving of accounts could only be done via an ApproveAccount instruction processed within the new extension.

FYI: @abcalphabet

[Idria05]

Yes a im marketing

[Parad0x-Labs]

Strong interest here — we're building dark_shielded_pool on top of Token-2022 with a confidential balance layer for NULL token (8EeDdvCRmFAzVD4takkBrNNwkeUTUQh4MscRK5Fzpump). A confidential permanent-delegate would directly enable:

• Compliant emergency withdrawal — DAO-controlled revocation of shielded notes without exposing the full privacy model
• Agent authorization flows — permissioned agents that can act on confidential balances under protocol governance

Two technical questions:

1. Mint-level vs account-level: Is the delegate authority scoped per-mint (all accounts inherit it) or could it be overridden per token account? A mint-level authority fits our compliance model, but account-level opt-out would be useful for self-custodied users.

2. ZK proof generation: The secret-sharing concern is the hard part. Does the delegate need the plaintext balance + ElGamal keypair to construct the proof, or is there a path where the account owner pre-generates an encrypted "escape hatch" proof the delegate can submit without ever seeing the plaintext? The latter would preserve the privacy model far better.

Happy to help spec or prototype once ZK ElGamal is re-enabled on-chain.

Repo: https://github.com/Parad0x-Labs/dna-x402 (see dark_shielded_pool)