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
A card is an attestation that is cryptographically signed by both an issuer and a receiver. By checking the issuer's card and their issuer's card, a verifier can confirm that a card traces back to some trusted root. Signatures are implemented through ML-DSA-44 to be quantum resistant. Cards are stored on IPFS so that storage is decentralized. A smart contract on Arbitrum One points to the latest card documents on IPFS, allowing cards to be updated and revoked. A cards address is derivable from its public key.
Verification is a library, not a centralized service.
This does not mean — verification is free of dependencies. A verifier needs network access to the smart contract 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 their respective ancestry. The policy limits what kind of card can be created and who can issue it. An issuer activates a policy to create a card. (e.g. a school superintendent makes a 'student card' policy and a school administrator creates cards with that policy.) A verifier walks the chain from the presented card through both the policy and the issuer 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), some positive (a promotion) and some revocations. To make an update, a service called a 'press' posts an update to IPFS and updates the smart contract to point to the new version. Because all updates must include valid signatures, a press cannot post a fake update without being quickly detected and reprimanded.
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 verified 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 only the statement defined by its issuing policy. By default, they do not include names, email addresses, or any other identifier that can be used to identify or track the cardholder, though card issuers could choose to add this information. Cardholders can also strip away personal information using a notary service, which produces a card attesting that the holder has another card of a given type. For example, someone could use a notary service to create an anonymous 'Meta Employee' card even if Meta does not grant them one.
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
The private keys tied to cards live on device and are backed up in an encrypted keyring blob. The blob is decryptable only from a passkey stored in Apple, Google, or a password manager. This recovery mechanism can be switched based on a user's preference.
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
A cards public key can be used to derive an address that can send and receive messages. All 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.
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 people report a cardholder's actions to that card's issuer. The report includes proof of the cardholder's actions, signed by their card. If issuers fail to act and the harm is severe, 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
Card backups are encrypted and delivered and retrieved via OHTTP. A system of independent relays implement OHTTP and allow messages to be routed to devices without data about both a card and the device it is being sent to living in the same place.
This does not mean — cards cannot be de-anonymized, they can be if message routers and relay services collude. To make this difficult, a user can choose to route their messages through a large number of relay services, making collusion very difficult.
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 if these operators act in bad faith; 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.
Membership Card Protocol