Appendix: Comparison Tables

This appendix holds the comparison tables that 3  Consensus by Comparison relies on and shows how EventChain relates to existing transparency and provenance systems.

Standards Lineage

EventChain sits in a lineage of cryptographic accountability systems. Haber and Stornetta established hash-linked time-stamping as a way to make document history tamper-evident without a conventional record-keeper (Haber and Stornetta 1991). Certificate Transparency and Trillian turned append-only transparency logs into operational infrastructure for public certificates (Laurie et al. 2013; Google 2026). SCITT generalises transparency receipts for supply-chain statements using COSE/CBOR and external transparency services (Birkholz et al. 2026). KERI focuses on self-certifying identifiers and key-event logs for decentralised identity (Smith 2019). Parakeet demonstrates privacy-preserving transparency through public commitments, private querying, and verifiable proof (Malvai et al. 2023). TrustChain shows that a blockchain can preserve data while leaving truth at origin unresolved (Malik et al. 2019).

EventChain keeps the chained hash and the published heartbeat from these systems. What it adds is a key for every signer and a file the parties keep themselves.

Table 1: Provenance and transparency architectures compared

Property	EventChain	SCITT
Primary object	Signed event history	Supply-chain statement receipt
Attribution	Signing key plus enrolment evidence	Entity via X.509 or OIDC
Proof location	Travels with authorised holders	Receipt can travel with signed statement
Verification	Offline chain/signatures; separate binding and heartbeat evidence	Receipt, accepted service keys and proofs
Tooling	JSON Lines, SHA-256, ECDSA-P256, JCS and passkeys	COSE/CBOR, verifiable structures and registry
Storage/distribution	Hub distribution; application payload access	Left to implementers
Access control	Application policy over encrypted payloads	Out of scope
Two-party agreement	Offer and signed acceptance (Cryptographically Bound Contracts)	Application-defined

Table 2: Earlier transparency and identity systems, using the same comparison properties

Property	CT / Trillian	Haber & Stornetta	KERI
Primary object	Certificate log entry	Time-stamped document hash	Key-event history
Attribution	Certificate authority / subject	Requester identifier in the time-stamp certificate	Identifier controller
Proof location	External log	External time-stamp chain	Key-event log that travels with the identifier
Verification	Inclusion / consistency proof	Chain through time-stamp service	Key-event log verification
Tooling	Merkle log infrastructure	Hash chain and time-stamp service	KEL and witness infrastructure
Storage/distribution	Outside certificate-log scope	Outside protocol scope	Outside protocol scope
Access control	Public log model	Out of scope	Out of scope
Two-party agreement	Outside scope	Outside scope	Outside scope

SCITT and EventChain operate at different layers. SCITT answers whether a transparency service registered a signed statement; its receipt can accompany the statement for verification (Birkholz et al. 2026, sec. 7). EventChain preserves producer-signed entries and their sequence in a portable file.

Dishonest Hub

The Hub accepts producer-signed entries, orders them and serves authorised copies. Table 3 sets out what a dishonest Hub can attempt, how a holder detects it and what risk remains. Figure 4.2 shows the comparison each holder makes.

Table 3: Adversarial Hub failure modes, detection paths, and residual risks

Failure Mode	Detection Path	Residual Risk
Hub alters an old entry	Chain and producer-signature checks expose alterations; a retained head or a later heartbeat also binds exact final-entry bytes	A party must run verification; hash checks alone authenticate nothing without the producer signatures
Hub withholds an entry from a role-authorised party	A supplied copy falls short of or conflicts with the published heartbeat	The file cannot establish receipt of an unacknowledged submission; missing or stale heartbeats alone do not prove withholding
Hub binds a valid signature to wrong payload	Holder recomputes the salted payload hash from the plaintext and salt	Parties lacking the exact plaintext and salt cannot test that hash
Hub presents different histories to different holders (a fork)	Each holder compares its copy with a heartbeat host the foundation lists for its topic; conflicting Hub-signed heartbeats attribute the fork to the Hub’s key	Detection requires a host that keeps every heartbeat and shows everyone the same list; fresh entries await the next heartbeat

If no host listed for the topic (Hub Heartbeat) is reachable, the file alone provides fork consistency: incompatible branches become detectable when holders compare copies (Li et al. 2004). OpenTimestamps receipts cannot stand in for the list (OpenTimestamps).

