One file per payment, verifiable without us.
The Evidence Record is what the layer leaves behind. Everything upstream exists to make it true.
Sealed once, attested outside
Hash-chained records, a signed daily root, proofs that never touch the bytes.
Explore the fields
Sixteen core fields, six for B2B rails. Click a field.
Core · 16
B2B addendum · 6
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",
"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.