Skip to main content

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 minAnonymity to 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.
Every case, with its status and the test that shows it, is in the edge-case register.
Last modified on October 12, 2026