The Hub’s one remaining duty, staying available to accept new entries and serve copies, rests on the Hub service provider’s service agreement.

Trust Boundary

Holders verify integrity and order from the file. Naming signers and checking freshness need external evidence, and applications govern payload access and decisions (Table 4).

Table 4: Trust boundary in the EventChain architecture

Capability group	Evidence or responsibility	Remaining dependency
Holder checks: integrity and order	Verify links and producer signatures offline	Correct verifier and retained AOF
Holder checks: payload commitment	Hash raw salt followed by exact plaintext bytes	Authorised access to plaintext and salt
External evidence: authorship	Verify key signature; assess identity binding (Table 4.2)	Retained enrolment and dispute evidence
External evidence: freshness/shared history	Compare with authenticated heartbeat (Figure 4.2)	Accepted Hub key; preserved same list; publication interval
Operations: appending/distribution	Hub accepts entries and serves copies	Availability; application-controlled payload access
Operations: search/indexing	Hub supplies discovery and query results	Check returned evidence against retained history
Operations: portal views	Application presents selected evidence	Presentation and action policy remain application duties

Failure Modes

The following tables separate what the evidence establishes from what remains unknown and requires operating controls.

Table 5: History integrity and verification

Failure mode	What the evidence establishes	What remains unknown	Complementary control
Tampered entry (post-signing edit)	Chain or producer-signature checks fail (Table 3)	Checks do not necessarily locate the original alteration	Routine verification by holders
Verification never run	None	A valid file that no party bothers to check	Contractual verification obligations, automated verification triggers

Table 6: Signer conduct

Failure mode	What the evidence establishes	What remains unknown	Complementary control
False data from an authorised signer	Signature identifies the key; enrolment evidence supports attribution	The falsehood itself, and the intent behind it	Process controls, cross-checks, independent measurement, separation of duties
Honest signer error	None	Mistakes that produce valid-looking entries	Quality systems, peer review, calibration
Coerced signature	None	Duress behind a technically valid signature	Whistleblower channels, dual-control policies
Rubber-stamping	None	Perfunctory signatures without genuine review	Audit culture, random re-inspection

Table 7: Credentials and access

Failure mode	What the evidence establishes	What remains unknown	Complementary control
Compromised passkey	None; a later signed compromise claim stands beside the history as a visible dispute	A signature produced from a stolen or cloned credential	Hardware-bound passkeys with user verification, device attestation, anomaly detection
Lost or unrecoverable key	Earlier signatures stay valid; the organisation retires the key and issues a new one	None	Key-loss procedures, identity re-proofing
Restricted payload access	Chain and signature checks still verify the history	Content of payloads the holder cannot access	Application access policy and retention of authorised supporting evidence

Table 8: Physical measurement

Failure mode	What the evidence establishes	What remains unknown	Complementary control
Sensor removed from the asset it monitors	A CBC signed at installation by the technician and the sensor (Cryptographically Bound Contracts) records which sensor the technician fitted to which asset	A removed sensor keeps signing valid readings, because the key is in the sensor and shows nothing about where the sensor is	Physical tamper indicators and inspection
Sensor calibration drift	None	Gradual measurement error within technically valid signatures	Calibration schedules, reference comparisons

Choosing an Approach

Table 9 sets EventChain beside the other ways of keeping provenance. The approaches combine: an organisation might keep ERP audit trails internally and use EventChain for the evidence shared across organisations.

Table 9: Approaches to provenance: when each fits and where it falls short

Approach	Works well when	Falls short when	Adoption condition
Do nothing	Single-party control, low stakes, short lifecycles, negligible dispute risk	Multiple handoffs, regulatory scrutiny, or long-lived histories where reconstruction costs compound	Risk exposure remains below the cost of any provenance system
ERP audit trails	All relevant parties share one system, or a dominant buyer mandates platform access	Records must survive beyond the platform operator, or partners lack ERP access	Organisational control spans the full lifecycle
Document signing (e-signatures)	Point-in-time attestation between known parties, such as contract execution or inspection sign-off	Continuity matters, because signed documents do not chain into a verifiable sequence across several actors	The proof need is a single moment
Managed compliance portals	Compliance requires a portal with public access and standardised data models	The portal cannot produce independently verifiable evidence, or the history must outlive the platform vendor	A single vendor can credibly serve the history’s full lifetime
VC/DID credentials	Interoperable identity claims across organisations, where selective disclosure and the subject’s control of its credentials matter	The question is the order and integrity of events, which credentials do not carry	Identity portability is the primary requirement
Enterprise distributed ledger	High-value, multi-party transactions that need shared state no single operator controls	Consortium formation stalls, costs exclude smaller participants, or throughput requirements exceed consensus limits	All parties can fund node infrastructure and governance
SCITT transparency registry	Public accountability for signed statements, with receipts that can travel with those statements	Statement storage, discovery, and distribution need an implementation beyond the registry specification	A transparency service exists and holders accept its verification keys and policies
EventChain with an application layer	Identified parties in different organisations need a long-lived history each can verify, including participants who cannot fund ledger infrastructure	Strangers settle payments with one another, or one organisation controls the whole process and nobody outside needs to verify	At least one party needs proof that survives beyond any single platform

