arXiv:2606.16223v1 [cs.CR] 15 Jun 2026
did:crdt: Coordination-Free Decentralised Identifiers via Signed CRDTs Hugo O’Connor
Claire Barnes
Anuna Research [email protected]
Anuna Research [email protected]
Such a total order is as hard as consensus (total-order broadcast is consensus-equivalent [2]). Blockchain methods (did:ethr [12], did:ion [7]) pay exactly this cost: fees, seconds-to-minutes latency, and connectivity for every mutation. Peer methods (did:key [8], did:peer [9]) avoid it by freezing the document, which then cannot rotate keys, add devices, or synchronise. Sidetree [7] adds a CRDT-like delta log but still anchors it to a blockchain for total ordering before finality. No method achieves all four of no consensus, offline mutation, cryptographic authorisation, and W3C DID Core alignment; did:crdt targets all four, realising the first three and substantially the fourth (Section VIII). Motivating example. Disaster response exposes the gap: responders authenticate today with centrally issued credentials such as PIV-I/FRAC [20], where a cached trust anchor validates an existing badge offline, but enrolling a responder or revoking a lost device needs the issuing authority a disaster removes (FEMA puts revocation at a central update with an 18-hour window [21]). Consider instead one organisational DID comanaged by a few authorised devices at incident command: offline and split across sites, each evolves the shared document independently (registering radios, rotating a lost key, enrolling a replacement), and when a channel reappears they exchange signed deltas and converge to byte-identical state with no coordinator. I. I NTRODUCTION Key insight. The CALM Theorem [1] (Hellerstein and Decentralised Identifiers (DIDs) [6] are the W3C standard for Alvaro) proves that any computation expressible as a monotone self-sovereign identity (SSI), in which the subject, not an issuer function over a join-semilattice is confluent: replicas converge or registry, can control cryptographically verifiable identifiers. without coordination. If every field of a DID document is How fully a DID delivers this is method-dependent: DID Core modelled as a CRDT [11], then each transition only adds permits a controller distinct from the subject and registries that information, their composition is again a CRDT, and by are centralised, federated, or decentralised. A DID method can, CALM the merged state is confluent. We map verification however, place the identifier under its subject’s sole control with methods to a 2P-Set, services to an add-wins set, metadata to a no issuer and no single point of revocation, which did:crdt last-write-wins map, key rotation to a monotone sequence targets. This property makes DIDs fundamental infrastructure register, and deactivation to an irreversible boolean latch for verifiable credentials, decentralised authentication, and (Section IV). Signing each mutation at the application layer multi-device identity wallets. Yet every production DID method separates authorisation (local, cryptographic) from ordering, so accepts a damaging compromise: to support an evolving no consensus layer is needed. The only ordering the protocol document it coordinates through consensus, and to escape requires is causal delivery on the signed-delta path; this, unlike consensus it freezes the document. a total order, needs no agreement protocol and remains available The coordination trap. We use coordination in the preunder partition; by [3], causal consistency is the strongest model cise CALM sense [1]: blocking communication to reach any always-available, partition-tolerant system admits. agreement on a global order before a node may act. Contributions. (1) A formal seven-field CRDT composition Source code (MIT OR Apache-2.0): codeberg.org/anuna/did-crdt. for the W3C DID document data model, mapping each field to a
Abstract—Existing Decentralised Identifier (DID) methods require coordination, an agreed global order of operations, to update a DID document: blockchain-anchored methods incur fees and latency; lightweight peer methods (did:key, did:peer) offer no update mechanism; and Sidetree methods still require blockchain ordering for finality. We present did:crdt, a DID method that targets W3C DID Core and removes the need for coordination entirely: there is no ledger, no sequencer, and no global total order. Each DID document is composed of signed Conflict-Free Replicated Data Types (CRDTs), one per document field, each chosen so that concurrent edits merge deterministically. By the CALM Theorem, the state-merge path is then confluent: replicas that see the same updates reach the same document in any arrival order. The signed-delta path needs only causal delivery, applying an update after those it builds on, which is far weaker than the total ordering ledgers impose and needs no agreement protocol. We are explicit about scope: every untrustedpeer path is authenticated, so Byzantine fault tolerance (safety even when peers lie or send malformed data) holds for signed deltas and verified-bundle replay, while the unauthenticated statemerge path is a trusted-domain optimisation and key-compromise recovery is bounded by revocation semantics. We give the data and threat model, CRUD semantics, conflict resolution, and a Rust reference implementation with property-based convergence tests and microsecond-scale merge latency. Index Terms—Decentralised Identifiers, CRDT, CALM Theorem, self-sovereign identity, coordination-free distributed systems, W3C DID Core
© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.
CRDT type whose product satisfies commutativity, associativity, and idempotence. (2) The did:crdt method specification: content-addressed identifier derivation via BLAKE3-256, a typed delta vocabulary, and deterministic concurrent-merge semantics. (3) A system and threat model and security analysis (genesis attacks, delta replay, rotation races, state-size DoS, creation-flood sybil resistance, discovery-layer availability, and the limits of key-compromise recovery), with Byzantine fault tolerance established for every untrusted-peer path (signed deltas and verified-bundle replay) and explicitly not claimed for the trusted-replica state-merge optimisation. (4) A Rust reference implementation (no unsafe, WASM-compatible) with property-based convergence tests over randomised delta sequences. II. BACKGROUND A. CRDTs and the CALM Theorem
B. System Model Replicas and storage. There is no central server. Each replica holds, for every DID it tracks, the full product-CRDT state plus its delta log. The pure core is storage-agnostic (state lives in memory, persisted by the embedder if at all), and any transport that delivers signed deltas suffices: gossip, HTTP, or out-of-band media. Adversary. We assume a computationally bounded adversary that controls the network (observe, delay, replay, reorder, drop) and may operate Byzantine replicas. It cannot forge signatures or BLAKE3 pre-images. Honest replicas accept only signed deltas authorised by a non-revoked key (Section IV-C). Recency. Without a total order there is no global “latest”: CALM guarantees convergence among replicas that have seen the same deltas, not freshness. The monotone versionId lets a verifier order two states by delta inclusion, but absolute recency needs a freshness response from a well-connected peer, the deliberate cost of offline, coordination-free operation.
A CRDT’s [11] merge ⊔ forms a join-semilattice: it is III. R ELATED W ORK commutative (A ⊔ B = B ⊔ A), associative ((A ⊔ B) ⊔ C = A ⊔ (B ⊔ C)), and idempotent (A ⊔ A = A), hereafter CAI. did:key [8] derives the identifier directly from the public CAI suffices for strong eventual consistency: replicas receiving key, making the document static; did:peer [9] is likewise the same updates converge regardless of delivery order or static. did:ethr [12] stores documents as Ethereum smartduplication, with no agreement protocol. contract events, inheriting gas fees and ∼12 s confirmation The Shapiro et al. catalogue [11] enumerates the CRDT latency; Satybaldy et al. [15] benchmark such methods primitives used in this work: a G-Set (grow-only set, merge = (did:ethr at 12.9 s, $0.066/op), motivating dropping the union), an OR-Set using the ORSWOT optimisation [5] (add- ledger. Sidetree [7] is the closest structural predecessor: both wins, no unbounded tombstones), an LWW-Map (last-write- use a content-addressed delta log where each operation is a wins per key under a total timestamp order), a Max-Register typed mutation. The critical divergence is ordering: Sidetree (merge = max), and a boolean latch (merge = logical OR). requires a blockchain anchor to impose a total order, whereas Timestamps use Hybrid Logical Clocks (HLCs) [4], a triple did:crdt selects CRDT types whose merge functions are (physical _ms, counter , node_id ) that is causally consistent order-independent by construction. and bounded in skew from wall time. The node_id is derived Ledgerless verifiable history. KERI [18] and from the signer’s public key, a deterministic tiebreaker bound to did:webvh [19] drop the ledger but keep a single that key. The product of CRDTs is again a CRDT, a corollary controller’s totally ordered log, treating concurrent multiof [11]: CAI holds componentwise. device writes as equivocation to detect rather than state to The CALM Theorem [1] states a distributed program merge. did:crdt instead composes commuting CRDTs has a coordination-free, confluent implementation iff it is that converge offline with no coordinator or canonical log; monotone. Crucially, CALM asks only that merging never CRDTs have served identity data (e.g. DIF Identity Hubs) discards information; it is fine for the resolved document to but not, to our knowledge, the DID document itself as a stop showing a fact. We distinguish lattice monotonicity (merge method (Ceramic’s did:3, despite a CRDT-like reputation, only moves state upward in the semilattice), which CALM uses blockchain-anchored fork-choice that picks one canonical requires and every did:crdt field satisfies, from observable branch, not a commutative merge). monotonicity (a fact, once visible, stays visible), which several IV. T HE D I D : C R D T M ETHOD fields deliberately break: a revoked key disappears from the document, and a delta is rejected if it precedes its authorising A. Identifier Derivation key. The latter is not needed for convergence but is why A did:crdt identifier is content-addressed: the controller the signed-delta admission path is order-sensitive. Confluence constructs a genesis delta (an AddVerificationMethod is safety, not liveness: convergence still needs a transport operation with a logical timestamp of zero), and the DID that eventually delivers every update. The state-merge path is the lowercase hexadecimal encoding of the BLAKE3-256 tolerates any order; the signed-delta path needs only causal hash [10] of the compact JSON tuple (τ0 , op 0 , signer _key), i.e. delivery, which is not coordination and is strictly weaker than did:crdt:⟨BLAKE3-256(json(τ0 , op 0 , key))⟩. This tuple the consensus-equivalent total-order broadcast [2] that ledgers is hashed before the DID exists; the real DID then forms the require. Kleppmann [13] shows content-addressed hash graphs full key identifier (e.g. did:crdt:abc#key-0). Creation make CRDTs Byzantine-fault-tolerant; did:crdt applies this needs no network, registry, or synchronisation, and a given in its Merkle DAG. genesis delta deterministically yields the same DID.
B. CRDT Field Composition Figure 1 shows the architecture. The DID document state is the product of seven independent CRDT fields, each mapping a distinct portion of the W3C DID Core model [6]; an incoming signed delta is signature-verified and dispatched to the relevant field. The product is again a CRDT [11], so the state-merge path stays confluent and order-independent while the signed-delta path adds order-sensitive authorisation (Section IV-C). Each field’s merge semantics match the intended DID behaviour: • Verification methods: 2P-Set (authorized = added \ revoked , two grow-only G-Sets): a key is addable and permanently revocable but never resurrected, with full key history retained for audit. Any non-revoked key may authorise deltas. • Services: OR-Set (ORSWOT) [5]: add-wins, so a readded endpoint survives a concurrent stale removal without unbounded tombstones. • Metadata: LWW-Map: last-writer-wins under an HLC timestamp [4], with the public-key-derived node_id as a key-bound tiebreaker. • Key rotation: Max-Register: highest sequence wins; it names the active controller for external authentication but does not gate delta authorisation. • Credential revocations: G-Set: permanent and additive; never un-revokes. • Deactivation: boolean latch (merge = OR): irreversible. C. Delta Model
dedup by content hash (a delta already held is a true no-op); (2) signature verification over ⟨did , τ, P, op⟩: the signature MUST verify under a key present in the G-Set (for the genesis delta, verification uses the embedded public key); (3) causal admission: if the parents P are not all present, the result is Unknown and the delta is held pending retry rather than rejected; (4) authorisation against the delta’s causal past, not current state: the signer MUST be added there, and neither revoked nor the document deactivated there. Concurrent deltas that a revocation or deactivation has not yet reached are therefore both admitted; a current-state floor rejects only facts imported via state-merge without their originating deltas; (5) CRDT merge (safe to repeat and reorder by CAI). Order-sensitivity caveat. The stateful admission pipeline is itself monotone: its three-valued result is a flat lattice where Unknown resolves upward to Valid/Invalid as a delta’s causal closure completes and never reverses (an out-of-order delta is held pending, not rejected). The protocol thus requires causal ordering (a delta is applied after its parents) but not a causal transport: it reconstructs that order from the MerkleDAG parents, holding out-of-order deltas pending, so any delivery order converges. D. CRUD Operations Create: derive the DID via genesis hash, sign and apply the genesis delta; usable offline with no acknowledgement. Read: project the product state to W3C DID Core JSONLD; the versionId is a BLAKE3 hash of observable state, and resolution does not replay the log, so its cost is historyindependent. Update: wrap the operation in a signed delta with a fresh HLC timestamp and broadcast; it converges once causally-prior deltas arrive, duplicates idempotent. Deactivate: set the boolean latch; it propagates by OR, and per DID Core §8.2.1 the resolver then returns didDocument: null.
All mutations are signed deltas: a tuple ⟨did , τ, P, op, π⟩ where τ is an HLC triple (physical _ms, counter , node_id ), P is the (sorted, deduplicated) set of content hashes of the delta’s causal parents (the frontier its signer had observed), so a DID’s delta history forms a Merkle DAG (the genesis delta has P = ∅), op is one of E. Concurrent Merge Semantics eight typed operations (AddVerificationMethod, Concurrent edits resolve with no inter-replica communicaRevokeVerificationMethod, tion: a concurrent add/remove of one endpoint is add-wins AddServiceEndpoint, RemoveServiceEndpoint, (ORSWOT); equal-sequence RotateKeys break by greater SetDocumentData, RotateKey, RevokeCredential, BLAKE3(key_ref); same-key metadata writes by greater Deactivate), and π is an Ed25519 or secp256k1 ECDSA HLC then node_id ; and Deactivate beats any concurrent signature over canonical_json({did,τ ,P,op}), update (latch OR). so a delta cannot be re-parented without invalidating its V. S ECURITY A NALYSIS signature (ed25519-dalek and k256 back the two suites). Each AddVerificationMethod carries a SuiteType Against the adversary of Section II-B: discriminant and a relationships list (which of the five Signature-chain integrity. Every delta is signed over W3C verification relationships the key participates in; default canonical JSON including the target DID and HLC timestamp, [authentication]). The node_id in τ MUST equal the preventing cross-DID replay and tiebreaker spoofing (the lower 8 bytes of BLAKE3(public key bytes), binding the node_id binding of Section IV-C). Any non-revoked key tiebreaker to the signer’s identity; the validator recomputes it (added \revoked ) may authorise new deltas; the 2P-Set enables after signature verification and rejects on mismatch. revocation while preserving convergence (a compromised key Validating an incoming delta is a five-step gate (well- is permanently excluded via the revocation G-Set), and since formed, correctly signed, prerequisites present, signer both halves are grow-only and revocation irreversible, CAI allowed, then merge), returning a three-valued result holds. (Unknown/Valid/Invalid): (1) deserialise (deltas exceedKey-compromise recovery (a fundamental limit). Authoriing 64 KiB are rejected before processing) and idempotent sation is flat: any non-revoked key may sign any operation, so
Signed Delta ⟨ did , τ, P, op, π ⟩ validate sig π → dispatch on op
G-Set
G-Set
OR-Set
LWW-Map
Max-Reg.
G-Set
add-only
revoked keys
(ORSWOT)
HLC ts
seq # wins
revocations
OR
activeKey
revocations
deactivated
verif.Meth.
revokedVMs
service
metadata
Bool Latch
2P-Set
⟨ G-Set add × G-Set rev × OR-Set × LWW -Map × Max -Reg × G-Set × Latch ⟩ resolve()
Resolved W3C DID Document −−−−−−→ JSON-LD Fig. 1. did:crdt CRDT composition architecture. An incoming signed delta ⟨did, τ, P, op, π⟩ is signature-verified and dispatched to the appropriate CRDT field. Verification methods and their revocations form a 2P-Set (authorized = added \ revoked). The product CRDT is projected to a W3C DID Core JSON-LD document by resolve(). By the CALM Theorem [1], the state-based merge is fully order-independent; the delta admission path is stateful and requires causal delivery for convergence. τ : HLC triple (ms, ctr , node_id); π: Ed25519 or secp256k1 signature. Each delta also commits to its causal parents P by content hash (covered by π), so the history forms a Merkle DAG (Section IV-C).
a compromised key can add attacker keys, rotate, rewrite state, application-layer signatures (following Kleppmann [13]): a or deactivate the DID before detection. Revoking it halts future Byzantine node cannot forge valid deltas, and replay is misuse but cannot undo what it authorised (grow-only sets idempotent. Each delta commits to its causal past by hash, retain attacker keys; the deactivation latch is irreversible). This so that past is tamper-evident: altering or dropping an ancestor exposure is no worse than single-controller ledger methods leaves a dangling parent hash the receiver re-requests, and like did:ethr [12] but weaker than Sidetree/did:ion [7], equivocation creates content-addressed forks that surface on which separates update and recovery keys; did:crdt has no reconcile. Withholding an unseen concurrent branch stays such tier and, lacking a consensus total order, no canonical state undetectable (the DAG attests integrity, not uniqueness) but to override, so a compromised key’s writes merge rather than only delays convergence; it cannot corrupt honest state. being adjudicated away. It thus gives containment, not recovery; State-sync caveat. Convergence holds on every path; authenthe future-work mitigation (Section IX) closes this gap via M - ticity (each delta signed by an authorised key) only on the auof-N signatures for sensitive operations or a recovery-key thenticated paths: the live gossip ingest, which signature-verifies policy. every inbound delta, and merge_verified_bundle, Metadata-ordering integrity. LWW-Map writes order by which re-derives state by replaying a content-addressed bundle the HLC physical-millisecond component (the node_id secures of signed deltas through full signature and admission checks. only the tiebreaker), so a Byzantine authorised signer can The unauthenticated merge_state, which imports another inflate its timestamp to dominate a metadata key; the HLC replica’s state without re-verifying signatures, is retained only skew bound limits this within the skew window. Metadata as a trusted in-process optimisation (e.g. replica duplication needing tamper-evident concurrency should use the OR-Set within one operator’s deployment); invoking it with an untrusted field, whose add-wins merge keeps all concurrent writes. source voids Byzantine safety. A remove cancels exactly the Genesis, replay, and DoS. Only adds in its causal past (fixed by its content-addressed parents), AddVerificationMethod is permitted on an empty so delta replay resolves concurrent add/remove add-wins like document, blocking pre-genesis Deactivate/RotateKey the state join (⊔). attacks; forging the DID = BLAKE3-256(genesis) requires Sybil resistance. Minting a validly-formed DID costs only breaking 256-bit pre-image resistance. Replay is harmless by a keygen and one hash, so an adversary could flood spurious idempotence (a delta already in the DAG is a no-op), and creations. The planned (unimplemented) layered defence is concurrent rotations are all admitted and resolved by the a 20-bit genesis proof-of-work (∼0.5 s per DID, ∼106 × perMax-Register (higher sequence wins, BLAKE3 tiebreak). A DID batch-flood cost; updates exempt), per-IP creation rate 64 KiB per-delta limit bounds per-delta cost, and resolution limits, and optional invitation codes for closed namespaces. projects materialised state independent of history length; Meanwhile the admission control of Section VI (a node stores bounding cumulative log growth via checkpoint compaction is an unknown DID only when a local resolution request solicits future work. it) discards floods without storage. Byzantine fault tolerance (delta path). did:crdt Discovery-layer availability. The discovery keypair is achieves BFT on the delta path via content-addressed hashes, derived from the public DID (Section VI), so anyone knowing deterministic validity (non-revoked G-Set membership), and a DID can publish over the record. Redirection cannot forge
a document (genesis and delta-chain verification authenticate content), costing only a wasted connection; erasure (overwriting the single-writer record) can suppress cold-start discovery, a publish-rate race. Both touch first-contact only (nodes already holding or gossiping the document are unaffected) and never risk integrity; controller-signed records and erasure-resistant rendezvous are future work (the race is inherent to identifierderived keys, the model BitTorrent runs at scale). Revocation is likewise irreversible by design. VI. R ESOLUTION & D ISCOVERY Resolution (DID string to DID document) is a two-layer process. A. Local Resolution The resolve() function is a pure projection requiring no network call: it materialises the product CRDT state into the three-part envelope mandated by DID Core §7.1 (didResolutionMetadata, didDocument, didDocumentMetadata). Each CRDT field maps to its DID Core property: the 2P-Set yields verificationMethod (excluding revoked keys) and populates the five verification-relationship arrays; the OR-Set yields service; the LWW-Map yields document properties; the latch sets deactivated. Metadata carries created/updated and a versionId (BLAKE3 over observable state). For deactivated DIDs the resolver returns didDocument: null per §8.2.1.
content). It is implemented and exercised by in-process and cross-process (two service binaries against a pkarr relay stub) cold-start tests; live public-DHT validation is future work. C. Cost Analysis Per-DID cost contrasts sharply with ledgers (protocol-level, from [15] where available): per update did:ethr costs $0.066 at 12.9 s and did:hedera $0.00015 at 4.2 s, whereas did:crdt has zero fees and <90 µs local merge (hosting $4–8/mo versus $30–100). did:crdt’s figures are local and exclude its not-yet-measured availability layer, whereas ledger latency folds in global propagation and consensus; a wide-area comparison awaits a complete stack. Each signed delta is 200–500 bytes and the full log is retained, so a DID’s footprint is its materialised state plus history. Measured state RAM (log excluded) is 1.0 KiB (1 key/1 service), 4.4 KiB (10/10), and 37.9 KiB (100/100), so a 1 GiB node holds ∼1.0 M small DIDs’ state; history adds 200–500 bytes per update until checkpoint compaction (future work) bounds it. VII. I MPLEMENTATION & E VALUATION A. Reference Implementation
The reference implementation is a Rust library (did-crdt, Rust ≥ 1.75) with zero unsafe blocks, compiling to WebAssembly, in three feature layers: default (pure core, no I/O), sync (iroh P2P delta gossip), and service (axum HTTP resolver, independent of sync). The pure core (∼3,700 non-blank lines) is self-contained and embeddable in mobile B. Delta Discovery (FFI), WASM, and edge contexts. Key dependencies: crdts 7 The pure core is deliberately transport-agnostic: any mech- (G-Set, LWW-Register), blake3 1, ed25519-dalek 2, anism that delivers signed deltas to a replica is sufficient. serde; the service-endpoint ORSWOT is implemented directly The core implements transport-agnostic anti-entropy: replicas so a remove cancels exactly the adds in its causal past. exchange frontiers (hashes of the latest deltas each has seen) and ship only the missing deltas with their ancestors, so cost is B. Correctness Testing proportional to the difference, not the history. Three discovery The test suite comprises 262 functional tests (276 with modes exist at varying maturity: service, 314 with sync), most verifying distributed-system (1) Gossip mesh (implemented): the sync feature’s iroh- properties. Property-based tests (proptest, 256 cases each) gossip [16] engine does frontier exchange (ANNOUNCE, RE- check the CRDT laws (CAI) over random delta sequences, QUEST with frontier, return the deltas above it); inbound deltas plus rotation convergence at equal sequence, revocation monoare signature-verified at the trust boundary, and an integration tonicity, deactivation irreversibility, and signed-delta/state-join test reconciles two real iroh endpoints over the wire. (2) HTTP agreement on concurrent add/remove of a service endpoint. resolver (implemented): the service feature (independent Convergence tests simulate partition and reunion (50/30 conof sync) exposes an axum GET /{did} endpoint for web- current deltas merging identically; all 24 permutations of four compatible resolution from an in-memory store. (3) Out-of- deltas byte-identical; three-replica order-independence). Further band transfer (core API): for air-gapped use, signed deltas suites cover the gossip state machine and HTTP CRUD, each (or, with the Section V caveats, serialised state) transfer via CRDT primitive, ∼4 M-iteration fuzzing of deserialisation (no QR, NFC, Bluetooth, or USB. panics), and Merkle-DAG admission and authenticated sync, Cold-start resolution (locating a never-seen DID’s deltas) including a two-endpoint live-transport convergence test and a derives a keypair deterministically from the DID’s BLAKE3 forged-signature rejection on the gossip ingest. hash: any holder publishes a signed pkarr record [17] (publickey addressable records over the mainline BitTorrent DHT or C. Performance an HTTP relay) advertising its iroh address, and a resolver Median merge latencies (Criterion 0.5, release+LTO, Apple derives the same key, finds a holder, and bootstraps via empty- M2 3.49 GHz, via the committed benches/ harnesses) are frontier anti-entropy; a forged record only wastes a connection, 5–8 µs on small documents (1 key/1 service), 11–14 µs medium never forging a document (genesis re-derivation authenticates (10/10), and 70–88 µs large (100/100), including Merkle-DAG
admission but not signature verification; every small-document operation exceeds 140 K ops/s. Resolve latency is 1.8–74 µs for the local projection (no network round-trip, assuming the deltas are already held); the cost of obtaining them is the not-yet-measured availability layer (Section VI), so this is not an end-to-end comparison with blockchain reads. D. Deployment at Scale Garzón et al. [14] identify decentralised identity as critical 6G infrastructure. A key-rotating sensor fleet shows the gap: at ∼1,440 deltas/day per unit, a 10,000-sensor fleet on the cheapest ledger (XRPL, $0.000026/op [15]) costs $137 K/year with per-mutation connectivity, whereas did:crdt runs it offline fee-free; retained history (∼3–7 GB/day) needs the future-work compaction, and storage scales with replicas, not a shared ledger. VIII. D ISCUSSION Resolution and did:peer. did:crdt replaces the blockchain VDR with the CRDT state itself; in interactive flows the owner presents (did , [δ0 , . . . , δn ]) directly, like did:peer [9] numalgo 2. But did:peer documents are static and ephemeral, whereas did:crdt merges multi-replica updates deterministically, supports persistent identities with full key lifecycle, and falls back to gossip/DHT resolution. W3C DID Core alignment. The resolver emits the mandatory @context and the DID Core §7.1 resolution envelope, validated by construction and unit tests. We claim alignment, not certified compliance: the conformance suite and DID Method Registry submission are future work. Applicability. did:crdt suits owners controlling multiple intermittently-connected devices (wallets, IoT fleets), frequent fee-free updates, or offline operation. It is less suitable where an operation’s legal effect depends on a single authoritative order (e.g. eIDAS, where signature validity turns on revocation timing) or where the identifier must be publicly discoverable with no prior relationship. Implementation limitations. The core covers the full CRDT model; the gossip protocol, live iroh transport, service-binary integration, and pkarr DHT cold-start discovery with admission control are implemented and tested. Unimplemented: durable persistence (in-memory store; a SQLite layer is specified but unbuilt); the sybil-resistance layers of Section V; hardened discovery; and wide-area convergence measurement. IX. C ONCLUSION We have presented did:crdt, a DID method aligned with W3C DID Core that achieves consensus-free, offlinecapable, cryptographically authorised identity management by composing CRDTs. Mapping each document field to a CRDT makes the model a join-semilattice, so CALM [1] guarantees confluence without consensus given eventual delivery, while application-layer signing separates authorisation from ordering: the state-merge path needs no order, the signed-delta path only causal delivery. We are explicit about the boundaries: Byzantine fault tolerance holds for the signed-delta path but
not the unauthenticated state-merge API, and revocation gives containment, not recovery, from key compromise. Future work spans stronger authorisation (M -of-N threshold signing to bound single-key compromise); compact state via Merkle-inclusion proofs plus checkpoint compaction; completing the networking stack (durable persistence, sybil-resistance layers, hardened discovery) with wide-area measurement; W3C DID Method Registry submission and the conformance suite; and formal verification of the merge laws. ACKNOWLEDGMENTS AI Disclosure. Per IEEE policy, the authors disclose that AI assistants were used for drafting, implementation, and literature review; all work was directed, reviewed, and validated by the authors, who take full responsibility. R EFERENCES [1] J. M. Hellerstein and P. Alvaro, “Keeping CALM: when distributed consistency is easy,” Commun. ACM, vol. 63, no. 9, pp. 72–81, Sep. 2020. [2] T. D. Chandra and S. Toueg, “Unreliable failure detectors for reliable distributed systems,” J. ACM, vol. 43, no. 2, pp. 225–267, Mar. 1996. [3] P. Mahajan, L. Alvisi, and M. Dahlin, “Consistency, Availability, and Convergence,” Univ. of Texas at Austin, Tech. Rep. TR-11-22, 2011. [4] S. Kulkarni, M. Demirbas, D. Madappa, B. Avva, and M. Leone, “Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases,” UB TR 2014-04, 2014. [5] A. Bieniusa, M. Zawirski, N. Preguiça, M. Shapiro, C. Baquero, V. Balegas, and S. Duarte, “An optimized conflict-free replicated set,” arXiv:1210.3368, 2012. [6] M. Sporny, D. Longley, M. Sabadello, D. Reed, O. Steele, and C. Allen, “Decentralized Identifiers (DIDs) v1.0,” W3C Recommendation, Jul. 2022. [7] D. Buchner, O. Steele, and T. Ronda, “Sidetree Protocol Specification,” Decentralized Identity Foundation, 2021. [8] D. Longley, D. Zagidulin, and M. Sporny, “The did:key Method v0.9,” W3C CCG Editor’s Draft, 2024. [9] D. Hardman, S. Curran, and S. Curren, “Peer DID Method Specification v2.0,” DIF, 2020. [10] J. O’Connor, J.-P. Aumasson, S. Neves, and Z. Wilcox-O’Hearn, “BLAKE3: One Function, Fast Everywhere,” BLAKE3 Team, 2020. [11] M. Shapiro, N. Preguiça, C. Baquero, and M. Zawirski, “Conflict-Free Replicated Data Types,” in Proc. SSS, LNCS vol. 6976, 2011, pp. 386– 400. [12] M. Nistor, Ed., “ETHR DID Method Specification,” DIF, 2026. [13] M. Kleppmann, “Making CRDTs Byzantine fault tolerant,” in Proc. PaPoC, 2022, pp. 8–15. [14] S. R. Garzón, H. Yildiz, and A. Küpper, “Decentralized Identifiers and Self-Sovereign Identity in 6G,” IEEE Network, vol. 36, no. 4, pp. 142– 148, Jul. 2022. [15] A. Satybaldy, K. Tylinski, and J. Xu, “Decentralized Identity in Practice: Benchmarking Latency, Cost, and Privacy,” arXiv preprint arXiv:2601.20716, Jan. 2026. [16] n0, Inc., “iroh: A Toolkit for Building Distributed Applications,” https: //iroh.computer, 2024. [17] “pkarr: Public-Key Addressable Resource Records,” https://pkarr.org, 2024. [18] S. M. Smith, “Key Event Receipt Infrastructure (KERI),” arXiv:1907.02143, 2021. [19] S. Curran, J. Jordan, et al., “The did:webvh DID Method, v1.0,” Decentralized Identity Foundation, 2025. [20] U.S. Dept. of Homeland Security, Science & Technology Directorate, “Moving Towards Credentialing Interoperability,” 2010. [21] FEMA, “NIMS Guideline for the Credentialing of Personnel,” U.S. Dept. of Homeland Security, 2011.