The mint-creation opt-in decides which Solana tokens can ever go confidential

Token-2022 keeps confidential transfers in the mint extension set, and extensions are chosen when the mint is initialized ^[10]. The Solana documentation states the rule without hedging: "Most extensions can't be added after an account is initialized" ^[10]. A token already in circulation cannot grow a confidential mode, and a legacy SPL mint never can ^[10]. So any stablecoin that ends up supporting this either shipped with the extension or arrives as a new mint at a new address ^[11]. Rings has no such gate: it takes SOL and any SPL or Token-2022 mint ^[9].

On a mint that did opt in, the holder's side is bookkeeping. Configuring an account derives two keys the wallet has to keep: an ElGamal keypair for the ciphertext balance, and an AES key for a private copy the owner can decrypt quickly ^[12]. Incoming funds land in a pending balance and become spendable only when the owner sends an apply instruction, which is what stops a payer from invalidating a transfer you are halfway through proving ^[13]. A counter limits how many credits can stack up before you must apply, and the documented default is 65,536 ^[14].

The amount ceiling is 48 bits, because ElGamal decryption slows as the number grows ^[15]. That works out to 281,474,976,710,655 base units, or roughly 281.47 million whole tokens per transfer on a six-decimal mint ^[17]. Comfortable for payments. A settlement flow larger than that per instruction has to split it.

Where the proof gets built is the other decision. Native proofs are built by your client and cost three transactions per transfer; the Rings demo needs one, because a Helius server builds the proof ^[7]. Three-to-one on transaction count ^[18] is a real ergonomics gap, and it is bought with dependencies: a program Helius deployed, its own state tree and key material, a registry to find recipients, and an indexer to read your own balance ^[16]. The native design keeps every existing account, wallet address and token standard, and in exchange cannot hide who paid whom ^[16].

For the devnet ergonomics to carry into production, the Helius program has to exist on mainnet, and as of the September 9 read it does not ^[8]. The proof server also has to be something you are willing to place in the payment path, which is a governance question rather than a benchmark.

One caveat covers all of the above: this is a single dev.to writeup's reading of the Helius documentation and source, the Solana and Anza docs, the audit records and mainnet itself, dated September 9, 2026 ^[4]. Its own framing is the right posture, that "a status that is true in September is a lie by November" ^[19]. Epoch 982 is the anchor for the native feature being live ^[8]. Check the chain against that number before anyone writes a roadmap on it.