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 application’s 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 instance’s processes or administrators cannot access. Enclaves have no persistent storage, interactive access, or external networking.
AWS’s 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 SDK’s pinned signers. Signed policies refresh during attestation and expire after use.
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 operator’s 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 proof’s 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.
Helius’s 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.