Everything you own
The objects that make up an Nimbus account, where each one lives and how it comes back.
Nimbus's clients, not the protocol
This section describes how Nimbus's own applications and SDK set up an account: one wallet signature, the keys derived from it, the platform wallet and the local note store. The protocol enforces none of that. The shielded pool checks proofs, signatures and commitments; it does not check how your keys were made, whether they came from a signature, or which wallet signs for you. Another client can follow its own standard and still use the same pool. Where a page states something the pool or a circuit does enforce, it says so.
An Nimbus account, as Nimbus's clients build it, is one wallet signature and everything derived from it, plus the notes and records the protocol keeps for you in public, encrypted form. Nothing about it is stored by Nimbus in a form that lets anyone spend.
The objects
Eight objects make up an account. The first five are things you hold or can regenerate from your main wallet. The last three are public or archived records the protocol keeps on your behalf, and only your keys make sense of them.
Main wallet
Your own Solana wallet, held in your wallet software or on your device. Nimbus does not derive it, hold it or back it up. It signs the account message once on each device, binds itself to your platform wallet in the user registry, and pays the Solana fee for your registration and, in the SDK's default form, for your deposits. Its address is public like any Solana address. It comes back only through your wallet's own backup, and that backup is also the only backup your Nimbus account has.
Account signature
One Ed25519 signature by your main wallet over a fixed Nimbus message. The app asks for it when it needs your keys and holds it in memory; nothing in the protocol stores it. Every other secret on this page is derived from its 64 bytes, so only you should ever see it. Ed25519 signatures are deterministic, so signing the same message again returns the same bytes, which is how it comes back. See the account signature.
Platform wallet
A Solana keypair derived from the account signature, through a seed your device derives once per session, and re-derived from that seed each time it is needed. It signs the bind in the user registry, your registration and your deposits, so its address is public. The bind publicly links it to your main wallet, and the registration links it to your identity commitment. See the platform wallet.
Identity keys
The spending key, nullifier key, outgoing viewing key and proof-authorisation key, plus eight blinders that hide each slot of your identity commitment. All are re-derived on your device from the account signature, and none is stored anywhere else. At registration your device also splits the outgoing viewing key into shares, one for each guardian node. See your keys.
Encryption keypair
An ML-KEM-768 keypair that senders encrypt your notes to. The secret key is re-derived on your device and decrypts every note sent to you. The public key is archived by the data endorser when you register and served by the indexer to anyone who pays you, which is its purpose; the chain itself carries only its hash.
Identity commitment
Your identity commitment (sometimes called the user commitment) is one hash that commits to your keys, your platform wallet and the hash of your encryption public key. It is the one public value that stands for you inside the protocol. Registration appends it to the shielded pool's identity tree, where it stays permanently, and the registration transaction links it to your platform wallet. It never appears in a transaction afterwards. See your identity commitment.
Notes
The units of your private balance. Each note exists in three places: its commitment in the pool's note tree, which is public; its encrypted contents in the archive the data endorser writes and the indexer serves; and a decrypted copy in your device's local store. Its contents open with your keys or with the sender's, who created it. If your device loses its copy, rescanning the archive finds the note again.
Sender records
Every value transaction you send carries an encrypted summary of what it did: your identity commitment, the token and amount of each note spent, and the owner, token and amount of each note created. It is encrypted under that transaction's per-transaction viewing key and archived beside the notes. You can re-derive the key from your outgoing viewing key.
The local note store
Your device also keeps a local note store, encrypted under a journal key derived from the same signature. It is a cache of what the chain and the archive already hold, so losing it costs a rescan, not funds.
How each comes back
Everything except the main wallet comes back from the account signature or from public records. Sign the message again and the device re-derives the platform wallet, every identity key, the encryption keypair and the journal key, and recomputes the identity commitment. The commitment itself never needs restoring, because the identity tree holds it permanently. Notes and sender records come back by rescanning the archive with the re-derived keys. See recovery.
What controls your funds
Tokens you deposit sit in pool token accounts owned by the shielded pool program, not in any wallet Nimbus controls. A note can be spent only by a zero-knowledge proof that its owner knows the opening of the identity commitment the note belongs to, and that opening never leaves your device. The powers governance holds over the program are described in governance and upgrades.
Your viewing keys
Your device shards your outgoing viewing key, and each transaction's per-transaction viewing key, across the guardian nodes, a system of nodes that each run inside an AWS Nitro enclave. Each node receives one share, encrypted to it alone, and a single share reveals nothing about the key. The shares cannot be used to spend: spending needs the spending key, the nullifier key and the slot blinders, which never leave your device. See guardian nodes.
Related
Last updated
Security levels and quantum status
How strong each primitive is today, which ones a quantum computer would break, and what an attacker could and could not do if one existed.
The account signature
The single wallet signature every Nimbus key is derived from, why signing again recovers the whole account, and the ways it can go wrong.