threat model
A privacy protocol is only as strong as the threats it explicitly addresses. This document outlines what KIRITE protects against, what it does not, and the assumptions under which its guarantees hold.
adversary model
KIRITE is designed to resist the following adversary types:
| adversary | capabilities | KIRITE defense |
|---|---|---|
| passive observer | reads all on-chain data, no active interference | encrypted amounts, broken tx graph, stealth addresses |
| MEV bot | monitors mempool, can front-run transactions | amounts invisible, recipient unknown — nothing to front-run |
| analytics firm | advanced graph analysis, wallet clustering, heuristics | shield pool mixing breaks clustering, stealth addresses prevent linking |
| malicious validator | can observe transaction ordering, attempt censorship | proofs are valid regardless of ordering. censorship-resistant via Solana consensus |
| compromised RPC | can observe user requests, return false data | proofs verified on-chain. RPC cannot forge valid proofs |
what KIRITE protects
amount confidentiality
Transaction amounts are encrypted using Twisted ElGamal. The ciphertext is semantically secure under the Decisional Diffie-Hellman (DDH) assumption. Without the recipient's private key, the amount is computationally indistinguishable from random.
sender-receiver unlinkability
The Shield Pool ensures that there is no deterministic link between a deposit and the corresponding withdrawal. Given n deposits in the anonymity set, the probability of correctly linking a withdrawal to its deposit is 1/n.
recipient anonymity
Stealth addresses ensure that each transaction creates a fresh, one-time address. Even if an observer knows the recipient's public meta-address, they cannot link stealth addresses to it without the viewing key.
transaction graph obfuscation
The combination of encrypted amounts + pool mixing + stealth addresses makes it infeasible to reconstruct meaningful transaction patterns from on-chain data alone.
what KIRITE does not protect
No privacy protocol provides absolute anonymity. Understanding the limitations is as important as understanding the guarantees.
network-level metadata
KIRITE does not hide the fact that a user is interacting with the protocol. An observer can see that address X called a KIRITE program instruction. IP-level privacy requires additional tools (e.g., Tor, VPN) at the network layer.
small anonymity sets
If the Shield Pool has very few deposits (e.g., <10), the anonymity guarantee is weak. KIRITE mitigates this by enforcing minimum set sizes and incentivizing liquidity, but early-stage pools may have reduced privacy.
amount correlation
If a user deposits exactly 1,337.42 USDC and withdraws exactly 1,337.42 USDC shortly after, the unusual amount creates a correlation even though the amounts are encrypted during transit. Mitigation: KIRITE supports split withdrawalsand recommends variable amounts.
timing analysis (partial)
While time-locks reduce timing correlation, a sophisticated adversary monitoring deposit/withdrawal patterns over long periods may identify statistical correlations. The variable time window mitigates but does not eliminate this risk.
compromised client
If the user's device is compromised (e.g., malware, keylogger), all privacy guarantees are void — the attacker has access to plaintext data before encryption. This is outside the protocol's threat model.
trust assumptions
| assumption | implication if broken |
|---|---|
| DDH hardness on Curve25519 | Twisted ElGamal encryption broken — amounts revealed |
| discrete log hardness | stealth address scheme broken — recipients linkable |
| Bulletproofs soundness | invalid range proofs accepted — potential overflow/inflation |
| Solana consensus (≥ 2/3 honest) | transaction censorship possible (not privacy break) |
| client device not compromised | plaintext amounts/keys exposed at the source |
| sufficient pool liquidity | small anonymity sets reduce sender-receiver unlinkability |
audit status
KIRITE's Solana programs, cryptographic implementations, and client-side proof generation will undergo independent third-party security audits before mainnet deployment. A bug bounty program will be active post-launch.
- Audit Round 1 — scheduled Q3 2026 (Shield Pool program)
- Audit Round 2 — scheduled Q4 2026 (full protocol)
- Bug bounty — active post-mainnet