The DFOS protocol
MARCH 9TH, 2026
The DFOS protocol is a formalized specification for cryptographic identity and verifiable content — not a library, but prose and deterministic test vectors that describe how to combine standards that already exist. Ed25519, JWS, content-addressed CIDs, JSON Schema, W3C DIDs. We handed the spec to an AI agent and asked it to produce a working implementation, and it was able to build one in three languages without any access to our codebase. The protocol infrastructure is now live in the platform, with new entities cutting over this week and the implementation open sourcing alongside it. V1 locks in this month. The public API will serve proof chains for any entity — enough for full offline verification without needing platform access.
The protocol reference is published today — 42KB of worked examples, byte-level test vectors, and everything an independent implementer would need to verify or reimplement the entire system.
A few weeks ago I posted about opening up the dark forest — portable identity, public proof verification, a DID registry that accepts any cryptographically valid identity. This is the foundation all of that sits on.
the inversion
The protocol layer deals only in proofs and keys. No content, no posts, profiles, social graph, or application concepts. It knows about two things: identity chains (who has which keys) and content chains (who committed to which document hash, in what order).
Content chain operations commit to a documentCID — a content-addressed hash of whatever the document contains. The protocol doesn't look inside and doesn't care whether the document is a post, a profile, a credential, or something that hasn't been invented yet. The chain proves that this identity committed to this exact content at this time, and that the commitment is part of an ordered, unforgeable sequence.
This is the inversion that makes the dark forest work: the proof is public, the content is private. Anyone with a public key and a chain of signed tokens can verify that a piece of content is authentic — hash the content, check the CID, walk the chain, verify the signature. No trusting the platform, no access to the database, no DFOS-specific tooling required.
The content stays in the forest. The math is in the light.
the protocol
Two chain types, three operations each. Identity chains manage keys (create, update, delete). Content chains manage document commitments (create, update, delete). Both are signed linked lists using the same mechanics — Ed25519 signatures, JWS compact tokens, content-addressed CID links.
Ed25519 is the signature scheme — what every JWT library speaks, every SSH key uses, every did:key implementation expects. It's standard everywhere rather than an ecosystem-specific bet.
JWS compact serialization is the signed envelope format. You can take any DFOS proof token, decode it with any JWT library that supports EdDSA, and get back the operation payload with a verified signature. No custom encoding, no platform-specific tooling — the proof format is the thing the entire web already knows how to verify.
Identities are self-sovereign from genesis. An identity is born with a genesis operation that declares its initial key set — auth, assert, and controller keys. The DID is derived deterministically from the genesis operation's content address. No root authority, no issuer hierarchy — the math bootstraps itself.
The protocol evolved from an earlier internal crypto layer that used secp256k1 and a more complex operation model. The current version is a deliberate simplification — fewer moving parts, standards-driven at every layer, designed so that anyone in any language can implement it with off-the-shelf libraries. The direction is toward interoperability and away from platform-specific tooling.
the content layer
The protocol is deliberately blind to content, but content needs structure. That's where document envelopes and JSON Schema come in — as an additive layer on top of the pure crypto core, not embedded in it.
Every document committed to by a content chain uses a standard envelope:
{
"content": { "$schema": "https://schemas.dfos.com/post/v1", ... },
"baseDocumentCID": null,
"createdByDID": "did:dfos:...",
"createdAt": "2026-03-07T00:02:00.000Z"
}
The envelope provides attribution, edit lineage, and timing. The documentCID in the content chain is the CID of this entire envelope, so attribution and edit history are cryptographically committed alongside the content itself.
The content field declares its type with a $schema URI. Because $schema is part of the document, it's behind the CID — cryptographically committed in the chain. Every document is self-describing, so a verifier can resolve it, read $schema, and validate against the schema without any out-of-band knowledge.
The protocol ships two standard schemas — post and profile — but these are conventions, not requirements. Any implementation can define its own content schemas, and new content types are just new JSON Schemas rather than protocol changes. An application could also skip the envelope and schema layer entirely and use a completely different content model — the protocol only cares about the CID commitment in the chain. What's behind the hash is your business.
prose + test vectors = protocol
The protocol is not a library. It's a set of instructions for combining standards that already exist — Ed25519 (RFC 8032), JWS (RFC 7515), CIDv1 with dag-cbor, W3C Multikey, JSON Schema, W3C DIDs. Every component has mature implementations in every language you'd reach for, and there's nothing proprietary in the stack. The protocol describes how to wire them together and provides deterministic test vectors so you can verify your wiring is correct.
The protocol reference includes fixed seed keys, hex-encoded dag-cbor bytes, derived CIDs and DIDs, and JWS tokens you can verify against known public keys. An independent implementer can check their work value-for-value against the spec. The three cross-language implementations (TypeScript, Go, Python — 134 checks total) were each produced by an agent working from the spec alone, without access to the codebase. The reference implementation is just one implementation — the document is the source of truth.
The did:key interop comes free — every Ed25519 public key has a canonical did:key:z6Mk... representation, so systems that don't understand did:dfos can still verify signatures through did:key.
what this means for the forest
Everything in the opening up strategy starts to become concrete with this foundation.
The SDK is the protocol package — self-contained with zero platform dependencies, publishing to npm this week. The public registry serves standard JWS envelopes that any EdDSA library can verify. View Source shows real proof tokens that a developer can decode with whatever JWT library they already use.
The custody gradient becomes practical here. Ed25519 is the key scheme the entire self-custody ecosystem already uses, and managed keys (what you have now) and self-custodied keys (what you could hold yourself) produce indistinguishable cryptographic output. The signatures are the same math — moving between custody modes doesn't change what you've signed, just who holds the key.
And the privacy model is structural, not just policy. The chain commits to hashes, the hashes commit to envelopes, the envelopes contain content. You can verify the chain without ever seeing the content — prove it's valid, unbroken, and authentic while having no idea what any of it says. If you do have the content, from any source — the app, an export, a backup, a screenshot someone sent you — you can prove it's real. Hash it, check the CID, walk the chain, verify the signature.
Dark forest with public roots.
where we are
The protocol reference is published today, with the implementation open sourcing this week and V1 of the spec locking in this month.
The infrastructure is live in the platform now — new entities start signing against the Ed25519 chain format this week. Existing DIDs and entity IDs remain stable, and the proof layer maps them to protocol identities on the fly so that existing content gains verifiable proofs without changing any identifiers. A hard cutover to native protocol DIDs is planned later this month — no disruption, no user-facing changes, just the proofs underneath your content getting stronger in a format the rest of the web can read.
The protocol is a shared substrate, not a product feature. DFOS is one application built on it. There could be others — we hope there are.
