Assurance 0
A card helps you prove that you are trustworthy and lets you access shared resources
Plain
A card lets you prove a statement about yourself and lets online services act on it. Show your card and a claim comes with it — this person is a member of the running club — along with proof it was really issued to you.
Two uses: verify a statement attached to a message, or gain access by presenting your card to a service that checks it.
Technical
Proof is a signature pointing to a document on IPFS. The verifier checks the signature, derives the on-chain registry address (keccak256(pubkey)), reads the registry entry, fetches and decrypts the referenced document, then walks the chain to a trusted root.
Verification is a library, not a service — no API key, no permission, no call home.
This does not mean — verification is free of dependencies. A verifier needs network access to the registry and IPFS.
Assurance 1
You can see why a card was given, and by whom
Plain
Every card carries a chain of verification. When someone shows you a card, you can see who issued it, why it was issued, and why the issuer is who they say they are — following the chain back to a root you already trust.
Technical
Each card document references an issuer, an issuing policy, and its ancestry. A verifier walks the chain from the presented card to a trusted root, checking signature validity and issuer authorization at each link.
This does not mean — the chain tells you a person is trustworthy. It tells you who vouched for what, and lets you decide whether you trust them.
Assurance 2
A card reflects current standing, not past standing
Plain
Cards can be updated and revoked. If someone's standing changes, the issuer (or someone else authorized) can update or revoke it. A card you're shown tells you where things stand now — not when it was issued.
Technical
Cards include an append-only log of updates, some benign (key rotation), others revocations (codes 800–999), registered on a smart contract on Arbitrum One. A press posts the latest version to IPFS and updates the contract to point to it.
This does not mean — revocation propagates instantly everywhere. It means revocation is authoritative and cannot be hidden from a verifier who checks.
Assurance 3
A card says why you're trustworthy and nothing else
Plain
A card proves one thing — that you're a member of a community, a licensed practitioner, a student — without revealing anything else about you. It allows you to be both anonymous and verified.
Technical
A card asserts the statement defined by its issuing policy. Personally identifying fields appear only where the policy specifies them, and the holder must countersign at issuance for the card to be valid.
This does not mean — a card is contentless. Presenting a card reveals the card's statement and its issuance chain.
Assurance 4
Your cards are separate from each other
Plain
The cards you hold are not connected. You can show a professional credential in one place and a fan club card in another, with no way to tell they belong to the same person unless you present them together.
Technical
Each card has its own keypair, registry address (derived one-way from its public key), and content key. There is no shared identifier across a holder's cards, and no directory that enumerates them.
This does not mean — behavioral correlation is impossible. It means the protocol itself provides no linkage.
Assurance 5
Losing your phone doesn't mean losing your cards
Plain
Your cards live on your device, and you can get them back if it's lost, stolen, or replaced. Recovery doesn't depend on any single service staying in business. You choose how strong to make it: a hardware key, a paper password, or another credential.
Technical
Sub-card keys live in the device's Secure Enclave/TPM. The master card key lives in an encrypted keyring blob, decryptable only from passkey + service_secret — neither factor alone suffices. Hardware-key recovery opens a 72-hour cancellation window before releasing the wrapped key.
This does not mean — every recovery path is equally strong, or that recovery is automatic. Keys that are trivially recoverable are also trivially stealable.
Assurance 6
Every card is a secure inbox
Plain
People can reach you through a card without ever learning your email address or phone number. You can filter messages both by which cards they come to and which cards they come from.
Technical
Messages are end-to-end encrypted to the card's ML-KEM public key. The outer envelope carries only the recipient card hash; sender identity, message type, and content sit inside the encrypted payload, routed through relays.
This does not mean — an inbox is unsolicited-message-proof. It means messages carry verified provenance, and reaching you requires holding a card, not knowing a personal identifier.
Assurance 7
Cards carry accountability as well as trust
Plain
If someone uses a card to gain access and then behaves badly, the issuing community can be told — even if that person is anonymous to the people they harmed. The report carries proof, not a screenshot. Anonymity isn't impunity.
Technical
A defined process lets reports include proof of the cardholder's actions, signed by their card. If issuers fail to act, third-party trust and safety services focused on defined harm categories can flag the card.
This does not mean — the issuer learns who the person is. It means the issuer can act on the card they granted.
Assurance 8
The infrastructure can't watch you
Plain
The services that make cards work are built so that no single one of them can see what cards you hold or what you do with them. The knowledge is deliberately split apart, so no operator, including us, holds enough to watch you.
Technical
Stated per component: wallet services route by recipient hash only; presses verify before posting; relays implement OHTTP and see only device-notification metadata. Data linking cards and messages lives on wallet services; data linking messages and devices lives across independent relays — neither half is sufficient alone.
This does not mean — nothing is observable. On-chain writes are public events with timestamps and a visible fee payer.
Assurance 9
You can choose from many infrastructure providers or start your own
Plain
The protocol is federated. Anyone trusted can run the infrastructure. No company sits in the middle, and no one can buy their way into that position. It's open source, and a community can move to another operator or run their own.
Technical
Presses, relays, wallet services, and notaries are independently operated roles, authorized by cards rather than a central administrator. A governance board maintains the protocol and adjudicates rule violations; it does not own the infrastructure or the data.
This does not mean — there's no trust involved. Federation moves trust from a company to an operator, identified by card so you can see why they're deserving of trust.
Assurance 10
Cards are built for the long term
Plain
Cards use encryption designed to hold up against future attacks, including attacks by quantum computers that don't exist yet. Sharing a card establishes a channel that can't be intercepted in the middle.
Technical
ML-DSA-44 (FIPS 204) signs IPFS content; ML-KEM-768 (FIPS 203) encrypts card-to-card messages — both post-quantum. secp256r1 via RIP-7212 authorizes on-chain registry writes — classical, by design, with a migration path, since keys are rotatable.
What we do not promise
01
Cards cannot build a community for you. They give an existing community capabilities it didn't have. They don't create trust, convene people, or resolve conflict — that's organizing.
02
Federation means trusting operators, not trusting no one. The protocol makes it visible who you're trusting. It doesn't remove the need to trust.
03
We are not claiming these guarantees are verified today. They are design targets, published so we can be tested and held accountable. The protocol is in development.
Found a hole in one of these?
Two open questions are live and real — help us check whether this holds up.