Helius Encrypts Solana Proof Requests, but Trust Remains

By Nathan Brooks

Helius has launched a Solana transfer-privacy integration whose remote prover runs inside an attested AWS Nitro enclave, according to the company’s wallet integration guide and launch announcement.

Helius’s guide identifies the enclave as the SDKs’ default prover. The operative question for integrators is which protections their software can enforce before a remote proof request leaves the device.

What does this change for wallet developers?

Helius’s guide says proof generation requires plaintext covering the complete transaction data and nullifier keys. The protocol specification identifies the asset, amount, blinding values and nullifier secret for notes being spent, plus paths proving that those notes belong to the state tree.

The proof also includes output assets, amounts and blinding values. Those private inputs become readable to the proving code inside the enclave, so the documented client encrypts 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, while the TypeScript SDK leaves signing the finished Solana transaction to the application’s signer.

Helius documents two viewing-key models:

• Local decryption keeps the viewing key on the device.
• Delegated decryption shares a viewing key with an authorized provider, giving 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.” The enclaves have no persistent storage, interactive access or external networking.

The signed attestation document contains cryptographic fingerprints of the enclave image and software. Helius’s Privacy Rings checks verify:

• the certificate chain;
• challenge response and freshness;
• approved measurements; and
• the binding of the request-encryption key.

The tagged SDK rejects a remote prover request that lacks the required signed document 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. Those controls let a wallet reject an unapproved image or key binding before transmitting sensitive proof material, rather than treating operator deployment as sufficient assurance.

Where trust still rests

Verification still depends on the wallet developer’s confidence in the code, its reviewers and the image selected for approval. The measured image includes:

• the prover;
• the startup script;
• the certificate bundle;
• allowed external hosts;
• the indexer URL; and
• the AWS Key Management Service key identity.

AWS Key Management Service releases a shared encryption seed only to matching attested enclaves. The deployment guide says clients cannot read the KMS key policy and must rely on the operator’s deployment for that guarantee.

Helius identifies four trust roots during initial policy binding:

• AWS KMS;
• AWS Support;
• Nitro hardware; and
• the operator.

A wallet can therefore remove unapproved code from the execution path without removing the operator from the initial trust chain.

Encryption also does not conceal all request metadata from the parent instance. Paths, queries, timing and sizes remain visible, and the path reveals the proof’s circuit shape. The confidentiality boundary covers request contents, not every observable feature of the request.

What is ready for mainnet?

The versioned trusted-execution-environment guide records a mainnet build based on v0.6.0-alpha, with measured-build provenance. That version is distinct from the ts-sdk-v0.8.0-alpha documentation tag.

The specification allows client-side proofs, and the repository provides localnet tooling and downloadable prover binaries. These options give wallet teams a path to reduce or avoid reliance on the remote enclave, subject to their own deployment and verification choices.

Helius’s launch announcement says Certora, zkSecurity and OtterSec audited the programs and circuits. Its security page lists Certora in October and zkSecurity in August, while marking OtterSec’s report as awaited.

For wallet developers, the change is from trusting an operator’s assertion to enforcing attestable execution, while still approving the underlying code and deployment policy. As wallet teams standardize those approvals, the market structure shifts from operator assurances toward cryptographically checked code and key bindings, although the operator remains an initial trust root.