ACDC (Authentic Chained Data Containers)
Identity Protocol
Community
Links
Details
License Open source — Apache 2.0 for code; OWF Contributor License Agreement 1.0 for specification text; canonical specification repository at github.com/trustoverip/kswg-acdc-specification; reference implementations available across the WebOfTrust GitHub organization
Dev Status 🟢 Active
Dev Status Detail Released / Active — v1.1 specification published; IETF Internet-Draft active (draft-ssmith-acdc-03); production-deployed via GLEIF vLEI; reference implementations in multiple languages; ongoing refinement through the KSWG. Note: the original TSS0033 ToIP draft repository (2021) is archived; canonical work continues at trustoverip/kswg-acdc-specification
Owner Samuel Smith (Prosapien) — primary author; Philip Feairheller (GLEIF) — co-author; Kevin Griffin (GLEIF) — editor; co-incubated at Trust Over IP Foundation via the KERI Suite Working Group (KSWG); IETF Internet-Draft track. Contributors include Nuttawut Kongsuwan, Henk van Cann (Blockchainbird), and Kor Dwarshuis (Blockchainbird)
Country International specification development (United States lead authorship — Samuel Smith / Prosapien; Philip Feairheller / GLEIF — international); ToIP is internationally chartered; IETF is internationally chartered
Start Year 2020
Stack Specification document (Spec-Up-T markdown source); JSON Schema 2020-12 dialect for ACDC schemas; CESR (Composable Event Streaming Representation) for native wire format; reference implementations in Python (keripy / signify-py); TypeScript (signify-ts); additional language implementations under the WebOfTrust organization
Funding GLEIF (Global Legal Entity Identifier Foundation) for vLEI production deployment funding; ToIP Foundation member organizations; Prosapien and other commercial implementers; DARPA funded early KERI research that ACDC builds on; HealthKERI for healthcare-sector deployment work
Last Investigated Jul 1, 2026
Identity Protocol Attributes
Origins Self-sovereign identity and verifiable credentials (designed as a variant of W3C Verifiable Credentials addressing perceived limitations); supply chain provenance; delegated authorization chains; emerged from Samuel Smith's broader KERI ecosystem work as the credential and attestation layer atop KERI's identifier substrate; co-evolved with GLEIF's vLEI program for verifiable Legal Entity Identifiers
Database N/A — ACDC is a credential format specification; persistence is implementation concern. Reference implementations typically use LMDB for KERI key event log storage and transaction event log (TEL) state; the ACDC specification itself mandates no backend
Query Language N/A — ACDC is a credential format; lookups are by SAID (content-addressable) or by edge traversal in the chained graph; no query language defined in the specification
Data Formats Multiple supported serializations — JSON (most common in examples), CBOR, MGPK (MessagePack), and CESR (KERI's native composable wire format optimized for both text and binary with lookahead streaming properties). Schemas use JSON Schema 2020-12 dialect with composable oneOf operators. All serializations are content-addressed via SAIDs. Each ACDC is internally structured as ordered field maps with top-level fields v (version), t (message type), d (SAID), u (UUID), i (issuer AID), rd (registry SAID), s (schema), a/A (attribute/aggregate section), e (edge section), r (rule section)
Mobile Support Yes — signify-ts targets browser and mobile JavaScript environments; KERIA-based agents are designed for cloud or mobile deployment with edge agents (Signify) for constrained devices; reference implementations support standard JavaScript and Python mobile environments
Web Support Yes — signify-ts for browser JavaScript; KERIA agents expose HTTP-based interfaces; ACDCs are designed for web-deliverable verifiable credentials
Native Apps Yes — wallet and agent implementations exist via KERIA and various commercial offerings in the ToIP and GLEIF vLEI ecosystem (ProSapien, Provenant, others); GLEIF tooling for vLEI credential lifecycle management
Terms Open Source / Free — OWF Contributor License Agreement 1.0 for specification text; Apache 2.0 for source code
Funds Not separately disclosed at the specification level; GLEIF's vLEI program represents the largest concrete funding stream for KERI/ACDC infrastructure (vLEI deployment funded through GLEIF's operational budget for the global LEI ecosystem)
Based On Built on KERI (Key Event Receipt Infrastructure) for identifier and key state substrate; built on SAID (Self-Addressing Identifier) specification for content-addressable digests; built on CESR (Composable Event Streaming Representation) for native wire format; complemented by IPEX (Issuance and Presentation Exchange Protocol), OOBI (Out-Of-Band Introductions), did:keri DID method, and Transaction Event Logs (TELs) for revocation state; variant of W3C Verifiable Credentials data model; JSON Schema 2020-12 for schemas; influenced by Ricardian Contracts pattern for the rules section
Permissions Capability-style authorization expressed through chained ACDCs — each ACDC in a chain may delegate or attenuate authority to its issuee, who may then issue further ACDCs downstream. Delegation chains are end-verifiable from any leaf back to a root of authority. Rules section (r field) carries Ricardian contractual obligations binding to the credential. Chain-Link Confidentiality enforces permission rules cryptographically across the disclosure chain. Multi-signature thresholds at the AID level for multi-party permission
Authentication & Identity ACDC issuance and presentation are authenticated through KERI-anchored AID signatures. The Issuer AID (`i` field) is a KERI Autonomic Identifier whose control authority is established via KERI's verifiable Key Event Log. Verification of any ACDC requires verifying the Issuer's KEL key state at the time of issuance, then verifying the digital signature on the ACDC's SAID. For Targeted ACDCs (with an Issuee AID in the attribute section), the Issuee can also make non-repudiable commitments to the credential, enabling provable disclosure by the holder
Storage Model Per-issuer Key Event Log (KEL) maintained by the issuer's KERI infrastructure; per-credential registry state in Transaction Event Logs (TELs) for issuance, revocation, transfer, and retraction events; ACDC documents themselves are content-addressable via their SAIDs and may be stored anywhere (cached, attached, or distributed); chained edges reference other ACDCs by SAID enabling fragment-by-fragment graph distribution
Interoperability High within the KERI ecosystem — composes natively with KERI identifiers, did:keri, CESR wire format, IPEX presentation protocol, and OOBI discovery. Optional interoperability with W3C VC ecosystem (ACDC is positioned as a VC variant; JSON serialization can be processed by VC tooling). Compatible with W3C DIDs via did:keri or did:webs. Bridges to other DID methods feasible through KERI-based attestation. ACDCs are explicitly designed to be portable across trust domains without shared trust assumptions between Controllers and Verifiers
Data Portability High — ACDCs are content-addressable (via SAID), self-contained, and verifiable without online lookup once the issuer's KEL state is established. Credentials portable across any infrastructure that supports KERI verification. Multiple serialization formats (JSON, CBOR, MGPK, CESR) enable cross-platform exchange. Chained edges reference other ACDCs by SAID, so partial graph fragments can be exchanged without exposing the full chain
Governance & Decision Making Trust Over IP Foundation stewardship via the KERI Suite Working Group (KSWG); IETF Internet-Draft process for formal standardization; Samuel Smith (Prosapien) as primary author and technical lead; multi-stakeholder editorial group including GLEIF, Blockchainbird, and others; specification developed via the trustoverip/kswg-acdc-specification GitHub repository with public pull-request process; production deployment governance handled by GLEIF for the vLEI ecosystem
Protocol Maturity / Standardization Released / Production-active — v1.1 specification published; IETF Internet-Draft active (draft-ssmith-acdc-03); GLEIF vLEI is the largest concrete production deployment; multiple reference implementations mature; ongoing standardization through ToIP KSWG; pre-IETF-final but with substantial real-world adoption ahead of formal RFC publication
Identity Standards KERI (identifier substrate); SAID (content-addressable identifiers); CESR (wire format); did:keri DID method; W3C Verifiable Credentials (as a variant); W3C DIDs (composable via did:keri); JSON Schema 2020-12. Composable with ToIP's Trust Spanning Protocol and Trust Registry Query Protocol
DID Methods Supported Native: did:keri (primary, KERI-anchored). Compatible: did:webs (web-anchored KERI variant); ACDCs can reference any DID method as an identifier value, but verifiable trust semantics depend on the KERI substrate. Other DID methods may appear in ACDC content but their key state verification is delegated to their respective resolvers
Key Management Inherited from KERI — pre-rotation key management (next key committed in advance via hash, eliminating the rotation vulnerability window); multi-signature thresholds for multi-party control; delegated identifiers for hierarchical key management; post-quantum secure when paired with post-quantum signature algorithms. ACDC issuance is bound to the issuer's KERI key state at time of signing
Credential Types ACDC variants — Public, Private, Metadata, Compact, Uncompacted, Targeted, Untargeted, Bespoke. Variants are determined by the presence or absence of UUID (u), Issuee (i), and field expansion state. Public ACDCs allow rainbow-table attacks on schema-known fields; Private ACDCs include high-entropy UUIDs that blind contents. Targeted ACDCs have an Issuee AID enabling delegation chains; Untargeted ACDCs provide verifiable authorship attestations without a specific recipient. Metadata ACDCs enable contractually-protected pre-disclosure negotiation. Bespoke ACDCs are disclosure-specific issuances bound to particular disclosure events
Verification Method Multi-step — (1) verify the Issuer's KERI Key Event Log to establish their current key state; (2) verify the ACDC's digital signature against that key state; (3) verify the ACDC's SAID against its content (digest equivalence); (4) verify the schema SAID against the ACDC's structure (JSON Schema validation); (5) traverse the edge graph to verify any chained ACDCs recursively; (6) check the Transaction Event Log (TEL) for issuance/revocation state. Verification is end-verifiable and does not require trusted intermediaries
Privacy Features Comprehensive multi-layer privacy model. Graduated Disclosure: Compact ACDCs hide field contents behind SAIDs; Private ACDCs use high-entropy UUIDs to blind contents; Partial Disclosure exposes some sections while hiding others; Selective Disclosure (via the Aggregate section A field) discloses individual attributes from a blinded aggregate without revealing others; Contractually Protected Disclosure binds the discloser and disclosee to terms-of-use before any disclosure occurs (via the Metadata ACDC pattern). Chain-Link Confidentiality protects against unpermissioned downstream sharing through cryptographic chain rules. Pairwise AIDs supported for unlinkability across relationships. Bulk-issued credentials with independent registries minimize correlation
Authentication Methods KERI AID signature-based — Issuer signs the ACDC with the private key corresponding to the current key state in their KEL; Issuee can counter-sign via their own AID for offer/agreement flows. IPEX (Issuance and Presentation Exchange Protocol) defines the message exchange patterns for offer, agreement, issuance, and presentation. Mutual authentication via paired AID interactions. Out-Of-Band Introductions (OOBI) provide identifier discovery
Revocation Mechanism Transaction Event Log (TEL) registries — each ACDC's `rd` field references a TEL registry that maintains dynamic state for the credential including issuance, revocation, transfer, and retraction events. TEL events are anchored in the issuer's KEL, providing non-repudiable state transitions. Supports both blindable (privacy-preserving) and public TEL updates. Ledger-less — no on-chain revocation lookup required; verifiers consult the TEL referenced by the credential
Agent Types Supported Humans, organizations (notably Legal Entities via vLEI), services, devices, sensors, IoT endpoints, software agents — any entity capable of controlling a KERI AID can issue or hold ACDCs. GLEIF's vLEI program uses ACDCs for Legal Entity-issued credentials at production scale. Untargeted ACDCs enable sensor and observation-source attestations. Targeted ACDCs support delegation chains where issuees become issuers downstream
Wallet/Client Types KERIA-based cloud agents; Signify edge agents (mobile/browser via signify-ts and signify-py); GLEIF vLEI tooling (issuer wallets, QVI wallets, holder wallets); commercial wallets from ProSapien, Provenant, and other ToIP ecosystem implementers; reference implementations across the WebOfTrust GitHub organization
Recovery Mechanisms Inherited from KERI — pre-rotation provides built-in single-key-compromise recovery (rotate to the pre-committed next key); multi-signature thresholds for multi-party control with partial-key-loss tolerance; delegated identifiers enable hierarchical recovery via parent controller. Credential-level: revoked credentials can be reissued under new ACDC SAIDs anchored to the recovered key state
Compliance / Regulations GLEIF vLEI alignment with global Legal Entity Identifier regulatory framework; eIDAS 2.0 alignment work ongoing through ToIP and partner organizations; GDPR-compliant by KERI's non-intertwined identifier trust bases (true forgetting possible per-identifier); financial sector use cases via vLEI for KYC and trade finance; healthcare sector via HealthKERI; compliance posture is deployment-specific
Credential Exchange Protocols IPEX (Issuance and Presentation Exchange Protocol) — KERI's native protocol for issuance, offer, agreement, presentation, and revocation message exchange; CESR-streamed message exchange; mailbox-based asynchronous delivery; compatible with DIDComm for protocol-level interop with the broader SSI ecosystem; OOBI for identifier discovery
Trust Framework Trust Over IP Foundation (KERI Suite Working Group); GLEIF vLEI Ecosystem Governance Framework for production legal-entity credential use; composable with ToIP's Trust Spanning Protocol and Trust Registry Query Protocol; supports nested Ecosystem Governance Frameworks (EGFs) for application-domain-specific credential rules; the Rules section (r field) of each ACDC carries Ricardian contract terms binding the credential to specific governance
Cost Model Specification is free; reference implementations are open-source; operational costs are deployment-specific (issuer KEL infrastructure, witness/watcher networks, TEL hosting, agent hosting); ledger-less design avoids on-chain transaction fees. Commercial offerings from ProSapien, Provenant, and others price their own deployment infrastructure
Censorship Resistance High — ACDCs inherit KERI's ledger-less trust model. Issuers can move witness sets and TEL registry hosts if adversarial; credentials remain verifiable as long as the issuer's KEL and the relevant TEL state are reachable through any chosen witness or replica. No global gatekeeper for credential issuance or verification