OpenETR Overview¶
OpenETR is a protocol for deriving consequential state from end-verifiable evidence concerning durable electronic records.
Its governing verification discipline is simple:
Each proof proves only what it proves.
The model is summarized in the OpenETR Axioms: ten foundational propositions and five short maxims connecting artifact identity, signed evidence, derived state, and external recognition.
The OpenETR committee draft consolidates the model into a standards-style specification with conformance requirements and a normative Nostr profile. It is a project draft and is not an approved National Standard of Canada.
If this is your first encounter with OpenETR, start with one practical question: how can another party determine what happened to a digital record without having to trust the application displaying it? OpenETR answers by keeping the identifiable content, the signed evidence, the derived state, and external recognition separate.
It is not limited to warehouse receipts. The Warehouse Receipts workspace is the first focused domain adapter, and the Product Passports workspace is the next domain surface. The underlying OpenETR model is intended to support Digital Artifacts such as bills of lading, certificates, credentials, secured finance records, product data artifacts, and other electronic transferable records.
The model can be read from left to right:
Digital Artifact -> Digital Controllable Record -> Consequential State -> Digital Original
Consequential State -> Recognition -> Effect
OpenETR calls the identifiable content a Digital Artifact. It calls the signed evidence a Digital Controllable Record (DCR). A DCR may be one independently verifiable signed record or a graph of related records containing evidence of consequential actions. Consequential state is what follows when validated evidence is evaluated according to an identified ruleset. A Digital Artifact for which consequential state has been established through a DCR is a Digital Original.
Cryptography validates the evidence. An identified ruleset determines what follows.
The DCR is not the file, and the word “controllable” does not automatically give it legal status. Legal recognition remains a separate question.
A verifier should therefore report artifact integrity, event authenticity,
graph continuity, transition validity, consequential state, retrieval
coverage, evidence sufficiency, temporal assurance, actor recognition, system
reliability, and external effect as separate dimensions where applicable. It
should not compress them into one universal valid result.
For a complete worked example, see the English Gutenberg reconstruction in the Digital Originality brief.
For the conceptual basis of treating exact copies as the same artifact while deriving a singular consequential state from signed evidence, see the Records-First Authenticity And Digital Originality Design Note.
How The Implementation Fits¶
Domain adapters Warehouse Receipts, Product Passports, bills of lading, credentials
OpenETR protocol DCR evidence, state transition rules, consequential state
Nostr event substrate signed events, kinds, tags, relays, event ids
Outside the protocol recognition by law, contracts, registries, and institutions
OpenETR sits in the middle. It turns domain actions, document identities, control assertions, and evidence links into signed protocol evidence without forcing every domain to share the same user interface, vocabulary, statute, or business process.
The host system remains responsible for the path from request to real-world operation: authenticating its users, applying permissions, obtaining approvals, and controlling whatever execution boundary it owns. OpenETR records attributable evidence concerning the Digital Artifact and derives protocol state from the resulting DCR. A recognition layer then determines whether that state is accepted for a particular operational, institutional, commercial, or legal purpose.
host system proposal -> authorization -> protected operation
OpenETR signed evidence -> DCR validation -> consequential state
outside protocol recognition -> operational or legal effect
A signature commits a statement to the evidence graph. It does not, by itself, prove that the statement was authorized, that an external operation occurred, or that every alternative path was controlled. Relay acceptance distributes evidence; it does not provide global ordering, consensus, or legal effect.
What OpenETR Provides¶
OpenETR defines:
- digest-addressed Digital Artifacts;
- Digital Controllable Records made of signed end-verifiable events;
- state transition rules for deriving state from DCR evidence;
- Anchor Events that begin candidate DCRs;
- evidence events for transfer, encumbrance, discharge, redemption, termination, and attestation;
- linked evidence records for supporting documents and lifecycle evidence;
- profile-backed signing;
- object-centric relay queries;
- Evidence Graph and Control Graph traversal;
- verifier policy warnings;
- CLI, JSON, Python component, and webapp integration surfaces.
What OpenETR Does Not Decide¶
OpenETR does not, by itself, decide:
- legal title;
- protected-holder status;
- warehouse licensing;
- KYC status;
- registry recognition;
- statutory effect;
- priority among competing claims;
- whether a host system executed a signed action;
- whether every effective action path was mediated;
- whether a signer had current institutional authority; or
- a globally authoritative ordering for concurrent events.
Those are recognition questions. OpenETR preserves durable signed evidence and derives Consequential State according to an identified ruleset. Recognition outside the protocol determines the effect given to that state.
A host application can make a stronger, bounded claim when it places OpenETR verification before a protected signing or execution operation and prevents equivalent ungoverned paths within its own scope. That is an integration property, not a universal property of the open event network.