Ledger

The Ledger is ENI6MA’s immutable nonce registry. It enforces one-time use, TTL-based expiry, and burn-before-validate so that every proof ceremony consumes exactly one nonce and replays are rejected at the infrastructure layer. The Registry (or any authorized service) reserves nonces for challenges and burns them when proofs are submitted; the Ledger never sees secrets or proof payloads in the clear beyond what is needed to record the burn and audit events.

Nonce lifecycle

Every authentication attempt starts with a reserve and ends with a consume (burn). In between, the nonce is in state RESERVED and is bound to a single challenge. The Registry calls POST /reserve to obtain a nonce; the Ledger returns a UUID, a tau (τ) timestamp in microseconds, and a TTL (default 300 seconds). The Registry uses tau to generate session-unique challenge geometry. When the client submits a proof, the Registry calls POST /response with the nonce UUID and payload; the Ledger atomically transitions the nonce from RESERVED to SPENT. A second submission with the same UUID is a replay and returns 409 Conflict. An expired nonce (no burn within TTL) returns 410 Gone. A tau mismatch or invalid request returns 400 Bad Request.

POST /reserve: uuid, tau, TTL

POST /reserve creates a new nonce entry. The Ledger allocates a unique UUID and a tau value (microsecond timestamp). The response includes the UUID, tau, and TTL so the caller can bind the challenge to this nonce. No secrets are stored; the Ledger only records that this nonce exists, is RESERVED, and will expire at now + TTL. Typical TTL is 300 seconds (5 minutes), which is enough for a user to complete the ceremony but short enough to prevent long-lived challenge stockpiling. Integrators should not reserve nonces far in advance; reserve when you are about to present the challenge.

POST /response: burn and 409/410/400 semantics

POST /response consumes the nonce. The request body includes the nonce UUID and the payload (e.g. hash or reference) that the Registry uses for verification. The Ledger does not verify the proof itself; it only records that this nonce is now SPENT and associates the payload hash (or similar) for audit. If the nonce was already SPENT, the Ledger returns 409 Conflict — this is the replay response. If the nonce has expired (TTL elapsed without a burn), the Ledger returns 410 Gone. If the request is malformed or tau does not match the reserved nonce, the Ledger returns 400 Bad Request. On success, the Ledger returns 200 and the nonce is permanently SPENT; no further use of that UUID is allowed.

Burn-before-validate

A critical design rule is burn-before-validate: the Registry must burn the nonce (POST /response) before running the cryptographic proof verification. If validation were done first, an attacker could submit a wrong proof, see that it failed, and try another guess against the same challenge. With burn-before-validate, the first submission — correct or not — consumes the nonce. So each challenge accepts exactly one validation attempt. This makes replay structurally impossible and bounds the attack surface: even an intercepted proof cannot be replayed because the legitimate submission (or any single submission) already burned the nonce.

GET /status and GET /events: audit without PII

GET /status/{uuid} returns the current state of a nonce (RESERVED, SPENT, or expired). This is useful for debugging and for visibility services that show whether a given challenge is still valid. GET /events (or the Ledger visibility API) provides an audit feed of reserve, consume, and optionally access-log or success events. Events record circuit hash (or handle), nonce UUID, timestamp, and payload hash — never user secrets, bearings, or PII. Compliance and security teams can reconstruct “who attempted what and when” without exposing any credential material. The Ledger visibility service (e.g. ledger.eni6ma.net) is a read-only gateway for this audit trail.

Why the Ledger matters for developers

Without the Ledger, the combinatorial security of the proof system would be theoretical — an attacker could try many guesses offline against a captured challenge. The Ledger makes the barrier practical: each guess costs one nonce, nonces must be reserved through the API and consumed within TTL, and rate limiting (e.g. 10 validations per minute per circuit) caps the attempt budget. So brute force becomes infeasible (e.g. 12-round circuits require billions of attempts; at 10/minute that is hundreds of years). At the same time, every attempt is logged, so brute-force patterns are visible long before they could succeed. For integration: always treat a nonce as single-use and time-bound; on 409 or 410, request a new challenge rather than retrying the same nonce.

Why the no-replay Ledger is a breakthrough for human auth

Human authentication has always faced a single catastrophic weakness: replay. In every traditional system, the artifact a human presents — a password, a one-time code, a session cookie, or a signed token — can be captured and replayed. The attacker does not need to understand the cryptography; they need only to obtain the artifact and present it again. ENI6MA’s Ledger eliminates replay at the infrastructure level through three mechanisms that work together: nonce uniqueness, burn-before-validate, and time-to-live expiry. Together they make capture-and-replay impossible for human auth in a way no password, MFA, or session-based system can match.

