What is Nimbus

Nimbus is a set of Solana programs, zero-knowledge circuits and supporting services that give you a private balance on Solana. Inside it, who paid whom, how much, in which token and out of which notes are not visible to anyone watching the chain, while getting tokens in and out stays public.

The problemCopy Anchor Link

Solana is a public ledger. Every token account's balance, every transfer's sender, recipient and amount, and the history behind all of them can be read by anyone, and they stay readable permanently. That openness is what makes settlement verifiable, and it is also what makes ordinary financial activity uncomfortable to put on chain.

• A company that pays salaries from one wallet publishes what each employee earns.
• A treasury moving funds tells the market what it is about to do.
• A merchant's receiving address shows its revenue and lists its customers.
• Wallet clustering links addresses that transact with each other, so one address tied to a name exposes the rest.

The approachCopy Anchor Link

When you deposit, tokens move from your platform wallet into a pool token account. Those accounts belong to the shielded pool program: their authority is a program-derived address (the code calls it VaultAuthority), so no person or company holds a key to them. What governance can change about the program is set out under governance and upgrades.

Ownership inside the pool is recorded as notes. A note is a private record of an amount of one token and the identity that owns it. The chain never sees a note's contents, only its commitment: a hash of all its fields, appended as a leaf to a Merkle tree the program keeps.

To spend notes, your device proves in zero knowledge that it knows unspent notes in that tree, owned by your registered identity, and that for each token the value leaving the transaction, fees included, equals the value entering it. With the proof it publishes one nullifier per spent note. A nullifier is derived with the owner's nullifier key, so nobody else can tell which note it belongs to, and the program refuses any nullifier it has already accepted, so a note cannot be spent twice. Notes owned by a program address are the exception to the first part, as nullifiers explains.

The new notes are encrypted to their recipients, who find them by trying to decrypt each one published. Before the program accepts a value transaction, six attesters check the parts that concern them and co-sign it: three guardian nodes, the screener, the fee enclave and the data endorser.

What is differentCopy Anchor Link

Proofs on your deviceCopy Anchor Link

Your device builds the transaction's zero-knowledge proof itself, in the browser, with a WebAssembly Groth16 prover. Your keys and your notes' contents do not go to a proving service. See how Nimbus uses proofs.

Post-quantum note encryptionCopy Anchor Link

Each note is encrypted to its recipient with ML-KEM-768, the lattice key-encapsulation mechanism standardised in FIPS 203, and AES-256-GCM. Encrypted notes are published for anyone to download and keep, so they are built to withstand someone who stores them today and gains a quantum computer later. The proofs and signatures are not post-quantum; security levels sets out what that means.

Screening, zones and disclosureCopy Anchor Link

The screener checks the bound submitter of every value transaction, plus the public counterparties of deposits and withdrawals, before it co-signs. For a Private Send it screens the submitter, usually the relayer, while the private recipient stays private. Zones let an authority approve notes leaving or entering its domain, checked inside the proof so that the zone itself is not revealed. Each transaction also carries an encrypted sender record and a per-field disclosure commitment, and its per-transaction viewing key is shared among the guardian nodes. See disclosure.

Guardian nodes in attested enclavesCopy Anchor Link

The three guardian nodes run in AWS Nitro enclaves. Before a node's key can sign for the pool, Solana programs verify its AWS attestation document on chain, P-384 certificate chain included, and check its measurement against the set approved for its cluster through a timelocked proposal. See trusted execution.

An escape hatchCopy Anchor Link

If an attester is offline or refuses to sign, you can still take a note out. The escape hatch spends one note to a public address with only a proof, no attester signature. The price is that it discloses that note's fields, pays a withdrawal fee, and waits 48 hours before the funds can be released to the destination. See escape hatch.

Formal verificationCopy Anchor Link

Lean proofs over models of the transaction circuit show that a valid proof cannot mint tokens or fund a withdrawal without inputs, under stated range bounds. Kani model-checks the nullifier staging buffer (which the code calls the turnstile) and the Merkle tree code. The models are hand-written and the proofs rest on stated axioms; formal verification says exactly what is and is not covered.

What Nimbus is notCopy Anchor Link

• Not a fixed-denomination pool. A note holds any amount a 64-bit integer can represent, and a transaction can split or merge notes, so you do not deposit or withdraw in set sizes.
• Not a rollup, a layer 2 or a sidechain. Every transaction settles in the shielded pool program on Solana, which verifies the proofs and signatures in the same Solana transaction. There is no sequencer and no separate chain. Any wallet can submit a transaction, your own included, and the transaction names the one that will.
• Not encrypted computation. Nobody computes on an encrypted balance: the protocol uses notes and zero-knowledge proofs.
• Not private from everyone. The screener sees every transaction's submitter and the public counterparties of deposits and withdrawals, and the indexer learns which notes you spend when your device asks it for their Merkle paths. See trust assumptions.

What is private and what is notCopy Anchor Link

Stated exactly, a chain observer can see:

• that a wallet registered, and which main wallet, platform wallet and identity commitment belong together;
• each deposit's depositor (your platform wallet), source token account, token and amount;
• each withdrawal's destination, token and amount;
• for every value transaction, when it ran, who submitted it, any relayer tip and its token, and its nullifiers and commitments, which look random;
• for an escape hatch, the fields of the note it spends.

A chain observer cannot see who sent a private transfer or who received it, how much moved or in which token, which notes a transaction spent, how value was split between recipients and change, or which zone a note belongs to. Whether a transaction also spends notes cannot be seen either, because every transaction has the same three input slots.

Linking a deposit to a later withdrawal is a matter of inference from amounts and timing, which how privacy is lost covers.

Scope and statusCopy Anchor Link

• Nimbus runs on Solana. This documentation describes the programs, circuits and services in this repository, checked at the commit shown at the foot of each page.
• All value moves through one instruction, process_3x3x2x2, currently at envelope version 0.
• The forester, which moves staged nullifiers into the nullifier tree, is built but not deployed.
• Program addresses and what is live on each cluster are on the program addresses page.

RelatedCopy Anchor Link