threat model

A privacy protocol is only as strong as the threats it explicitly addresses. This page lays out what KIRITE protects against, what it does not, and the assumptions under which the guarantees hold.

adversary model

what KIRITE protects

deposit ↔ withdraw unlinkability

The Shield Pool stores commitments in a Poseidon Merkle tree. Withdraws prove leaf membership via a Groth16 circuit and publish only a nullifier hash and a Merkle root. The nullifier secret never leaves the user's device, so an observer cannot recompute the commitment to match a deposit.

Given n active deposits in the pool, the probability of correctly linking a withdraw to its deposit by chain data alone is bounded by 1/n (in practice less, with timing and recipient correlations excluded).

recipient anonymity

Stealth addresses (DKSAP) generate a one-time on-chain address for every withdraw. An observer with knowledge of the recipient's public meta-address still cannot link the stealth output to it without the view key. The relayer pays gas and rent so the recipient's identity does not appear anywhere on the withdraw transaction.

front-run-safe withdraws

The Groth16 proof binds to a hash of the recipient token account. A malicious relayer attempting to redirect funds at the last moment would invalidate the proof on-chain, and the withdraw reverts.

what KIRITE does not protect

amounts

Each pool is fixed-denomination. Every deposit and every withdraw moves the exact same amount. The denomination is public. Users who need to send 0.073 SOL will visibly leak the non-pool change.

network-level metadata

KIRITE does not hide the fact that an address interacted with the protocol. An observer can see that wallet X called the deposit instruction. IP-level privacy is the user's responsibility (Tor, VPN, etc.).

small anonymity sets

v2 caps each pool at 32,768 leaves (Merkle height 15). When a pool contains fewer active depositors, the unlinkability guarantee weakens proportionally. Users seeking strong privacy should wait for additional deposits before withdrawing.

timing correlation

v2 does not enforce on-chain timelock; the relayer recommends clients delay 10+ minutes before broadcasting a withdraw. Aggressive timing-analysis pipelines can still partially deanonymize light pools. Mitigation is traffic, not policy.

compromised client

If the user's device is compromised (malware, keylogger), all privacy guarantees are void. The pre-image is on the device; an attacker with the device sees it. This is outside the protocol's threat model.

cryptographic assumptions