How it works
A neutral, protocol-first overview of how the runtime works, bridging up to the reference layer.
Audience: both · Read route: understand
The base protocol lets organisations share, address, and verifiably record encrypted data directly with one another, with no central server and no shared database. This is a conceptual overview, not the normative reference: the rules live in the base protocol specification, and the runtime detail lives in the reference section. Read this to understand the shape of the protocol before you put it to work in Getting started.
Architecture
The base protocol has no central server and no master copy of state. Each participating organisation runs its own runtime, and the shared, ordered log of recorded actions is the single source of truth. The runtime is expressed as three roles:
- a writer encodes, signs, and submits an action,
- a reader admits recorded actions from the public audit layer and replays them, and
- a recorder persists the reconstructed state and checks that a replay reproduces it.
State is locally owned, and the logic that changes it is written as pure method bodies, so any party can reconstruct the same state from the same log without trusting anyone else's copy. There is no shared database to be the authority; the log is.
Data flow
A change travels through the protocol as a recorded action. When a method runs, it produces a recorded action with a fixed shape: an identifier, the method name, its arguments, the actor that signed it, the time carried in the action itself, and an anchor reference to its position on the public audit layer.
The writer encodes and signs that action and anchors it to the public audit layer, a shared, append-only, tamper-evident record that no single party controls or can rewrite. A reader then admits the anchored action and replays it in log order, and state is reconstructed deterministically: two runtimes applying the same actions in the same order arrive at identical state. Because method bodies read the time from the action itself and never from a local clock, make no network call, and draw no randomness, replay is reproducible by construction. When a replay disagrees with stored state, that drift signals tampering or corruption, and it is grounds to stop.
This diagram is free to copy into your own presentation. On the built site this block carries a copy control and is marked translate="no", so machine translation leaves the role labels and terms intact.
The envelope
A record is a versioned envelope of typed tiers. Encryption is on by default and applied per field: each field is encrypted independently and carries its own receivers, so different parties can be granted access to different fields of the same record. Selective disclosure is simply a matter of granting a counterparty only the field keys it is entitled to.
Each field carries a placement descriptor stating where its encrypted content lives, inside the anchored record, in overlay storage, or in external storage. In every case the record carries a cryptographic commitment to the field, so a party can confirm a field exists and is unchanged even without holding the key to read it.
The example below shows how a single record serves many parties at once. The roles are generic; read them as the shape of an access model, not a specific deployment.
| Party | Which fields it can read | How access is granted |
|---|---|---|
supplier | origin | granted the origin field key |
manufacturer | origin, production | granted those field keys |
retailer | product identity, warranty | granted those field keys |
customer | warranty | granted the warranty field key |
auditor | none read; confirms every field's existence and integrity | verifies each field's cryptographic commitment, without a read key |
public-body | only the fields named in a specific request | holds a scoped, time-bounded, revocable mandate |
Each party sees exactly the fields it is entitled to and nothing more, and the auditor can verify that no field has been altered without being able to read any of them.
Primitives
Every mechanism in the protocol rests on open, published primitives, so that an implementation can be built and verified by anyone. The open primitives are HKDF, PBKDF2, AES-256-GCM, ECDH, and ES256.
Keys are derived, not stored. Every key an implementation needs is derived on demand through a five-level hierarchy, following an open, published key-derivation standard, over two curves: secp256k1, which binds a runtime to the public audit layer, and P-256, which signs in the formats that EU digital identity wallets and web identity systems already use. Both curves derive from the same master input, so one secret covers audit-layer binding and EU wallet and web-identity signing.
Records are encoded with a deterministic canonical encoding following RFC 8949, so that two conforming implementations produce byte-identical output and therefore identical commitments and proofs. Keys retire per epoch: on rotation a new epoch begins, the transition is marked publicly and anchored, and data encrypted under a prior epoch stays readable to any party that held a key in that epoch, with no re-encrypt-everything event.
None of these is proprietary. Each is a published standard an implementer follows directly, which is what makes the protocol rebuildable rather than dependent on a single implementation.
The trust chain
Authority binds through a verifiable chain of grants: a legal entity binds to a runtime account, the account binds to a mandated actor, and the actor binds to each signed recorded action. Every link is verifiable, and none of them requires a network call at the moment an action is recorded.
A mandate grants an actor scoped, time-bounded, revocable authority to sign actions on an account's behalf, and the actor's public key is pinned at the moment the mandate is granted. Verification is therefore local: an action's signature verifies against the key pinned at grant time, with no lookup on the critical path. A delegation and its revocation are themselves recorded actions on the public audit layer, so the authority history is auditable. Because every key in the chain is a distinct per-context derivation, a compromise at one link does not cascade to the others.
The binding aligns with the open W3C DID and Verifiable Credentials standards. Citizen-facing mandates may be issued as portable, selectively disclosable credentials using SD-JWT and presented over OpenID4VP and OpenID4VCI, with binding aligned to eIDAS; the credential is optional, and organisational flows work without it. Where a party needs to publish verifiable claims about itself for others to look up and check, it does so through the register described in the specification at /protocols/data-sharing/v0.1, Section 4.
Where to go next
To go deeper, the reference section sets out each runtime concept in detail: the runtime and replay, the envelope, identity and delegation, and anchoring and the audit log. To put the concepts to work, continue to Getting started.