Membership Card Protocol

Identity Protocol

A protocol for community-issued membership credentials ("cards"). A community writes a card policy: who may issue, what a card attests, how it may be updated or revoked. An issuer offers a card, the holder countersigns with a key they generate themselves, and a "press" holding an on-chain authorization checks the policy and registers the card. The card's current state is a pointer in a registry contract on Arbitrum One and its history is an append-only encrypted log on IPFS. Cards are private by default, designed not to be linkable to each other, can receive encrypted messages, and are verified by walking the chain of cards back to a trusted root. The README calls the protocol "fully decentralized", while the assurances page calls it "federated": presses, relays, wallet services and notaries are independently operated roles authorized by cards rather than a central administrator, and a press can lose its authorization . Today it is a small project of one organisation with one contributor, a draft specification and no real-world communities yet.

Company
Links
Visit Website See this tool in the graph Suggest an edit

Details

License No licence file was found in the repository (checked 2026-10-29); the project describes itself as free to use and open source . https://github.com/davidgljay/membership_card_protocol
Dev Status 🧪 Alpha
Owner Relationality Lab
Governing Body Relationality Lab (author and operator today). Designed governance, per the project: RootPolicyBody (4-of-5; policy registration and logic upgrades), PressRegistryBody (4-of-5; press authorization and revocation) and DnsGovernanceBody (M-of-N, bootstrapped 1-of-1; the mcard:// namespace), all with on-chain quorum keys; the materials do not state that any body has convened
Country Not stated by the project.
Start Year 2026
Stack TypeScript services and SDKs; Rust contracts on Arbitrum Stylus; Arbitrum One; IPFS; ML-DSA-44 (FIPS 204) and secp256r1 signatures; ML-KEM message encryption; AES-256-GCM
Funding Not stated by the project.
Last Investigated Oct 29, 2026

Topology view

This tool in the centre and the things it is directly related to. Each line names the kind of relationship.

Topology view: Membership Card ProtocolThis tool in the centre and the things it is directly related to. Each line names the kind of relationship.MembershipCard Protoc…IPFS (Based on, Speaks protocol, Stores in)IPFS
  • IPFS (Tool): Based on, Speaks protocol, Stores in

Open in Graph Explorer

Use Case Domains

Identity & Trust

Affordances

Portable attestations Contextual disclosure

Identity Protocol Attributes

Origins A way for people who build community to share resources and build trust: membership credentials issued by communities themselves rather than by a platform, private by default, with proof of standing that does not depend on a central identity provider
Database Arbitrum One registry contract (a mutable pointer per card, press authorizations) plus append-only logs on IPFS; wallet services hold encrypted keyrings
Query Language None. A card is found by deriving its registry address, keccak256 of its public key, then fetching its log from IPFS and decrypting it with a key derived from the same public key
Data Formats A normative canonical serialization (spec Appendix A) with published conformance and versioning test vectors; card documents and log entries are encrypted JSON on IPFS; mcard:// URLs for offers
Mobile Support Designed for it: mobile SDKs are listed as done and sub-card keys are held in device secure storage; there is no finished app
Web Support A web SDK is listed as done, and a browser authentication flow (a request routed through CHAPI, or a future browser-native API) is specified; no finished frontend app
Native Apps None yet: the frontend app is listed as not done
Terms Described as free to use and open source, but no licence file is published; presses pay a minimal fee, roughly $0.005, to create a card and may charge for cards
Funds Not stated by the project.
Based On Arbitrum One (Stylus contracts, the RIP-7212 secp256r1 precompile); IPFS; ML-DSA-44 and ML-KEM post-quantum cryptography; passkeys and YubiKey backups; optional OHTTP
Permissions Press registry writes require an on-chain press authorization; issuing under a policy requires holding a press sub-card of that policy; anyone may run a wallet service and verify cards
Authentication & Identity Cards rather than accounts: a holder generates their own keypair on accepting a card, and the card's address is keccak256 of its public key. The master key stays cold; day-to-day signing uses device-held sub-card keys registered to it. A holder's cards are designed not to be linkable to one another
Storage Model Hybrid: registry pointers on Arbitrum One; encrypted append-only logs on IPFS (AES-256-GCM, content key derived from the card's public key); keyrings held encrypted by wallet services and replicated across a federation
Interoperability Its own credential design: the specification names no DIDs and lists a W3C Verifiable Credential compatibility layer only among future items . Wallet-to-site requests are routed through CHAPI. The README says a verifier is available as an npm module and a Python library; an npm package named membership-card-verifier (version 0.0.1, 2026-07-12) exists but nothing links it to the project, and no Python package was found, so neither is confirmed
Data Portability Cards are addressed by public key on a registry contract and logs sit on IPFS, so a card can be read by anyone holding its public key; keyrings are encrypted blobs replicated across wallet services, and the holder can recover them independently of the primary service via a YubiKey backup
Governance & Decision Making Protocol changes are designed to go through on-chain quorum bodies (see Governing Body); the site invites partners to take part in its governance, and today decisions rest with the author
Protocol Maturity / Standardization Draft specification v0.4, "In Review", with conformance and versioning test vectors; not submitted to any standards body; mainnet contracts deployed; no independent audit yet
Identity Standards None adopted: its own card and policy model, not W3C DIDs
DID Methods Supported None.
Key Management Passkey-encrypted master keys held in a keyring stored by the wallet service; sub-card keys in device secure storage (Secure Enclave or TPM) for routine signing; master keys used only to create sub-cards and rotate keys; rotation is deliberate, never automatic
Credential Types Cards: signed credentials defined by a policy (membership, roles, sub-cards, press authorizations), with typed fields and predicates and a three-digit update code for each log entry
Verification Method A verifier walks the chain of cards from the presented key back to a trusted root, checking each signature, that the issuer was authorized by policy, and that no revocation applies; signatures are ML-DSA-44, and press registry writes are verified on-chain with secp256r1
Privacy Features Private by default: card content is encrypted on IPFS and readable only with the card's public key; a holder's cards are designed to be unlinkable; messages are end-to-end encrypted; optional OHTTP hides the requester's IP from the wallet service. The registry pointer and its updates are public on-chain
Authentication Methods A wallet signs a statement or request with a card satisfying a predicate; the user approves each request, and a confirmation code ties the browser session to the signed response
Revocation Mechanism Log entries with codes 800-999 revoke a card (quiet 8xx, loud 9xx) with an effective date; revocations cannot be erased, and standing is restored by issuing a successor card; presses can be revoked by the press registry body
Agent Types Supported People, communities and organisations through cards, and services such as presses; any holder of a card key
Wallet/Client Types Wallet services that hold encrypted keyrings and messaging endpoints, with web and mobile SDKs; anyone may run one
Recovery Mechanisms A YubiKey-based backup with a 72-hour window in which any registered cancellation credential can abort recovery, with notifications sent on all configured channels; recovery is independent of the primary wallet service. Guardian-quorum social recovery is a future item
Compliance / Regulations Not stated by the project.
Credential Exchange Protocols The protocol's own signing and authentication request flow (CHAPI routing, a direct fetch, optional OHTTP) and its card-offer messages; no OpenID4VC or DIDComm
Credential Exchange Protocols - List
Trust Framework Chains of policy-defined cards back to a trusted root; the card protocol's presses sign only for policy adherence; a governance board is designed to update the protocol and address violations such as fraud
Cost Model Low-cost writes: presses pay roughly $0.005 per card and may choose to charge for cards; no token
Censorship Resistance Moderate by design, unproven in practice: anyone can run wallet services and presses must be authorized on-chain, but press authorization is revocable by a governance body and the system depends on Arbitrum One and IPFS availability

Relationships

How this tool connects to other tools and organizations, from relationships reviewed by the OpenHaven data steward. They describe how projects connect, not how good they are.

Based on
Speaks protocol
Stores in