Evidence Rail

The seal binds the entity id, entity type, version, data hash and signed_at into one length-prefixed binding root, and then signs it.

• Signature: Ed25519 (RFC 8032), strict verification. 150 of 150 Wycheproof Ed25519 vectors pass.
• Hash: SHA-256.
• Canonical form: RFC 8785 JSON Canonicalization, pinned by 12 frozen golden vectors.
• Domain separation: every signed payload carries a fixed prefix, so a signature can't be reused across protocols.

A seal verifies only if it was signed by 0REI's pinned key. A seal that merely verifies against a key embedded in itself is rejected.

Seals are batched into a Merkle tree. The root of each batch is stamped by an external RFC 3161 time-stamping authority, so "existed no later than T" doesn't depend on 0REI's clock.

Production stamps through FreeTSA, with DigiCert configured as the fallback.

• 0rei-verify, a standalone command line tool that runs without the API server.
• The orei Rust crate, to seal and verify in-process.
• Merkle inclusion proofs that a third party checks with only the leaf, the proof and the root.
• Seals embedded in PNG images, checked off the file with no database lookup.

• Optimistic concurrency control. Parallel writers can't silently overwrite each other, and conflicts surface as HTTP 409.
• An entity and its seal are created in one transaction, so a partial write is impossible.
• Append-only delta entries (Increment, Decrement, Append, Set) for high-frequency settlement.
• Pluggable HSM signing, with an AWS CloudHSM integration path on the FIPS 140-2 Level 3 pathway. This is an integration path, not a product certification.

That the data was true when it was sealed. That the key holder is who they say they are, without a separate identity system. That no records are missing from a set.

The signing step alone, measured in a loop with no API, database or timestamp: 46,696 signatures/sec (median of 8 runs).

The full engine, API + Postgres with fsync on: ~547 seals/sec (2026-10-26).

Method and limits