Architecture

Sombra is four pieces: a Solana program that holds shielded state and verifies proofs, a client that scans notes and builds transactions, a prover that generates STARKs, and a node set that finalizes transfers.

The Solana program

A single on-chain program owns the shielded state. It tracks:

• The commitment set — every note commitment that's ever been produced. Stored as an accumulator so membership can be proven without revealing which element.
• The nullifier set — every note that's been spent. Each transfer reveals a nullifier; the program rejects any transaction whose nullifier is already present.

The program's job on every shielded transfer:

1. Verify the STARK.
2. Check that the submitted nullifier is not already in the nullifier set.
3. Add the output commitment to the commitment set.
4. Add the nullifier to the nullifier set.
5. Emit a finalization event.

The program never sees amounts, senders, or recipients. It only sees commitments, nullifiers, and proofs. Deploying on Solana means no consensus changes required — Sombra is a standard program, not a sidechain or rollup.

The client

The Sombra client is distributed as a browser/wallet extension (Chrome Web Store as the primary path, raw binary fallback for other browsers). It holds the user's seed, derives their Kyber-768 keys and spending keys, and does three things:

1. Scans on-chain encrypted payloads for notes addressed to the user's vault.
2. Stores local state — the user's unspent notes, decrypted locally.
3. Builds transfer transactions — selects input notes, constructs outputs, requests a STARK proof, assembles the Solana transaction, and submits it.

All scanning and decryption happens on the user's device. Keys never leave the client.

Builders integrating Sombra use the same client as an SDK. Wallet and application integration interfaces are TBD before beta.

The prover

STARK proof generation is compute-heavy — too heavy to run in a browser tab without unacceptable latency. Sombra ships with a server-side GPU prover that clients can call. The client sends witness data; the prover returns a proof.

Current benchmarks:

• RTX 3090: ~1.8–2 seconds per proof
• RTX 6000: sub-second (projected)

Once proof generation is under 1 second, network latency (~200–250 ms cross-continent) becomes the dominant cost. A distributed prover network is planned as future work but not part of MVP.

The witness sent to the prover does not leak the user's secret key — the client prepares witness data that proves knowledge of the key without revealing it. The prover is compute, not custody.

Proof generation may be free at launch; a fee structure will be announced before beta.

Node governance

Sombra transfers finalize via an attestation quorum from an approved set of nodes. This is the MVP mechanism; it may evolve as the network matures.

How it works:

• Node operators stake or deposit SOL to participate.
• On each transfer, the approved node set votes to attest finalization.
• Refundable SOL fees are paid at UTXO creation and distributed to nodes when the transfer finalizes.
• A supermajority of nodes must attest; the exact quorum threshold is TBD before beta.
• Bonsol-operated "super nodes" are part of the initial set as a bootstrap mechanism.
• Poorly-behaving minority voters can be suspended by the governance process.

The initial node set is limited to reputable staking providers. Onboarding additional node operators is governed; the exact process is TBD before beta.

Nodes stay stateless — finalization vs. off-ramp is differentiated through contract events, not by node-local state.

Data flow: a shielded transfer

User         Client (extension)              Prover (GPU)        Solana program
────         ──────────────────              ────────────        ──────────────
                                                                 commitment set
                                                                 nullifier set
             select input note
             compute nullifier
             build output commitment
             build witness
                                 ────────▶
                                            generate STARK
                                 ◀────────
             assemble tx ────────────────────────────────────────▶
                                                                 verify STARK
                                                                 reject if
                                                                   nullifier seen
                                                                 add commitment
                                                                 add nullifier
                                                                 emit finalization
                                                                 nodes attest
user sees confirmation ◀─────────────────────────────────────────

What's out of scope for MVP

• Full on-ramp privacy. Deposits into a vault reveal the external wallet → vault link. A vault-less quantum-native token is proposed as the forward path for full on-ramp privacy, but it is a research direction — no MVP timeline.
• Off-chain ledger storage. Storing the full encrypted payload off-chain (with a 32-byte on-chain hash) is planned for v2/v3, not MVP.
• Distributed proving network. Planned post-MVP, once single-node GPU proving is < 1 second.

What's next

• Security — the full threat model, including what each MVP limitation means for users.
• FAQ — practical questions for users and integrators.