Why
Two projects, opposite architectures, and the same premise underneath: an account or a file path is a poor long-term identity.
ERC-7812 is the standardisation attempt. Provable identity is fragmented — Privado ID, EAS, Rarimo each carry their own registry — and the proposal is to collapse that into one singleton on-chain registry where any protocol can store and prove statements by zero-knowledge proof without publishing the underlying data. Vitalik is a co-author. The Rationale section on why a singleton is the part to read, because the argument for one shared registry over many is the whole design decision and everything else follows from it. This card sits between dsrv-portal, which asks who vouches for a credential, and erc-8141, which asks what the protocol absorbs — the middle question is where the statement lives.
Docbank is the clearest example of the opposite bet, and it is worth running rather than reading about. Agents that file, retrieve and revise documents need a system of record, not a sync folder — and a file path makes a poor identity once things get moved and renamed. Docbank's answer: the catalogue stays on your machine, a document keeps its identity through moves, every version is named by a verifiable SHA-256 digest, and stale automation hits an explicit revision conflict instead of silently overwriting. That last property is the one that matters for agent-facing archives, because a silent overwrite by an agent working from stale state is exactly the failure that has no signal at run time.
Holding them in one card makes the shared conclusion visible. Both refuse to let the location be the identity — one replaces it with a registry entry provable by ZK, the other with a node ID and a content digest. The difference is where the authoritative record lives and who can be made to answer for it, and that is the same question priced-by-the-wrong-thing reaches from tokenised equity and build-rent-or-own-the-rail reaches from bank ledgers. The ledger is always the easy half.
How it works
Same premise, opposite architectures
| ERC-7812 | Docbank | |
|---|---|---|
| What it refuses | One registry per identity protocol | A file path as identity |
| Identity is | A registry entry, provable by ZK | A stable node ID surviving moves and renames |
| Version identity | The statement, unpublished | Immutable, SHA-256-addressed |
| Where the record lives | On-chain, singleton | Your machine |
| Who can vouch | Any protocol writing to it | You — the daemon owns the vault |
| Failure it designs against | Fragmentation across registries | Silent overwrite by stale automation |
What to read in the standard
The Rationale, and specifically why a singleton. The argument that one shared registry beats many is the design decision; storage layout, proof format and interface all follow from it. The reference implementation (rarimo/evidence-registry) is where to check whether the argument survives contact with code.
What Docbank does that a sync folder does not
| Property | How |
|---|---|
| One authenticated daemon owns a vault | CLI, web app, TUI, scripts and external agents all speak the same loopback-authenticated HTTP/OpenAPI contract |
| In-process option | Go programs embed an independently rooted vault via go.kenn.io/docbank, skipping the daemon |
| Stale writes conflict, not overwrite | Writes carry revision preconditions |
| Deletion is staged deliberately | Trash → permanent delete → GC → pack reclamation are separate decisions, with revision-bound restore in between |
| Blobs without ceding the catalogue | Loose or packed, optionally in fenced filesystem or S3-compatible stores — Docbank verifies but does not encrypt them |
| Recovery is provable rather than assumed | Incremental snapshot repositories verified end-to-end before a restore is published; restore is topology-independent |
| Supply-chain check | Installers refuse any archive whose digest does not match the release SHA256SUMS |
Apache-2.0, Go 1.26+ with CGO and Node 24+ to build from source. Sibling project to msgvault, which does the same for messages.
The shared conclusion
Neither lets the location be the identity, and both make the record verifiable by something other than trust in a provider. The registry does it by publishing a proof and withholding the data; the vault does it by publishing nothing and keeping a digest. Which one is right depends entirely on who has to be convinced — a counterparty who was never in the room, or you in five years.