Verify
What you can check at L1, what the free offline verifier checks at L2, and what verification does not prove.
You can verify an elan1 proof record without asking elan1. At L1, recompute the record's SHA-256 digest from its 16 fields and confirm it matches the next record's link in the chain. From L2, also check the Ed25519 signature and outside timestamp with the free offline verifier.
01At L1 Guarded · Available
Each record holds the digest of the one before (F03). Recompute SHA-256 over the length-prefixed fields and walk the chain; a changed or missing record breaks it.
Tamper-evident to you; not signed. At L1 you can see that the chain has been broken. Proving offline who sealed it is L2 Attested.
Chain intact. Digests computed when this page was built; recompute them yourself below.
Your browser does the arithmetic: SHA-256 over each field’s 4-byte length followed by its UTF-8 bytes, in field order. Nothing is sent anywhere.
02One record, all sixteen fields
The same arithmetic, on one full proof record. Change a field and the digest no longer matches what the next record expects.
Rendering · shown beside the record, never a seventeenth field
Checked and recorded by elan1 Govern · tamper-evident (L1)
Record 1042 points back to record 1041 by digest (F03 prev_digest).
Rendering · shown beside the record, never a seventeenth field
Checked and recorded by elan1 Govern · tamper-evident (L1)
L2 · Available Simulated here. The real check runs in the free offline verifier.
Signature
Check the Ed25519 signature on record 1042 against the residency domain's public key, obtained out of band.
Anchoring
Check the Merkle root that contains record 1042 against timestamps from two RFC 3161 authorities, anchored within 15 minutes.
Evidence bundle
Open the eight-member evidence bundle and run the free offline verifier, elan1-verify, on your own machine with no network.
At L1 records are hash-chained, not signed, and the check needs elan1. The three steps above describe the L2 design. Nothing on this page was signed or anchored.
How the browser recomputes: the preimage is the 19-octet domain string elan1.proof.seal.v6, then each of the 16 fields as a 4-octet big-endian length followed by its bytes. SHA-256 runs through WebCrypto on this device; nothing is sent. Where this is weak: the specimen encodes every field as UTF-8 text, while Seal v6 encodes identifiers and digests as fixed binary octets. It shows the method, not a production verifier.
03At L2 Attested · Available
Steps advance only when you choose one: with the step buttons, or the arrow keys on a keyboard. Nothing plays on its own.
You export a bundle for a period or a set of records and keep it. Nothing in the steps that follow calls elan1, so the check does not depend on us being reachable, or on taking our word for it.
You check: You hold one file. Every later step reads only what is inside it.
Available · L2 AttestedAt L2, each record is signed with the key of the residency domain it was written in: "in" for India. A record signed with any other key fails.
You check: Every signature verifies against the published domain key.
Available · L2 AttestedThe records in the bundle hash up to one root. Recompute it from the records you hold. If one record was added, removed or changed, the root you compute differs from the root in the bundle.
You check: Your recomputed root equals the bundle's root.
Available · L2 AttestedTwo independent timestamp authorities each stamp the root, and the root is anchored within 15 minutes. With two authorities, the time does not rest on a single party's clock, including ours.
You check: Both timestamps verify, and both fall inside the 15-minute window.
Available · L2 AttestedThe verifier repeats steps 02 to 04 and prints a result for each record. It runs air-gapped, and it is free: it comes with L2 Attested.
You check: A per-record result, produced on a machine elan1 never touches.
Available · L2 AttestedThe sample bundle
| Check | Result | Detail |
|---|---|---|
| 01 Manifest hashes | Pass | Every member matches its hash in manifest.json.The hash of seals.jsonl differs from the one in manifest.json.The hashed members match manifest.json.The hash of keys.json differs from the one in manifest.json. |
| 02 Ed25519 signatures against the “in” domain key | Pass | 6 of 6 records verify against the published key for domain “in”.Fails for seq 2207: the record no longer matches what was signed.Signed with a key not published for domain “in”. |
| 03 Merkle root | Pass | The recomputed root, 9c1e…44af, equals the bundle's root.The recomputed root, 51d0…a7e3, differs from the bundle's root, 9c1e…44af. |
| 04 Two RFC 3161 timestamps within 15 minutes | Pass | Both tokens cover root 9c1e…44af, stamped inside the 15-minute window.Both tokens still verify. They stamp the original root, which no longer matches the records.The second authority's token does not cover this root. |
| 05 Hash chain | Pass | Seq 2203 to 2208 link without a gap; every prev_digest matches.Mismatch at seq 2208: its prev_digest no longer matches record 2207. |
Bundle verified. 6 records, root 9c1e…44af, both timestamps inside the window.
| No. | What you can check |
|---|---|
| 01 | Each record signed with the residency domain's Ed25519 key |
| 02 | Records hashed up to one Merkle root per bundle |
| 03 | The root stamped by two RFC 3161 timestamp authorities and anchored within 15 minutes |
| 04 | The free offline verifier, run on your own machine with no network |
04Limits
Verification tells you the record is what was sealed. It does not tell you the record was a good idea.
| Proves | Does not prove |
|---|---|
| The record has not changed since sealed | The business decision was right |
| Which rules and version applied | The rules were good |
| Who acted, at what autonomy level | Nothing happened outside elan1 (Mode B) |
Mode B records show what elan1 was asked and what it decided. A write made around elan1 in Mode B leaves no record here; that is why we never say “enforced” for Mode B.
05Versions
L1 Guarded and L2 Attested available. The five L2 steps and the free offline verifier now describe the product as it is.
Owner decision, 10 Oct 2026: all four platforms launched.
Verification page published: the L1 chain check, the five L2 steps, and the limits of verification.
First public version.
When a claim, a level or a price changes, the change is logged here with the reason. Earlier versions stay readable; history is never edited in place.
06FAQ
At L1, recompute the record's SHA-256 digest from its 16 fields with the published Seal v6 method, and check that it matches the link carried by the next record in the chain. From L2, also check the Ed25519 signature and the outside timestamp with the free offline verifier. This page walks through both.
No. The digest method is published, so anyone can recompute a record and walk the chain. From L2 Attested, the free offline verifier checks a signed evidence bundle on your own machine, with no network and no request to elan1.
That a record was changed, removed or inserted after it was sealed, or that the record you hold is not the one that was sealed. The first record whose digest does not match the next record's link shows where the chain breaks. Verification shows that a change happened; it does not tell you who made it.
// VERIFY
We walk an assurance team through a specimen chain, field by field, and show where L1 ends and L2 begins.