Deployment Dependencies

The following tables list what a production deployment puts in place beyond the file and the verifier (Bootstrapping).

Table 10: Evidence production and availability

Dependency	Owner	Why it matters	Risk if ignored
Hub (hosted or self-run)	Hub service provider	Appends entries, distributes the AOF, enforces payload access policy	No chain creation or distribution
Heartbeat publication	Hub service provider	Signs and publishes heartbeats at the topic’s agreed interval	Holders cannot tell whether their copy is current
Heartbeat hosting and accepted Hub keys	Heartbeat hosts the foundation lists for the topic	Pull each heartbeat from the Hub, check it, preserve it; serve the same list and accepted Hub keys to everyone	Holders cannot establish freshness or reliably detect a fork

Table 11: Identity and access

Dependency	Owner	Why it matters	Risk if ignored
Identity provider integration	IT / Security	Maps passkeys to verified personnel	Unsigned or unattributable events
Signer onboarding	HR / IT	Registers passkeys against identity	Adoption stalls at first signing step
Payload access policy	Governance / Legal	Controls authorised payload access	Over-sharing or under-sharing halts rollout

Table 12: Application decisions and use

Dependency	Owner	Why it matters	Risk if ignored
Business logic and event schema	Domain / Engineering	Defines which actions become evidence and what each entry records	Unverifiable payloads
Holder verifier access	Holder IT	Enables independent verification (Table 4.3)	Proof exists but nobody checks it
ERP/API webhook integration	Engineering	Connects evidence to existing workflows	Manual data entry, adoption friction
Contractual verification clause	Legal / Procurement	Defines consequences of failed verification	A failed verification carries no consequence

Birkholz, Henk, Antoine Delignat-Lavaud, Cédric Fournet, Yogesh Deshpande, and Steve Lasker. 2026. An Architecture for Trustworthy and Transparent Digital Supply Chains. RFC 9943. https://doi.org/10.17487/RFC9943.

Google. 2026. Trillian: General Transparency. GitHub repository. https://github.com/google/trillian.

Haber, Stuart, and W. Scott Stornetta. 1991. “How to Time-Stamp a Digital Document.” Journal of Cryptology 3 (2): 99–111. https://doi.org/10.1007/BF00196791.

Laurie, Ben, Adam Langley, and Emilia Kasper. 2013. Certificate Transparency. RFC 6962. https://doi.org/10.17487/RFC6962.

Li, Jinyuan, Maxwell Krohn, David Mazières, and Dennis Shasha. 2004. “Secure Untrusted Data Repository (SUNDR).” 6th Symposium on Operating Systems Design and Implementation (OSDI), 121–36. https://www.usenix.org/legacy/event/osdi04/tech/full_papers/li_j/li_j.pdf.

Malik, Sidra, Volkan Dedeoglu, Salil S. Kanhere, and Raja Jurdak. 2019. “TrustChain: Trust Management in Blockchain and IoT Supported Supply Chains.” IEEE International Conference on Blockchain. https://doi.org/10.1109/Blockchain.2019.00032.

Malvai, Harjasleen, Lefteris Kokoris-Kogias, Alberto Sonnino, et al. 2023. “Parakeet: Practical Key Transparency for End-to-End Encrypted Messaging.” Network and Distributed System Security Symposium (NDSS). https://www.ndss-symposium.org/ndss-paper/parakeet-practical-key-transparency-for-end-to-end-encrypted-messaging/.

Smith, Samuel M. 2019. Key Event Receipt Infrastructure (KERI). https://arxiv.org/abs/1907.02143.