Nonce uniqueness. Every authentication attempt starts with the Registry reserving a nonce from the Ledger: a unique identifier (UUID) plus a tau (τ) timestamp in microseconds. That nonce is bound to exactly one challenge. The challenge geometry is derived from tau and from the circuit’s entropy, so the same nonce never produces two different challenges, and two different reservations never produce the same nonce. There is no “try again with the same challenge” — the Ledger guarantees one nonce per challenge and one challenge per nonce. In human terms: every time you authenticate, the system creates a brand-new, single-use slot. No slot is ever reused.

Burn-before-validate. When the client submits a proof, the Registry’s first action is to burn (consume) the nonce in the Ledger — transitioning it from RESERVED to SPENT. Only after the burn succeeds does the Registry run the cryptographic proof verification. If validation happened first, an attacker could submit a wrong proof, learn that it failed, and try another guess against the same challenge. With burn-before-validate, the first submission — right or wrong — consumes the nonce. A second submission with the same nonce receives HTTP 409 Conflict: the Ledger rejects it as a replay. So each challenge accepts exactly one validation attempt. Even if an attacker intercepts the user’s proof in transit, they cannot replay it: the moment the legitimate submission was processed, the nonce was burned. Replay is structurally impossible.

Time-to-live expiry. Every reserved nonce has a TTL (default 300 seconds). If no validation occurs within that window, the nonce expires and the Ledger marks it invalid. Subsequent submissions receive HTTP 410 Gone. This prevents challenge stockpiling (an attacker cannot reserve many challenges and brute-force them offline) and stale replay (an old captured proof is bound to a nonce that has long since expired). The window for any single authentication is both one-use (burn) and time-bounded (expire). Human users complete the ceremony in under a minute; the system never grants indefinite or long-lived value to a captured proof.

Ledger visibility and audit

The Ledger visibility service (e.g. at ledger.eni6ma.net) provides a read-only public gateway into the nonce registry. Security and compliance teams can monitor nonce lifecycle events, challenge attempts, validation outcomes, and replay prevention events in real time. This transparency layer enables audit without exposing sensitive data: the Ledger records what happened and when, never what the user’s secret is. Events typically include circuit hash (or handle), nonce UUID, timestamp, and payload hash — no bearings, no secrets, no PII.

GET /events (or the deployment’s visibility API) returns an audit feed of reserve, consume, and optionally access-log or success events. Integrators and auditors can reconstruct “who attempted what and when” for forensics and compliance without ever handling credential material. The Ledger’s design ensures that even a full export of event data cannot be used to impersonate a user or replay a proof.

TTL and challenge stockpiling

The default TTL of 300 seconds (5 minutes) is chosen to be long enough for a user to complete the ceremony comfortably but short enough to prevent an attacker from reserving large numbers of challenges for later offline analysis. If an attacker could reserve thousands of nonces and take the corresponding challenges offline, they could in theory run brute-force or correlation attacks at their own pace. TTL expiry makes that impossible: unused challenges become invalid after the countdown, and the Ledger does not extend or refresh TTL on an existing nonce. Integrators should reserve a nonce only when they are about to present the challenge to the user, not far in advance.

Similarly, rate limiting on the Registry (or on the Ledger when called directly) caps how many reserves (and thus validations) can occur per time window. Together, TTL and rate limiting bound both the lifetime and the volume of active challenges, so that neither stockpiling nor sustained online brute force is feasible.

Comparison to passwords and sessions

Passwords are infinitely replayable until changed. Session tokens are replayable for the entire session — often hours or days. TOTP codes are replayable within the 30-second window. SMS codes are replayable until used. Passkey signatures are bound to a challenge but the session that follows is still a long-lived token. In every case, the human’s act of authenticating produces something that can be captured and replayed within some time window. ENI6MA is the only system where the human’s authentication output is by design single-use and time-bound at the infrastructure layer. The Ledger is not an add-on; it is the mechanism that makes “no replay” enforceable. No amount of user training or policy can achieve that in a password or session world — only a system that never issues a reusable artifact and that burns and expires every single-use slot can. For human authentication, the Ledger is what makes the ephemeral witness actually ephemeral.

Ledger semantics reference

For full request/response schemas and deployment-specific details, see the Ledger service API documentation and the For developers page. Summary: reserve → RESERVED with uuid, tau, TTL; response (burn) → SPENT, 200; replay → 409; expired → 410; tau mismatch or bad request → 400. Audit events are available without PII for compliance and forensics.