flowchart TB
subgraph L["Ledger: new validator"]
direction TB
A["Carrier's signed<br/>acceptance"] --> V["Round of votes"]
N["New company's<br/>validator"] --> V
V --> R["Ledger commits<br/>the acceptance"]
end
subgraph E["EventChain: new holder"]
direction TB
B["Carrier's signed<br/>acceptance"] --> H["Hub appends<br/>the entry"]
H --> C["New company receives<br/>and verifies its copy"]
end
L ~~~ E
style L fill:transparent,stroke:currentColor
style E fill:transparent,stroke:currentColor
3 Consensus by Comparison
The members of a ledger agree on the history before each append, by a round of votes among everyone present. The holders of an EventChain history agree after the append, each by comparing its copy with one line the Hub has signed and published (a heartbeat), and nobody has to be present. Both routes end in the same state: every party holds one history, and each knows that any other party checking against the same heartbeat finds the same history through the entry it covers. Because each holder applies the same rules to an identical copy, each reaches the same verdict on whether an entry follows them; only the payload check depends on what each holder may read (Section 4.7). That state is what consensus guarantees, and this paper uses the word for the guarantee. The two routes differ in when the agreement happens and who has to be present. The costs and limits of each route follow from that difference.
In the same way, 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.1 This chapter says “a ledger” for the kind that votes, and a history with one holder is a signed log.
3.1 What You Get
EventChain gives six of the eight guarantees people seek from a ledger without a round of votes, each under an assumption that Table 3.1 names, and leaves the other two to contract and to other layers.
| Guarantee | A ledger gets it from | EventChain gets it from | What remains assumed |
|---|---|---|---|
| One history that every party holds and agrees on through the latest committed or published entry | A round of votes before each append | Each holder compares its copy with the latest Hub-signed heartbeat (Figure 4.2) | The hosts the foundation lists for the topic preserve every heartbeat and serve everyone the same list (Section 5.1) |
| Nobody can rewrite an entry unnoticed | Every replica validating every block again | Each producer signing its entry over the hash of the entry before it (Section 4.1) | Holders run the verifier |
| Events keep their order | The same round | One Hub thread appending in sequence, each signature fixing its entry’s position (Section 4.5) | The Hub decides which of two competing submissions goes first |
| Who made each statement | Organisation certificates or wallet addresses | A key per signer: a person’s passkey, a device’s hardware key or a service’s key (Table 4.2) | The enrolment evidence that binds the key to a party, and the registry root key that the parties accept outside the protocol (Section 4.3) |
| Verification without the operator | Running a node | Running the open verifier on the file, offline (Section 4.9) | A correct verifier, whose source anyone can read |
| Time | Block timestamps | The Hub’s asserted time, and an optional anchor in Bitcoin (Section 4.8) | The Hub’s clock; for the anchor, the Bitcoin network. Neither dates the event itself |
| Nobody can block a writer | Open membership and many validators | Not supplied: a Hub can refuse an append; a producer retains signed evidence of its attempted submission (adversarial Hub analysis) | Hub availability and acceptance remain contractual duties |
| Settlement among strangers | A round of votes on balances | Not supplied: ownership and balances belong to an application or ledger (Section 3.5) | Each party answers for what it signs |
The history is a text file that anyone can check with SHA-256 and ECDSA-P256, so the evidence outlives the platform that produced it.2 Every holder verifies every entry of its history, including entries whose payloads access policy keeps from it (Section 4.7). A gap in the chain or a copy shorter than the latest heartbeat shows that entries are missing, so a holder notices when a history leaves out inconvenient entries.3
3.2 What It Costs
Because nobody has to be present at the append, an append is one write, and the work of recording grows with the number of events and with nothing else. Picture an electricity supplier with 10,000 meters, each signing a reading every fifteen minutes (worked example): 960,000 entries a day, about eleven a second. Whether the supplier can keep that history depends on whether the work grows with the number of events or with the number of parties who hold the history. On a ledger it grows with both.
In 2018, Hyperledger Fabric’s authors at IBM Research reported more than 3,500 transactions a second for a payment workload with five peers in one data centre, falling to between 1,400 and 2,000 with 100 peers across five data centres, every peer holding the whole ledger (Androulaki et al. 2018). The whole Ethereum network processed 3.6 million transactions on 28 April 2026, its busiest day up to October 2026 (Etherscan 2026); this one supplier’s readings would equal a quarter of that day. A consortium ledger recovers its costs from its users: in 2021, TradeLens listed its service from $8 per container (TradeLens 2021).
Suppose another logistics company joins a shipment process. Figure 3.1 follows the carrier’s signed acceptance: the company joins the consortium ledger as a validating member, or receives the EventChain history as a holder.
A ledger can also serve read-only users without adding validators. Such a user trusts the validators for what an EventChain holder checks itself from its copy. Adding an EventChain holder adds one copy of the file and that holder’s own checks; existing holders do not repeat verification for it. The application’s business rules still apply: if dispatch requires the new company’s acceptance, the dispatch system waits for it (Section 4.7).
The Hub checks each submitted line as a verifier does, for well-formedness, predecessor hash and signature, before it appends (Section 4.4). 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 (EventChain 2026a); the checks cost the Hub thread 65 microseconds a line (Section 4.5). No fee attaches to an event. Each holder receives one line of about 335 bytes per event and verifies its copy on its own processor at its own pace. A holder that verified yesterday’s copy checks only today’s new entries. These measurements describe different workloads and environments: observed Ethereum traffic is not network capacity, and the figures are not a comparative throughput benchmark.
Batching spreads the trip to the Hub across many events. A benchmark of the reference producer on 13 October 2026 measured it against a compare-and-append Hub model (EventChain 2026c). Each producer signed a sequence of entries, each over the one before, and submitted them together. The Hub model accepted a batch when its first entry followed the current head, and the reference Hub checks every line before writing. That first check binds the batch to the whole history. The benchmark then checked format and signatures on every output file, and all 160 passed. Table 3.2 shows the committed entries per second with a 20-millisecond in-flight delay; the measured delay was about 21 milliseconds.
| Entries per batch | One producer | Ten producers | Twelve producers |
|---|---|---|---|
| 1 | 46 | 48 | 48–49 |
| 100 | 3,873–3,898 | 3,999–4,024 | 4,025–4,048 |
| 300 | 9,071–9,074 | 8,772–8,924 | 8,471–8,621 |
| 1,000 | 17,241–17,247 | 12,748–13,743 | 11,497–12,244 |
| 3,000 | 23,239–23,243 | 14,245–14,246 | 12,743–12,745 |
Each event keeps its own signature and its own line in the file. Larger batches spread the delay across more entries, so throughput approaches one producer’s signing rate. Producers that race for the same head spend more CPU: under saturating load, ten producers make about ten signatures per committed entry, because each loser signs its batch again against the new head. Larger batches also make producers wait longer. With ten producers and batches of 3,000 at this delay, median latency from the first signature to acceptance was 1.02 seconds, and the 99th percentile was 3.29 seconds; an event also waits for its batch to fill. Some producers committed nothing during the four-second windows, so a process that needs independent producers to progress gives them topics of their own (Section 4.5).
Table 3.3 applies these figures to the supplier.
| Quantity | Figure |
|---|---|
| Hub-thread utilisation at 65 microseconds a line | About one part in 1,400 |
| File growth per holder | About 320 MB a day |
| Verification time per holder, on one core | About 40 seconds per day of entries; October 2026 benchmark of 42 seconds per million entries (EventChain 2026b) |
The same arithmetic covers every photograph behind an insurance claim (worked example), because the file carries a fingerprint of each photograph and never the photograph itself (Section 4.2). The cost that grows with volume is each holder’s storage, about 117 GB a year at this supplier’s rate.
Some work costs the same with a ledger or with EventChain: a deployment still pays to integrate existing systems and to enrol signers. Ledger consortia carried one more item: those that closed in 2022 and 2023 named reaching critical mass as what consumed the money (Section 2.3.1). EventChain has no such item, because one organisation can start and the others take the evidence when they need it.
3.3 What Remains Trusted
Beyond the file and a verifier, a holder depends only on what the last column of Table 3.1 names, chiefly the enrolment evidence behind each key, the heartbeat hosts the foundation lists for its topic and the Hub’s availability to accept new entries. The Hub cannot rewrite a signed entry. It can withhold entries from a holder or show different holders different histories; Figure 4.2 shows how a holder checks against the latest heartbeat. Two conflicting heartbeats under the Hub’s key attribute the fork to the Hub. The field calls these properties fork consistency and accountability (Section 4.4; adversarial Hub analysis). Deciding what to do with the evidence stays with the application. EventChain does not prevent a false entry at the moment of creation; it makes later denial and editing unattractive, because each entry names a signing key and binds its statement to the preceding history.4 Table 4 gives the boundary capability by capability.
3.4 Where It Breaks
A valid signature proves that a key signed these bytes. It cannot reveal an honest mistake, coercion, collusion or a signer who signs without reading. Process controls and audit remain necessary, and when something goes wrong they now start from a signed history and the identity evidence behind it (failure-mode tables).
3.5 When It Fits
EventChain fits where each party to a process answers for what it signs, and where at least one of them needs evidence that survives beyond any single platform. Because each party answers for what it signs, detection after the fact suffices. Because the evidence travels as a file, nobody has to join a network before the first entry is useful. Where strangers settle payments with one another, a ledger’s round of votes remains the right tool. Where one organisation controls the whole process and nobody outside needs to verify, an ordinary audit trail does. Table 9 sets each approach beside the others.
In the vocabulary of distributed systems, a topic is a single-writer replicated log (the Hub is the single appender; producers sign the entries it appends) with timeline consistency, the model of PNUTS, in which “all replicas of a given record apply all updates to the record in the same order” and a read returns a possibly stale version that “is always a valid one from the record’s history” (Cooper et al. 2008). Under PACELC (Abadi 2012), a topic chooses consistency over availability when partitioned, refusing to append against an unknown head or to act on evidence it cannot confirm, and latency over consistency otherwise, appending without waiting for holders; the heartbeat bounds undetected staleness to one publication interval while a host the foundation lists for the topic stays reachable and preserves every heartbeat (Section 5.1). Abadi classifies PNUTS the same way, PC/EL.↩︎
Hash-linked time-stamping showed that ordering and tamper-evidence come from chained commitments with no round of votes (Haber and Stornetta 1991). The standards comparison places them alongside earlier systems.↩︎
Parakeet frames a related pattern: public commitments, private querying and verifiable proof (Malvai et al. 2023).↩︎
The US Food and Drug Administration’s data-integrity guidance rejects shared logins for the same reason: “a unique individual cannot be identified through the login” (U.S. Food and Drug Administration 2018).↩︎