# EventChain: A Distributed History Without a Distributed System

> Answers map: common questions linked to the paper's arguments and their limits.

Manuscript revision: 2026-10-13. EventChain records signed entries in a history that each holder verifies. Applications decide what to do with the evidence. Reviewers who read the abstract and one chapter most often miss the passages under Start here, so they come first and in reading order.

## Start here

- [What "consensus" and "distributed ledger" mean in this paper](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-consensus-by-comparison): The chapter's opening paragraph and its first footnote. A holder with an earlier prefix holds the same history; the paper uses the term deliberately for the state that results.
- [The guarantees table](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-what-you-get): Six of eight ledger guarantees, each with what remains assumed, and the two the paper leaves to contract and other layers.
- [Append Protocol and Hub Heartbeat](https://eventchain-protocol.github.io/how-it-works.html#sec-append-protocol): What the Hub checks, what it never judges, the signed refusal, and what one heartbeat comparison covers.
- [Protocol Stewardship](https://eventchain-protocol.github.io/open-protocol.html#sec-stewardship): What a heartbeat host can and cannot do, and what the proposed foundation keeps.
- [What a Signature Proves](https://eventchain-protocol.github.io/how-it-works.html#sec-identity-bound-signatures) and the [registry specification](https://eventchain-protocol.github.io/appendix-specification.html#sec-spec-registry): Key binding limits, the four binding events, the three open conventions and the five governance questions.
- [What It Costs](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-what-it-costs): Every figure with its date and who measured it, including the contention measurement.
- [Comparison tables](https://eventchain-protocol.github.io/appendix-standards-positioning.html): The dishonest-Hub, trust-boundary, failure-mode and deployment-dependency tables that carry most of the paper's stated limits.
- [Worked examples](https://eventchain-protocol.github.io/use-cases.html): Five processes that show where each guarantee and each limit applies.

- [Executive summary](https://eventchain-protocol.github.io/executive-summary.html): Restates the body for a business reader and keeps the body's qualifiers; the body is the authority where the two seem to differ.

## Shared history and forks

- [How does a holder detect a divergent history without contacting other holders?](https://eventchain-protocol.github.io/how-it-works.html#sec-hub-heartbeat): Each holder compares its copy with a Hub-signed heartbeat that it reads from a trusted heartbeat host. The Hub issues the heartbeat at the agreed interval and serves it at its endpoint; each host the foundation lists for the topic pulls it, checks the signature and that it names the file's head, and publishes it. Different hashes at the same position cannot both match one heartbeat. The check needs a recent heartbeat under the topic's accepted Hub key from a host that preserves every heartbeat and shows everyone the same list. A heartbeat covers only the prefix through the entry it names; later entries await the next one. A matching heartbeat shows that the holder has the same history as everyone else; the producer signatures show whether that history is genuine. [Protocol Stewardship](https://eventchain-protocol.github.io/open-protocol.html#sec-stewardship) explains the host dependency. [Heartbeat outcomes](https://eventchain-protocol.github.io/appendix-specification.html#sec-spec-outcomes) specifies how applications respond to missing, stale, or conflicting evidence.
- [Does every holder hold the same history at every moment?](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-consensus-by-comparison): The paper makes no such claim. A holder that has yet to receive the latest entries holds an earlier prefix of the same history; the chapter's first footnote names this timeline consistency, after PNUTS. The claim is that every party holds one history and that any party checking against the same heartbeat finds the same history through the entry that heartbeat covers. The paper gives no guarantee about which entries another holder has received at a given moment.
- [Does "consensus" here mean agreement before the append, as in a voting ledger?](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-consensus-by-comparison): The paper says once that it uses the word for the resulting state, one history that every party holds and agrees on through the latest published entry. A ledger reaches that state by a round of votes before each append; EventChain holders reach it after the append, each against one published heartbeat. [What You Get](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-what-you-get) lists six of the eight guarantees people seek from a ledger, each with the assumption it rests on, and names the two it leaves to contract and to other layers: nobody can block a writer, and settlement among strangers. The executive summary's "the certainty a blockchain promises, that every one of them holds the same history" is the first row of that table.
- [Is a heartbeat host a trusted third party?](https://eventchain-protocol.github.io/open-protocol.html#sec-stewardship): Yes, and the paper says so: the host is the trusted party in the design, and the design asks little of that trust. A host pulls each Hub-signed heartbeat and publishes it. It cannot forge one, because the Hub signed it, and it cannot read a payload, because the file carries only hashes. Two powers remain. It can serve an old list, which a holder notices when no heartbeat arrives within the agreed interval. It can show two holders two lists, which any two holders expose by setting their heartbeats side by side, and a topic with two hosts lets one holder do that alone. The guarantees table names this as the assumption behind one shared history: the hosts the foundation lists for the topic preserve every heartbeat and serve everyone the same list. The paper proposes an independent foundation to keep the signed list of trusted hosts for each topic.
- [What does a holder have when no heartbeat host is reachable?](https://eventchain-protocol.github.io/appendix-standards-positioning.html#sec-adversarial-hub): The file alone gives fork consistency: holders who compare copies with one another find a fork. The heartbeat hosts exist so that no holder has to make that comparison. With no host reachable, the verifier reports heartbeat evidence as missing and the application pauses the actions that need verified shared evidence for that topic ([outcomes](https://eventchain-protocol.github.io/appendix-specification.html#sec-spec-outcomes)).
- [Does the Bitcoin anchor detect a fork or a stale copy?](https://eventchain-protocol.github.io/how-it-works.html#sec-ots-rollups): The optional daily OpenTimestamps rollup shows that the anchored bytes existed before the anchor time, on evidence that rests on the Bitcoin network and validation of the proof, independent of the Hub. A Hub can anchor both branches of a fork, so fork and staleness detection belongs to the heartbeat hosts. The anchor does not date the event itself.

## Hub

- [Can the Hub refuse an entry, and does the history show that every event reached the Hub?](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-what-you-get): The guarantees table lists "nobody can block a writer" as one of the two ledger guarantees EventChain does not supply. A Hub can refuse an append, and the file cannot establish receipt of a submission the Hub never acknowledged ([dishonest Hub table](https://eventchain-protocol.github.io/appendix-standards-positioning.html#sec-adversarial-hub)). The protocol gives the submitter one thing: a submission that fails the per-line checks receives a signed refusal naming the submission hash, the reason and the Hub's asserted time, which the submitter retains, so a refusal of a valid line is evidence against the Hub. The Hub's duty to stay available rests on the service agreement with the Hub service provider.
- [What does the Hub check before it appends, and who judges content?](https://eventchain-protocol.github.io/how-it-works.html#sec-append-protocol): The Hub applies exactly the checks a verifier applies to one line: well formed under the entry specification, `prev_hash` equal to the current head, and the key on the line signed it. It appends every submission that passes, whatever the entry says and whoever holds the key, and judges nothing else. A false statement or an unbound key enters the history, where the verifier reports it and the other parties contest it in the chain.
- [How does the paper handle corrections and competing attestations?](https://eventchain-protocol.github.io/how-it-works.html#sec-cbc): A correction, an objection or a resolution is a new signed entry that names the entry it addresses through `subject_hash` ([correction references](https://eventchain-protocol.github.io/appendix-specification.html#sec-corrections)). The original stays in the chain, and no later statement overrides it automatically. When two authorised parties record conflicting accounts, the history preserves both, and application policy decides who may make each kind of statement and which one it acts on. A disputed offer stays pending while the objecting party withholds acceptance and records a signed objection.
- [Does the Hub append rate include verification, and what happens when producers contend for the same head?](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-what-it-costs): The Hub checks each line for well-formedness, predecessor hash and signature before appending it. A benchmark of the reference Hub on 14 October 2026, on one thread per topic, committed more than 11,000 entries a second with all three checks on every line and 29,000 with the head comparison alone, from one run; the checks cost the Hub thread 65 microseconds a line. The contention and batching benchmarks use a compare-and-append Hub model that applies the predecessor-hash check, with format and signature checks run on every output file afterwards, so they measure the append rule and not the cost of those checks. Under the [append protocol](https://eventchain-protocol.github.io/how-it-works.html#sec-append-protocol), a producer whose expected head has moved receives a rejection, verifies the extension, signs again and resubmits. Batching spreads the trip to the Hub across many individually signed entries. The author's measurements of 13 October 2026 compare batch sizes with one, ten and twelve producers ([contention table](https://eventchain-protocol.github.io/consensus-by-comparison.html#tbl-producer-batching)). Larger batches raise throughput across a network delay towards one producer's signing rate. Racing producers spend more CPU on retries, and larger batches increase latency; some producers committed nothing during the four-second windows. Independent topics let producers progress separately. Every committed event adds one line to the file.

## Keys and registries

- [Who controls the signer and key registries?](https://eventchain-protocol.github.io/how-it-works.html#sec-identity-bound-signatures): A registry is a topic like any other, kept by an organisation for its own signers or by an authority or community that binds each organisation's root key to its legal identity. Each binding carries two signatures, the subject key's offer and the keeper's acceptance, so neither party binds a key alone. Each topic declares the registries it accepts and changes that declaration only with its other parties' countersignature, so nobody re-attributes a past signature by swapping registries. Every chain of registries ends at a root key that the parties accept outside the protocol, as a browser accepts its root store. The proposed foundation keeps the conventions; binding a key stays the keeper's act, and accepting a root stays the parties'. A binding shows whom its keeper says a key belongs to.
- [How do rotation, retirement and compromise work, and what is still open?](https://eventchain-protocol.github.io/appendix-specification.html#sec-spec-registry): Four binding events exist as payload shapes: register, rotate, retire and compromise. Every key, including a registry root, rotates by the ordinary rotate event, the new key offering and the current key accepting; the paper specifies no pre-rotation. A compromise claim names the time from which the key is suspect, and the verifier reports each entry the key signed inside that window and leaves the decision to the application. A payload may state a time, but the signer asserted it, so the verifier places an entry in time by the heartbeats and anchors around it and no finer than they allow. The verifier reports signature validity, binding evidence, compromise status and authorisation separately. Three conventions remain open: declaration encoding, whether an entry carries a reference to its binding, and the attribution outcomes the verifier reports. The binding payload, which carries the subject type, an identity reference, a role and the hash of the enrolment evidence, travels with its salt so that holders resolve keys offline; the enrolment evidence itself, including any personal details, stays with the keeper under its access policy. Five governance questions, among them root recovery, how far back a compromise claim may reach, and how long a keeper retains enrolment evidence and how it deletes it, wait for the foundation.

## Stewardship and classification

- [Does the paper define the foundation's legal form, council, intellectual property or funding?](https://eventchain-protocol.github.io/open-protocol.html#sec-stewardship): The paper states what the foundation keeps: the signed list of trusted heartbeat hosts for each topic, the specification, the open-source verifier, the conformance suite, the identity-registry conventions and a signed list of recognised Hub service providers for topics that span rivals. It states one structural principle, that a founding authority convenes the foundation and controls neither its council nor its oversight, with other authorities joining as equals. It names the first questions the foundation settles ([registry conventions](https://eventchain-protocol.github.io/appendix-specification.html#sec-spec-registry)). Recognition applies to topics that span rivals; under [Bootstrapping](https://eventchain-protocol.github.io/open-protocol.html#sec-adoption-sequence) one organisation runs a Hub for a process it already operates without any recognition. Legal form, jurisdiction, ownership of the specification text and the name, appointments and operating funding lie outside the paper.
- [Is EventChain a distributed ledger?](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-consensus-by-comparison): The paper states one bounded sense: a history with two or more holders is a distributed ledger in which the parties hold the copies and one Hub sets the order. Many producers write, one Hub orders each topic, holders read, and no holder's check depends on another holder. A history with one holder is a signed log. The chapter's first footnote gives the distributed-systems terms: a single-writer replicated log, in which the Hub appends and producers sign, with timeline consistency, classed PC/EL under PACELC. The paper applies no legal or standards definition of distributed ledger technology.

## Implementation status

- [What exists in code, and what does the paper measure?](https://eventchain-protocol.github.io/open-protocol.html#sec-open-protocol): The public implementation repository holds the Haskell producer, a separate verifier package and shared cryptography code under the BSD-3-Clause licence; the reference Hub lives in its own repository. Every rule in the paper binds implementations. [What It Costs](https://eventchain-protocol.github.io/consensus-by-comparison.html#sec-what-it-costs) reports verification at 42 seconds per million entries on one laptop core in the October 2026 benchmark, the reference Hub committing more than 11,000 entries a second on one thread with all three per-line checks in the 14 October 2026 benchmark, and producer-batching measurements under contention on 13 October 2026. The paper does not say which of its rules the current code enforces, and it reports no multi-party deployment, no independent audit and no conformance test of a second implementation; these are gaps the paper leaves open. The [deployment dependencies table](https://eventchain-protocol.github.io/appendix-standards-positioning.html#sec-appendix-dependencies) lists what a production deployment still has to put in place.