Architecture

Sombra is five pieces: a client you run, a prover that generates STARK proofs, QFire (an off-chain relay), the node set that verifies and finalizes, and the Solana program that owns the shielded state.

The Solana program

A single on-chain program owns the shielded state. It does not keep a global commitment tree or a nullifier set. Instead it holds:

• Per-vault ledgers. Each vault has its own ledger — a linked chain of UTXOs. The ledger stores the current chain tip (latest_utxo_hash) and a small buffer of recently-spent tips awaiting cleanup.
• UTXO accounts. Each UTXO is a content-addressed account holding the Kyber-768 ciphertext, the encrypted payload, and a commitment hash. It is addressed by its own hash.

The program's job across a shielded transfer:

1. On UTXO creation, recompute and verify the UTXO's hash and confirm it points at the receiver's vault. (The STARK proof is verified off-chain by nodes, not here.)
2. On finalization, confirm the transfer has reached the attestation quorum.
3. Confirm chain continuity — the new UTXO points at the ledger's current tip.
4. Advance the ledger tip and record the spent tip for cleanup.
5. Emit a finalization event.

A freshly created UTXO exists on-chain but is not yet part of any ledger — it stays unattached (pending) until the nodes finalize the transfer. Finalization is the only step that advances a vault's ledger tip and marks the UTXO finalized, and only the node set can perform it.

The program never sees amounts, senders, or recipients. It only sees encrypted UTXOs, commitment hashes, and node votes. 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 UTXOs for ones addressed to the user's vault.
2. Stores local state — the user's unspent UTXOs, decrypted locally.
3. Builds transfer transactions — selects input UTXOs, constructs the outputs, writes the new UTXOs on-chain (where they sit unattached), requests a STARK proof over them, and relays that proof to the nodes.

All scanning and decryption happens on the user's device. Keys never leave the client, and no signature ever authorizes a spend — a zero-knowledge proof does (Sombra is signature-free; see Concepts).

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, plus an optional local prover users can install to keep proving fully on their own machine. 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 default remote prover runs inside NVIDIA Confidential Computing — a hardware trusted execution environment (TEE). The goal is that it computes your proof without being able to read your witness; the remote attestation that would prove that guarantee is on the roadmap (today the prover is operated by the Sombra team). Either way, the witness never hands over your secret key: the client prepares data that proves knowledge of the key without revealing it. The prover is compute, not custody.

Proof generation may be free at launch; the fee model is TBD before beta.

QFire — the proof relay

The STARK proof never goes on-chain. The client uploads it to QFire, an off-chain relay that stores proofs and fans them out to the node set. Keeping proofs off-chain is what keeps a shielded transfer cheap — the chain only ever stores the small encrypted UTXOs and the nodes' votes.

The node set

Nodes verify each proof and finalize the transfer via an attestation quorum. This is the MVP mechanism; it may evolve as the network matures.

How it works:

• The node set is an approved set of operators (staking/bonding is planned; the model is TBD before beta).
• Each node verifies the STARK against the expected proof image and checks UTXO-chain continuity.
• Nodes cast their attestation votes as ordinary Solana transactions signed by a rotating, hash-derived prover key; their post-quantum ML-DSA keys authenticate them to QFire, not the on-chain votes. Once a quorum attests, any node can submit finalization. The exact quorum threshold is TBD before beta.
• Creating UTXOs costs refundable Solana rent, reclaimed automatically once they are cleaned up — see network fees and rent reclaims.
• Bonsol-operated "super nodes" are part of the initial set as a bootstrap mechanism.
• Poorly-behaving voters can be suspended by the governance process.

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

Data flow: a shielded transfer

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.