One file per payment, verifiable without us. The Evidence Record is what the layer leaves behind. Everything upstream exists to make it true.
Hash-chained records, a signed daily root, proofs that never touch the bytes.
Sealed bytes
- rec_…VZ sha256 e91a…0c3d
- prev …
↓ prev hash
- rec_…W6 sha256 b0d4…71c9
- prev e91a…0c3d
↓ prev hash
- rec_…X1 sha256 4c2f…a9e0
- prev b0d4…71c9
↓ rolled into
- daily root
- signed checkpoint
Each record has a bundle outside its bytes: RFC 3161 time-stamps, proofs and keys. Renewals never change the record hash.
Sixteen core fields, six for B2B rails. Click a field.
Core · 16
B2B addendum · 6
enruta/0.2 · 8
enruta/0.3 · 11
record
Identity of the record: a ULID with the rec_ prefix, the schema version, creation time and the sequence number inside the customer chain.
"record": {
"id": "rec_01J9Q2W6G5X8ZK3R7T1V9M4N2B",
"schema": "enruta/0.3",
"created_at": "2026-11-30T18:01:44Z",
"sequence": 4127
}One record per attempt
Approved, denied or expired, each request leaves exactly one record. The absence of a payment is evidence too.
Content-addressed
The record’s identity is the hash of its canonical bytes: RFC 8785 canonicalization, SHA-256.
Chained and checkpointed
Each record names the previous record’s hash. Records roll into a daily root whose signed checkpoint is published the same day.
Time-stamped outside the bytes
RFC 3161 tokens, inclusion proofs, an OpenTimestamps anchor and renewals live in a companion bundle, so the record itself is never touched.
Keys snapshotted
Every verification key used at capture is stored with a provenance tag. A verifier in 2033 needs no live endpoint.
Open verifier
enruta-verify, the schema and the test vectors ship as Apache-2.0 inside every export. Anyone can write another verifier and check it against the vectors.