5 Open Protocol
Holders can verify an EventChain history without access to the application that created it. They retain the file and use the verifier to check its chain and signatures, even after changing suppliers or closing an old system. Identity, payload, and time checks also need their supporting evidence (Section 4.9.1).
The file uses JSON Lines (JSON Lines 2023), SHA-256 and ECDSA-P256 (National Institute of Standards and Technology 2015, 2023), JCS (Rundgren et al. 2020) and WebAuthn (Hodges et al. 2021), so a verifier built from this paper confirms any AOF, past or present, whichever Hub produced it.
The public EventChain implementation repository contains the Haskell producer, a separate verifier package, and shared cryptography code under the BSD-3-Clause licence (EventChain 2026). The reference Hub lives in its own repository (EventChain Protocol 2026).
The holder’s checks are independent, each needing the evidence named in Table 4.3. Verification results inform an application decision; they do not authorise it.
5.1 Protocol Stewardship
Every check in this paper runs on one copy of the history. Each entry carries its producer’s signature, so the Hub cannot rewrite history. One power remains with the Hub: it can show one holder one history and another holder another, and each copy passes every check on its own.
The file alone already gives fork consistency: holders who compare copies with one another find the fork. That comparison is a distributed system, and EventChain exists so that no holder has to coordinate with another. A host that keeps the Hub’s heartbeats strengthens the guarantee to the point where one holder, on its own, detects a fork or an old copy within one publication interval.
At each interval the Hub signs a heartbeat, and the hosts the foundation lists for the topic pull it and publish it (Section 4.4.1). Figure 4.2 shows how a holder compares its copy against the host’s latest heartbeat, including a copy that ends early or diverges at the covered position. Two conflicting Hub-signed heartbeats for the same topic and position attribute a fork to the Hub; a mismatching copy alone does not. Publication is interval-based, so the current heartbeat covers the prefix up to its position, and entries after it await the next heartbeat.
A heartbeat host is the trusted party in the design, and the design asks little of that trust. It cannot forge a heartbeat, because the Hub signed it. It cannot read a payload, because the file carries only hashes. It can lie only by showing an old list, which a holder notices when no heartbeat arrives within the agreed interval, or by showing two holders two lists, which any two holders expose by setting their heartbeats side by side. A topic with two hosts lets one holder make that comparison alone. Haber and Stornetta’s company printed its weekly hash as a classified advertisement in the New York Times for the same two properties: nobody can withdraw a printed line, and every reader sees the same page.
Who may host heartbeats is the one thing in the design that has to be neutral, so we propose that an independent foundation with no owners keep a signed list of the hosts it trusts for each topic. The foundation also keeps what every party already shares: the specification, the open-source verifier, the conformance suite, the registry conventions, and a signed list of recognised Hub service providers (the parties that run Hubs) for topics that span rivals. A founding authority convenes the foundation and controls neither its council nor its oversight; other authorities join that oversight as equals, and no supplier or founder decides alone.
A signature names a key. An entry is evidence only if someone stands behind that key and nobody can change later who that was. A registry settles the first: a topic, kept by any organisation or authority, in which the key owner and the registry keeper both sign each binding of a key to a person, device or role, so neither binds a key alone. The protocol settles the second: a registry cannot touch an entry in any other topic, and a topic changes which registries it accepts only when its other parties countersign, so nobody changes who signed a past entry by changing which registry answers. Every chain of registries ends at a root key that the parties accept outside the protocol, as a browser accepts its root store (Section 4.3). The foundation keeps the conventions those registries follow; binding a key stays the keeper’s act, and accepting a root stays the parties’. Who may keep a registry that others accept, and how a keeper recovers a lost root, are the first questions the foundation settles (registry conventions).
5.2 Bootstrapping
One organisation starts on its own. It enrols the keys its people and devices already hold, runs a Hub for one process it already operates, and signs that process’s events into a topic. Its Hub publishes heartbeats from the first entry (Section 4.4.1). Each counterparty takes a copy of the file when it needs one, verifies it against the latest heartbeat, and so nobody waits for a consortium. The deployment tables list what a production deployment still has to put in place.