Appendix: Standards and Threat Positioning
This appendix preserves the prior-art and threat-model detail behind the positioning chapter. The main argument stays focused on the Helios/EventChain relationship; this appendix shows how the EventChain proof layer 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. 2021; Google 2026). SCITT generalises transparency receipts for supply-chain statements using COSE/CBOR and external transparency services (Birkholz et al. 2025). 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 highlights a critical limitation for supply chains: blockchain can preserve records while leaving truth at origin unresolved (Malik et al. 2019).
EventChain borrows the durable lessons and chooses a different operating point: identity-bound event authorship, portable proof artifacts, role-aware distribution, lightweight verification, and daily public time anchoring.
| Property | EventChain | SCITT | CT / Trillian | Haber & Stornetta | KERI |
|---|---|---|---|---|---|
| Primary object | Enterprise event chain | Supply-chain statement receipt | Certificate log entry | Time-stamped document hash | Key-event history |
| Attribution granularity | Registered actor (WebAuthn passkey or TPM/PUF credential) | Entity via X.509 or OIDC | Certificate authority / subject | Time-stamp only | Identifier controller |
| Proof location | Travels with authorised holders | External transparency service receipt | External log | External time-stamp chain | External key-event log |
| Verification mode | Offline file verification | Receipt verification against service parameters | Log inclusion / consistency proof | Chain verification through time-stamp service | Key-event log verification |
| Operational weight | JSONL, SHA-256, passkeys, webhooks | COSE/CBOR, verifiable data structures, registry operation | Merkle log infrastructure | Hash chain and time-stamping service | KEL and witness infrastructure |
| Storage and distribution | Built into Hub, RBAC, and webhook model | Left to implementers | Outside certificate-log scope | Outside protocol scope | Outside protocol scope |
| Access control | First-class enterprise feature | Out of scope | Public log model | Out of scope | Out of scope |
| Custody transfer | Multi-signature handoff primitive | Application-defined | Outside scope | Outside scope | Outside scope |
SCITT and EventChain operate at different layers. SCITT answers whether a signed statement was registered in a transparency service. EventChain answers who wrote a specific event, how it relates to the surrounding sequence, which authorised parties received the proof, and whether the artifact verifies offline. An organisation could register EventChain artifact commitments in a SCITT transparency service for additional public auditability. The core EventChain guarantee still comes from the artifact and verifier held by authorised parties.
Adversarial Hub Analysis
The Hub performs useful work: event intake, hash computation, signature capture, RBAC distribution, indexing, and live portal presentation. Those services create operational trust. EventChain constrains that trust through independent verification.
Three Hub failure modes matter.
| Failure Mode | Detection Path | Residual Risk |
|---|---|---|
| Hub alters an old event | Any holder recomputes the chain and sees the break | A party must run verification or compare against an already-held copy |
| Hub withholds an event from a role-authorised party | Recipient sees a gap through sequence numbers, daily anchor mismatch, or counterpart comparison | Access-policy disputes may require governance or contract enforcement |
| Hub binds a valid signature to wrong metadata | Any holder with the metadata recomputes the content hash and detects mismatch | Parties lacking the relevant metadata cannot test that specific mismatch |
The defence is layered rather than absolute. Hash chaining makes tampering detectable. Identity-bound signatures make authorship attributable. Role-based distribution gives multiple parties overlapping views. Daily OpenTimestamps rollups can anchor the chain state publicly. Legal and contractual controls govern the Hub operator’s service obligations.
This trade-off differs from replicated-ledger architectures. Replicated ledgers reduce reliance on one operator by requiring multiple operators to process shared state. EventChain reduces reliance on the operator by making the evidence portable and independently checkable. The first approach spends infrastructure to prevent some operator failures. The second spends minimal infrastructure and makes failures discoverable by any authorised holder.
Source-Data Boundary
No provenance architecture can determine whether every source claim matched physical reality. A signed inspection can still reflect an honest error. A sensor can still mismeasure. A supplier can still collude with a buyer. Cryptography preserves the record of an assertion and makes later alteration detectable; process controls, calibration, governance, and contract enforcement address source-data quality.
EventChain’s claim remains narrower and stronger: once an event enters the record, later alteration becomes detectable, authorship remains bound to a named actor, the sequence remains independently verifiable, and the proof can travel beyond the platform that produced it. Helios uses that layer before analytics, automation, compliance portals, and product passports operate on lifecycle history.