Helius Launches Encrypted Solana Payments on Mainnet, With Operator Trust Still Required

Helius activated its permissionless Privacy Ring on Solana mainnet on Nov. 10, encrypting payment assets and amounts while leaving sender and recipient wallet addresses visible. The system's documented default prover—the service that constructs zero-knowledge proofs—adds a hardware requirement: secret transaction inputs are processed inside an attested AWS Nitro enclave, an isolated computing environment.

Because Solana's ledger is public and its recorded transfers are observable by anyone, encrypting assets and amounts addresses the most directly sensitive fields of a payment, even as the addresses on either side stay visible.

Solana can verify that a transfer satisfies the protocol's rules, but protecting the inputs while the proof is generated depends on the prover's isolation, its code, and its deployment policies.

What Reaches the Proving Service

For wallet developers integrating the launch, the practical question is which of those protections their software can actually verify. Their choices—local or delegated decryption, remote or client-side proof generation—determine which parts of a transaction their users must trust to others.

Helius's wallet integration guide states that 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.

The protocol specification lists private inputs that include 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 incorporates output assets, amounts, and blinding values.

Those inputs become readable to the proving code inside the enclave. The documented client shields 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 to the application's signer. Helius documents two decryption modes: local decryption, which keeps the viewing key on the device, and delegated decryption, which shares a viewing key with an authorized provider. Delegation grants that provider read access to balances and history without conferring spending authority.

How the Enclave Model Works

AWS describes Nitro Enclaves as isolated environments whose memory cannot be accessed by the parent instance's processes or administrators. Enclaves have no persistent storage, interactive access, or external networking. AWS's signed attestation document contains cryptographic fingerprints of the enclave's image and software.

Because proof construction is the step where the private inputs exist in plaintext, the prover's environment is where the enclave design concentrates its protections.

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 attestation before making any HTTP call. A wallet can pin a reviewed release policy or adopt a network policy authenticated by the SDK's pinned signers. Signed policies refresh during attestation and expire after use.

Where Trust Still Rests

A wallet can automatically confirm 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.

According to the Nitro deployment guide, the measured image includes the prover, startup script, certificate bundle, allowed external hosts, indexer URL, and KMS key identity. The design uses AWS Key Management Service to release the shared encryption seed only to enclaves with a matching attestation. Clients cannot read the KMS key policy, the guide notes, and instead 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 instance, including 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 permits client-side proofs, and the repository supplies localnet tooling and downloadable prover binaries.

Helius's launch announcement says Certora, zkSecurity, and OtterSec audited the programs and circuits. Its security page lists Certora's audit in October and zkSecurity's in August, while marking OtterSec's report as pending. For teams evaluating the launch, the documented items to track are the pending OtterSec report, the gap between the v0.6.0-alpha mainnet build and the ts-sdk-v0.8.0-alpha documentation tag, and whether integrations adopt pinned release policies, network policies, or the specification's client-side proving option.

The launch leaves wallet developers with a trust decision: which code and which deployment policy they approve to handle proof inputs.

Source: CryptoNewsNet | Originally reported by CryptoSlate