Helius launched its permissionless Privacy Ring on Solana mainnet on Nov. 10 with encrypted payment assets and amounts, while sender and recipient wallet addresses remain visible.
Related Asset Solana #7 SOL · $81.35 24-hour change: down 4.24% Loading price history… 24H Down 4.24% 7D Down 9.78% 30D Down 23.98%
Its documented default prover, the service that constructs zero-knowledge proofs, adds a hardware requirement where secret transaction inputs are processed inside an attested AWS Nitro enclave, an isolated computing environment.
Solana can check that a transfer satisfies the protocol‘s rules, but protecting the inputs while that proof is made depends on the prover’s isolation, code, and deployment policies.
The practical question for wallet developers integrating the launch is which of those protections their software can verify.
What reaches the Solana prover
Helius‘s wallet integration guide says proof generation needs plaintext inputs covering the complete transaction data and nullifier keys. It identifies an attested AWS Nitro enclave as the SDKs’ default prover.
The protocol specification lists private inputs including the asset, amount, blinding values, and nullifier secret for notes being spent, along with paths proving those notes belong to the state tree. The proof also includes output assets, amounts, and blinding values.
Those inputs become readable to the proving code inside the enclave, and the documented client protects them from the host operator by encrypting requests to a key held by the attested enclave.
The nullifier secret also derives the markers used to prevent repeat spending. In the native wallet integration, the wallet retains the signing key, and the TypeScript SDK leaves signing of the finished Solana transaction with the applications signer.
Helius documents local decryption, which keeps the viewing key on the device, and delegated decryption, which shares a viewing key with an authorized provider. Delegation gives that provider read access to balances and history, without granting spending authority.
AWS describes Nitro Enclaves as isolated environments whose memory the parent instances processes or administrators cannot access. Enclaves have no persistent storage, interactive access, or external networking.
AWSs signed document contains cryptographic fingerprints of its image and software. The documented Privacy Rings checks verify the certificate chain, challenge response and freshness, approved measurements, and the binding of the request-encryption key.
The tagged SDK refuses a remote prover request without one, before making an HTTP call. A wallet can pin a reviewed release policy or use a network policy authenticated by the SDKs pinned signers. Signed policies refresh during attestation and expire after use.
Secret inputs travel. Signing authority stays.
Heliuss documented default path sends encrypted proof inputs into an AWS Nitro enclave, then returns the proof to the wallet before transaction signing.
Encrypted proof inputs make a round trip; the wallet keeps signing authorityDOCUMENTED DEFAULT PROVING PATHWalletAWS Nitro enclaveEncrypted inputsTransaction data + nullifier secretsProof returns to walletSigning keystays in the walletWallet builds + signsProof travels with the transactionSolana verifiesProof + owner authorization
Plaintext proof inputsprocessed inside
Proof validity does not certify prover confidentiality.
The wallet encrypts inputs for the enclave, receives a proof and signs the Solana transactionDOCUMENTED DEFAULT PATH
WalletSigning key staysin the wallet
Encryptedtx data +nullifier secretProofreturns
AWS Nitro enclavePlaintext proof inputsprocessed insideWallet builds + signsTransaction carries the proofSolanaProof + owner authorization verified
Proof validity does not certifyprover confidentiality.
Inspect the verification boundaryInspect the verification boundaryWallet checksDeployment trust
The client verifies attestation against an approved policy before encrypting remote proof requests.
Wallet checks against an approved policy
Certificate + challengeCheck identity and freshnessSoftware measurementsMatch the approved imageEncryption-key bindingInputs go to the attested keyApproving the code remains a trust choice.
Wallet-side attestation checks
1Certificate + challengeIdentity and freshness2Software measurementsMatch the approved image3Encryption-key bindingInputs go to the attested key
Approving the code remains a trust choice.
Code review, AWS isolation and the operators initial KMS policy binding underpin the documented confidentiality design.
Trust dependencies behind confidential proving
Reviewed code
AWS isolation
Operators KMS bindClients cannot inspect the KMS key policy.Attestation checks do not remove this deployment dependency.
Dependencies behind confidential proving
1Reviewed codeConfidence in implementation2AWS isolationHardware + platform guarantees3Operators KMS bindClient cannot read the key policy
These dependencies remain after attestation.
Wallets check an approved enclave and key; code review and deployment policy remain separate dependencies.
Documented default configuration only, not independent live attestation or an audit. Other proving or authorization paths can differ. Native wallet signing, remote proving and balance-viewing access have separate roles.
Sources and evidence
Sources
- Private Wallet
- Solana Privacy Rings protocol specification
- TypeScript SDK README at ts-sdk-v0.8.0-alpha
- Encryption and Privacy Guarantees
- TEE prover README at ts-sdk-v0.8.0-alpha
- Nitro Enclave prover deployment guide
- What is Nitro Enclaves？
- Cryptographic attestation
- Helius‘s wallet integration guide says proof generation requires plaintext inputs covering the complete transaction data and nullifier keys, and identifies an attested AWS Nitro enclave as the SDKs’ default prover. [1]
- The protocols private proof inputs include spent-note asset, amount, blinding, nullifier secret and Merkle path, plus output asset, amount and blinding; these are secret inputs used to construct the proof rather than data revealed by the proof onchain. [2] [1]
- In the documented native wallet integration, the wallet retains its Solana signing key; the tagged TypeScript SDK says the finished Solana transaction is signed by the applications signer. [1] [3]
- Nullifier secrets help derive the markers that prevent repeat spending; they are distinct from the owner signature that authorizes a normal default-ring spend. [4] [2]
- The tagged SDK requires an application-supplied TEE policy before making a remote prover request and encrypts calls to the attested key; a missing remote policy fails before HTTP. [3] [5]
- The documented attestation checks cover the certificate chain, nonce, freshness, approved enclave measurements and the binding of the HPKE encryption key; trust pins must come from an approved policy rather than the provers response. [3] [5] [6]
- AWS says Nitro isolates enclave memory from the parent instance, including root or administrator users, and provides no persistent storage, interactive access or external networking inside the enclave. [7]
- The Nitro deployment guide says the measured image includes the prover binary, startup script, certificate bundle, permitted egress hosts, indexer URL and KMS key identity; PCR0 to PCR2 bind these bytes. [6] [8]
- The Nitro design releases a shared encrypted seed through AWS KMS only to matching attested enclaves; its guide explicitly says a client cannot read the KMS key policy and relies on the operators deployment for that guarantee. [6]
- The SDK supports either a reviewed policy JSON pinned by the application or network policies authenticated by pinned signers through SignedTeePolicy; signed policies are refreshed during attestation and are not used after expiry. [3] [5]
- The Nitro guide says the parent cannot read properly encrypted proof requests or responses, but can see paths, queries, timing and sizes; the path reveals the circuit shape. [6]
- For ordinary owner-authorized transfers, the protocols proof checks include note inclusion, nullifier non-inclusion, owner authorization and balance conservation; successful proof verification does not itself verify the confidentiality of the machine that generated the proof. [2] [6] [8]
Supporting facts
Method
Qualitative data-flow diagram of the documented native-wallet default prover. No numerical scale or calculated values. The selectable panel distinguishes client attestation checks from code, hardware and deployment trust dependencies.
Scope
Documented default configuration only, not independent live attestation or an audit. Other proving or authorization paths can differ. Native wallet signing, remote proving and balance-viewing access have separate roles.
Infographic by CryptoSlate
Where Solana's deployment trust remains
A wallet can automatically check that the enclave matches an approved software image and encryption key, yet deciding which image to approve still requires confidence in the code and its reviewers.
The Nitro deployment guide says the measured image includes the prover, startup script, certificate bundle, allowed external hosts, indexer URL, and KMS key identity. Its design uses AWS Key Management Service to release the shared encryption seed only to matching attested enclaves.
The guide says clients cannot read the KMS key policy and rely on the operators deployment for that guarantee. It identifies AWS KMS, AWS Support, Nitro hardware, and the operator as trust roots during initial policy binding.
Even correctly encrypted requests leave metadata visible to the parent, such as paths, queries, timing, and sizes. The path reveals the proofs circuit shape.
The versioned TEE guide records a mainnet build based on v0.6.0-alpha, with measured-build provenance, distinct from the ts-sdk-v0.8.0-alpha documentation tag.
The specification allows client-side proofs, and the repository supplies localnet tooling and downloadable prover binaries.
Heliuss launch announcement says Certora, zkSecurity, and OtterSec audited programs and circuits. Its security page lists Certora in October and zkSecurity in August, while marking OtterSec as awaiting a report.
The launch gives wallet developers a trust decision on which code and deployment policy they approve to handle proof inputs.