Skip to content

How evidence works

The idea in one paragraph

Everything consequential that happens on Exedra Gate, a document uploaded, a signature placed, an envelope finalised, an access rule changed, is written as an event into an append-only record. Those events are hash chained, the finished record is signed, and the signed record is timestamped by an independent authority. The result is a record that a third party can check on their own machine, with standard tools, without asking Exedra Gate whether it is intact.

The chain: tamper-evident, not tamper-proof

Each event in the record carries a SHA-256 hash of its own content and the hash of the event before it. Editing, inserting or removing an event afterwards breaks the chain at that exact point, so a verification run does not just say the record was altered, it says where.

The precise claim matters. A hash chain does not prevent alteration; no honest system can promise that about its own administrators. What it does is make alteration detectable and attributable: the record as it stood is reconstructable, and a record that has been tampered with stops verifying. Detectable is a property that can be demonstrated on demand. Unalterable is a property that can only be asserted, which is why Exedra Gate says tamper-evident and never anything stronger.

The signature: who stands behind the record

When an evidence pack is generated, its pack hash is signed with Ed25519. The public key and the key id travel inside the pack, so an old pack can still be checked after a key rotation. By default the platform key signs. A client running signing delegation signs with a key they operate themselves, on their own hardware, and the private key never exists on the platform; the pack then verifies against the client's pinned public key, and key custody is theirs. Either way, the signature makes one statement: this exact record, byte for byte, is the one that was generated.

The timestamp: independent time

A signature from the operator of a system proves little about when something happened, because the operator controls its own clocks. So the pack is timestamped under RFC 3161 by an authority independent of Exedra Gate: a SHA-256 fingerprint of the record is sent out, and a signed token comes back attesting that this content existed at that moment on the authority's clock. When timestamping is configured as required, a timestamp failure means no evidence pack is produced at all; the system refuses rather than issuing a weaker artefact quietly.

The claim ladder is stated rather than implied. An RFC 3161 timestamp is admissible evidence a court can weigh. It is not an eIDAS qualified timestamp, which carries a legal presumption of accuracy on top; Exedra Gate does not claim that presumption for the default token, and a client whose obligations require the qualified form should raise it before relying on one.

What the words mean here

Exedra Gate uses a small vocabulary deliberately, because each word is a claim:

  • Tamper-evident: alteration is detectable through the chain and the signature. Never tamper-proof.
  • Verifiable: a third party can check the record with ordinary tooling, offline.
  • Reconstructable: the record carries enough to re-derive and re-check what happened, in order, from the artefacts alone.
  • Independently timestamped: the time attestation comes from an authority Exedra Gate does not control.

What is deliberately absent from that list: proven true, endorsed, and any claim about the quality of what was signed. Evidence here is a record of process, not a judgement of content.

Where you meet this in the product

Signing runs on Exedra Gate's own engine with no external e-signature vendor in the path, and every envelope's audit trail is chained from creation to completion. Evidence packs are generated when signing completes and are yours to download and keep. Client workspaces additionally keep a chained access-event ledger of network rule changes and denied sign-ins. All of it is checkable with the same handful of primitives: SHA-256, Ed25519 and RFC 3161. The verification guide walks through every check with runnable commands.