Who sees what
We assume a relayer and the issuer may be run by the same team, and design for it.
What Arkognito protects
- Linking records to each other or to a wallet from chain data: one-time owners, a shared creator, shuffled padded batches, bucketed lifetimes.
- Relayer tampering: signed envelopes, verified by the client after every write and by any reader.
- Relayer censorship or crashes: failover, and duplicate-free recovery.
- Reads revealing ownership: app-wide listings, local tag opening, batch-level fetches.
- Rate limits revealing identity: blind tokens, key-consistency checks, timing separation.
- Network identity: Oblivious HTTP, when used, with relayers verified through Arkiv.
- Key exposure in the browser: keys in a Web Worker that only signs Arkognito-shaped requests.
Limits, stated plainly
- Relayer and OHTTP relay must not collude. OHTTP protects IPs only if they are run by different people. Without OHTTP, the relayer sees IPs.
- Anonymity is per batch. In a quiet hour a batch can be small; use
minAnonymityto refuse small batches. - Quotas limit wallets, not people, unless the issuer requires attestation codes.
- A hostile frontend can still ask the key worker for signatures and ownership proofs. Only use Arkognito on pages you trust, with no third-party scripts.
- Content can identify people regardless of owners.
check()helps but cannot catch everything. - Expiry does not erase history. Use encryption for private content.
- Records are create-only. One-time owners hold no gas.
- Smart-contract wallets are not supported in this version.
- No outside audit yet. The protocol is experimental and runs on testnet only.