architecture

KIRITE v1 is a Solana-native ZK shield pool with stealth-address recipients. Two on-chain instructions, one off-chain prover, one optional relayer. No L2, no sidechain, no custom VM.

system overview

layer 1: shield pool (Anchor program)

The core program holds a Poseidon-Merkle commitment tree per denomination. Deposits insert a 32-byte commitment as a leaf; withdraws prove membership via Groth16 and publish a nullifier hash to prevent double-spend.

• Fixed denominations — 0.01 / 0.05 / 0.1 / 1 / 10 SOL on launch. Each denomination is a separate pool with its own tree.
• Merkle height 15 — 32,768 leaves per pool. Casual-privacy sweet spot: 1,024x more capacity than v1 with proof generation that still stays under 5s on desktop.
• Per-nullifier PDA — each consumed nullifier creates a small PDA at [b"nullifier", pool, nullifier_hash]. A double-spend attempt collides on init and reverts.
• Vault PDA — token vault is owned by a program-derived authority. The pool authority cannot move user funds, only freeze the pool in emergencies.

proof verification

On-chain verification uses Solana's native alt_bn128 syscalls for the Groth16 pairing check (~120k compute units per withdraw) and the native poseidon syscall for Merkle root recomputation and zero-leaf padding. No off-chain prover, no third-party oracle.

// withdraw verifier inputs (256 bytes proof + 4 public inputs)
proof_a (G1, BN254, big-endian uncompressed) :: 64 bytes
proof_b (G2, BN254, big-endian)              :: 128 bytes
proof_c (G1)                                 :: 64 bytes

public_inputs[0] = root            // pool's known Merkle root
public_inputs[1] = nullifier_hash  // Poseidon(ns, leaf_index)
public_inputs[2] = denomination    // = pool.denomination
public_inputs[3] = recipient_hash  // = keccak256(recipient_token_account)

layer 2: stealth address (DKSAP)

Recipient addresses are one-time outputs derived from a published meta-address (public spend key + public view key). The depositor generates an ephemeral keypair, computes a shared secret with the recipient's view key, and derives the one-time address. The recipient scans for incoming notes using their view key alone; the spend key is required only at claim time.

layer 3: client (Telegram miniapp + SDK)

Note material (nullifier_secret, blinding_factor) is generated and stored on the user's device. Proof generation runs in the browser via snarkjs WASM (~1s on desktop, ~3s on mobile). The compiled circuit (membership.wasm) and the trusted-setup zkey are static files served from the miniapp origin.

layer 4: relayer

The relayer is a Vercel-hosted backend that receives a client-generated proof + public inputs, signs the on-chain withdraw, and forwards the unwrapped output SOL to the stealth address. The relayer pays gas and the per-nullifier PDA rent. It cannot construct a valid proof itself.

• OFAC SDN screening — refreshed weekly from the Treasury's public XML; rejects any sanctioned recipient.
• Anyone may run one — the relayer is replaceable. The default relayer is a convenience, not a trust dependency.
• Self-funding via 0.1% protocol fee — fee revenue is routed to the relayer treasury. Phase 2 forwards that revenue to $KIRITE stakers.

data flow

follow-on: confidential balances

Solana ships a token-extension primitive, Confidential Balances, that encrypts SPL token amounts via Twisted ElGamal. KIRITE v1 does not integrate it. Amount privacy in v1 is bounded by the fixed-denomination pool design. A follow-on version may layer Confidential Balances on top to support arbitrary amounts; see /docs/confidential.