a witness for atproto identity

DIDMARC — hold the directory accountable

DID Mapping Alignment, Reporting & Conformance — an independent accountability layer for atproto identity.

Independent, on-chain proof that plc.directory serves a DID's complete, current, and non-equivocated history — exposed as a graduated status any resolver or PDS can enforce unilaterally, with no network coordination and no protocol change.

Open the console →

The gap a signature leaves

An atproto identity is a signed, hash-linked log of operations, served from a single directory. Every operation is self-certifying — but a signature only vouches for the operation it's attached to. It can't tell you whether the directory showed you all of them, the latest ones, or the same ones it showed everyone else.

What a signature proves

This operation is authentic — signed by a key that was valid at the time. PLC already gives you this, per operation.

What it can't

That you were shown the complete, current, and non-equivocated history. No signature can speak for the operations it isn't on — including the ones you never saw.

What a directory can do to you

That gap isn't theoretical. Every operation can be perfectly signed and the directory can still deceive you, because it alone decides which operations you see. None of the attacks below needs a stolen key — only control of the directory a resolver trusts:

Omission — undo a fix

Your account key is stolen, so you do the right thing and rotate it out with a new signed operation. The directory serves your history with that one operation missing — so to the rest of the network the stolen key is still live, and the thief keeps signing as you.

The lie is the operation left out.

Erasure — make someone vanish

The directory simply returns nothing for a DID that plainly exists. Every app that looks the person up sees no such identity — handle dangling, posts unresolvable — with no error to appeal.

Absence carries no proof to check.

Split-view — two faces

Show the victim their real history, while showing one targeted service a forked version that points their account at a server the attacker runs. Neither side ever sees the other's copy.

No one viewer holds both halves.

Each of these is a real, ground-truthed scenario in the adversarial report. DIDMARC is the layer that catches them: independent, on-chain proof of the whole, current history, so a resolver can tell when the directory's answer doesn't add up.

How it works

Each opted-in DID's full operation log is re-verified from genesis inside a Starknet contract — the network proves the computation and settles to Ethereum; there is no bespoke prover and no trusted snapshot. The contract commits a proven DID→document root. A resolver fetches a document from the directory and checks it against that root, getting back a status. plc.directory stays canonical; DIDMARC is a read-side witness that anyone turns on alone — no coordination and no protocol change.

The graduated status

confirmed — head committed past the 72-hour recovery window; immutable. The strongest assertion.
tentative-consistent — the on-chain view agrees with the directory, but the head is still within the recovery window (or explained by clock skew).
diverged — the directory's served head contradicts the proven head. This is the alarm that fires on omission and erasure above: warn, quarantine, or refuse to relay.
absent — DID not anchored; no opinion. DIDMARC has nothing to say about an identity nobody opted in.

Never a false diverged. A directory that's merely running ahead, or a contradiction that plain clock skew could explain, stays at tentative-consistent — not an alarm. A false alarm gets the check switched off, so that restraint is exactly what makes diverged mean something.

Adoption is a ramp: start by just logging the status, then quarantine on diverged, then refuse to relay — each resolver decides on its own, at its own pace.