Pedersen Commitments & K1 Key Pre-Rotation

Both features complete 0REI version 4 and run on main. They live inside CoreSeal, the hand-written Rust sealing engine, and they are bound into every seal's signed binding root. The nine-point time layer brackets every seal and every chain head with outside witnesses, and the 0REI Offline Verifier checks every step on an air-gapped machine against pinned trust roots.

One Ed25519 signature covers the record, its committed values and its time.

Open the page: The 9-Point Time Stamping System

• Private totals. Auditors, insurers and regulators confirm sums and ranges over sealed records while the records stay sealed.
• Customer-held secrets. The opening secret stays with the customer by default.
• Hardware-rooted identity. The genesis key signs only inside certified hardware, and the seed is never exposed.
• Key compromise containment. A stolen current key can't redirect 0REI's chain to an attacker's key, and a compromised bridge agent key is revoked mesh-wide with immediate presence invalidation.
• Outside time. Seals and chain heads carry "not before" and "existed by" evidence from independent witnesses.
• Independent proof. Everything is recomputed offline from the evidence itself, with no call to 0REI.

C = v·G + r·H on the Ristretto255 group. v is the value (a 64-bit unsigned integer), r is a random blinding factor, and C is the commitment.

• Perfectly hiding. With a fresh random r, C reveals nothing about v, even to unlimited computing power.
• Computationally binding. Opening C to a different value would require solving the discrete logarithm problem on Ristretto255. H is derived by hashing the public string 0REI-pedersen-H/v1 onto the group, so nobody knows a number x with H = x·G. Its exact value is pinned by a test.
• Classical-only binding. The 0REI PQ claims ledger records this property for 0rei-commitments/v1, so the outside time witnesses stamp the seal's plain hash fingerprint.

In plain English: A value goes into a locked box together with a random secret. The box shows nothing about what is inside, and it can only ever be opened to the value that went in.

• Customer-held mode (default). The customer's side commits and range-proves each value with fresh local blindings and keeps the blindings. The sealing request has no field for the value or for r, and any unknown field is refused. 0REI seals values it never sees.
• 0REI-held mode (opt-in). 0REI commits the values, writes each commitment into the payload in place of the clear value, signs, and returns the blindings to the caller.

Blinding factors are wiped from memory on drop, compared in constant time and redacted from debug output.

In plain English: The customer keeps the only key to their own boxes. 0REI signs the locked box without ever seeing inside.

Each committed field carries a Bulletproof range proof that the value lies in [0, 2⁶⁴). The proof is bound to the record's entity id, entity type, version and field name, so a proof copied to another field or another record fails. A negative row can't carry a passing proof, and tampered proof bytes fail.

In plain English: Alongside each locked box sits a short certificate proving the hidden number is a sensible, non-negative amount, and that certificate only fits that one box, in that one record, under that one field name.

The commitments block (0rei-commitments/v1, 1 to 64 fields) is digested and folded into the seal's signed binding root. Swapping a commitment, or stripping the block, breaks the seal. Seals are issued in format v4, which also signs the seal's seal_id. A payload that puts a clear amount beside a commitment to zero is refused by name.

In plain English: The locked boxes are stapled into the seal before it is signed, so changing, adding or removing any box breaks the signature.

Commitments add: ΣCᵢ = V·G + R·H. 0REI proves that a set of sealed records sums to a stated total without opening any row.

• The total proof (`0rei-aggregate/v2`). A Schnorr proof shows knowledge of the blinding sum R without publishing it. The verifier recomputes ΣC from the sealed rows themselves.
• No subtraction attacks. Because R is never published, two totals over sets that differ by one row can't be subtracted to recover that row.
• Strict set rules. At least 5 counted records and at most 10,000. No record named twice. Two versions of one entity count once. Every row passes full seal verification first, including revocation. Every row is inside the stated entity type and period.
• Completeness. An N-of-N attestation shows that no version of a named entity was dropped, and the verdict says exactly which completeness level was shown, so a cherry-picked set is identified as such.
• The overlap ledger. POST /api/v1/aggregates/prove sums only the calling organization's own stored rows. A new set that overlaps a total already issued on the same field is refused with HTTP 409: "overlapping totals are refused". Audit events carry counts only, never values or blindings.
• Command line. 0rei-verify --aggregate proof.json seal1.json seal2.json … exits 0 when the total is proven and 1 otherwise.

In plain English: Locked boxes can be stacked and weighed together. The total weight proves the total amount without opening any one box.

A proven total reveals one number: the sum over the named records. Everything else stays committed. A total is a sum, so a party who already knows every value but one learns the last one by subtraction, as with any published total. That is why every total covers at least five records, R is never published, overlapping totals are refused, and the issuer decides who receives a total.

• The commitment. Each key publishes SHA-256 of the next Ed25519 public key. Only the digest is published; the next key itself is revealed at rotation. The genesis key signs an inception that commits to its first successor.
• The rotation. A rotation link is signed by the outgoing key and by the pre-committed incoming key. The incoming key's digest must match the commitment made one step earlier. A thief holding only the current key can't rotate, can't choose the effective time and can't choose the next commitment.
• Domain separation. Every signed statement type has its own domain string, so a signature made for one kind of statement never verifies as another.

In plain English: A handover needs two signatures: the person leaving and the successor named in advance. A thief holding only the departing key cannot complete it.

The verifier checks that the chain is rooted at the genesis key compiled into it, that the inception matches the pinned inception digest, and then, link by link, that each new key hashes to the digest named before it and that both keys signed. The result is one key epoch per key, [active_from, active_until). A seal is trusted only when its signed_at falls inside its signing key's epoch. Forks, cycles and times that run backwards are refused.

In plain English: The verifier walks the line of succession from the founder forward, checking at each handover that the newcomer is exactly the person named in advance.

The genesis key was created at a formal key ceremony inside a FIPS 140-3 validated hardware security module, on a dedicated ceremony machine with no network connection. The genesis key and its pre-committed successor are generated inside the module, and Ed25519 signing happens inside the hardware: the private keys and their seed are never exposed to the machine, the operators or any file. A second FIPS 140-3 module holds a wrapped backup. After the ceremony both modules are unplugged and stored apart. Only public outputs leave the room: the genesis public key and the signed inception, both compiled into every verifier.

In plain English: The master key is born inside a certified safe, signs only inside that safe, has a sealed twin in a second safe, and both safes are then locked away. The world only ever sees the public half and the signed promise naming the next key.

Every published chain head is signed, carries a sequence number, and is stamped by the time layer's witnesses (RFC 3161 formal timestamps and the hash-only permanent anchor). Each verifier keeps the newest head it has authenticated as a floor, and refuses any chain that is shorter, older, or different at the same sequence. GET /api/v1/trust/chain serves only a chain it has verified, with Cache-Control: no-store, and answers 503 whenever it can't verify.

In plain English: Every verifier keeps a copy of the newest succession list it has seen, and refuses any list that is shorter, older or different.

• Stolen current key. Rotation to the thief's own key fails, because the incoming key must hash to the digest named before the theft. The rightful holder of the pre-committed key completes the next rotation.
• Current and next key held apart. The committed successor is generated inside the ceremony HSM and stays offline until its rotation, while the current key signs in the production signer.
• Stolen genesis key. The genesis key signs only inside the HSM, and the inception is pinned in the verifier, so genesis can't skip or replace its own commitment.
• Revocation. Signed revocation lists revoke a key from its revocation time onward, so earlier honest seals stay valid.

In plain English: If a key is stolen, the thief is stuck: the only valid next holder was named in advance, and the revocation list cuts off the stolen key from the moment it is reported.

Online seal verification resolves the signing key through the same chain and key epochs, so a seal signed by a rotated key verifies online exactly as it does offline. Every proof bundle (raw seal, Merkle inclusion path, anchored batch, RFC 3161 token) carries the chain file, its inception and the signed chain head, so the Offline Verifier checks all four layers and the K1 trust in one air-gapped pass.

Open the page: Offline Verifier

Open the page: Zero Search

TremorFrost Bridge, 0REI's signed agent message bus, roots in its own configured admin key set: admins approve every agent key, every envelope is signed and replay-gated at ingest, and retired keys are revoked on demand. The bridge never links 0REI's crate, and its keys never chain to the 0REI genesis key or the K1 chain. The two share exactly two things: the frozen RFC 8785 golden test vectors and the shared conformance CI. The 0REI genesis HSM never signs live bridge traffic.

• Every envelope is signed over an eight-line input that binds it to one mesh instance, so traffic signed for one mesh never verifies on another.
• The ingest gate fails closed at every step, and storage opens only after the signature verifies, so a forged message never consumes a nonce.
• A revoked agent key is cut off immediately: presence is invalidated, and any message signed by the revoked key is refused. Agent rows are never deleted, so attribution is permanent.
• Admin keys sit on a hardware security key that each operator physically holds, a separate device from the 0REI genesis HSM.

When bridge records reach Evidence Rail, CoreSeal seals them under 0REI's own K1-chained seal keys, and the agent signatures inside them verify under the bridge's own key registry.

In plain English: Every agent on the bridge holds an ID card that the bridge's own admins approved. Every message carries a fresh signature over its exact bytes, and the front door checks the card, the signature and the freshness before a single byte is stored.

Open the page: TremorFrost Tier 3

Open the page: Evidence Rail

Every capability below reuses the same generators, the same transcripts, the same chain rules and the same Offline Verifier.

• Selective disclosure. Open one committed field to one party while every other field stays sealed, with or without handing over that field's blinding factor. Show the auditor one line of the sealed invoice. Every other line stays in its locked box, and the signature over the whole invoice still checks.
• At-least, at-most and threshold proofs. Prove "this balance is at least $50,000" or "this dose is under the limit" without saying what the number is, on single values and on totals.
• Aggregated range proofs. Many fields, one proof, logarithmic size: 64 fields take one 1,056-byte proof instead of 43,008 bytes of separate proofs.
• Standards-native outputs. IETF SCITT receipts for each seal, C2PA manifests on every Steg PNG, KERI-compatible key event logs for the K1 chain, and A2A-compatible signed agent messages from TremorFrost Bridge.
• Robust watermark for Steg. A robust layer that survives recompression, resizing and screenshots carries the seal id beside the fragile LSB seal, so one image answers both "is this the sealed image?" and "which sealed image did this come from?"
• Proof-backed search. Zero Search queries carry predicates over committed fields: a query for "amount at least t" returns the matching sealed records with their at-least proofs.
• Published cryptanalysis research. 0REI publishes its cryptanalysis research through peer review, giving diligence teams an independent, citable basis for the security arguments.
• Multi-party and threshold rotation. No single person rotates, and no single device signs. Signing keys are held as FROST (RFC 9591) m-of-n shares that produce ordinary Ed25519 signatures.
• PQC hybrid signing, with pre-rotation of PQC keys. Ed25519 plus FIPS 204 ML-DSA-87, both required to verify, on the same K1 chain. Each hybrid key names its hybrid successor in advance.
• Autonomous adversarial testing at GPU-cluster scale. The T3 engine, merged with TremorFrost's Tier 3 fence and ratchet, generates mutated seals, proofs, chains, bundles, Steg images and bridge messages and runs each through the Offline Verifier and the bridge verifier. Every refusal must name the right rule, and every finding is sealed into Evidence Rail.
• Aggregate audits at scale. Auditors run totals and threshold proofs across many periods and entity types over committed records.
• Bridge admin keys in hardware, with m-of-n approval. The bridge's admin keys are held in a dedicated HSM, separate from the 0REI genesis HSM, and every enrollment, revocation or rotation grant needs m of n admin signatures.

Open the page: Zero Search

Open the page: Proof

Signing runs behind an abstract HsmSigner trait with algorithm tags (Ed25519-SHA256), so the signature scheme can change to FIPS 204 ML-DSA-87 without altering ledger formats.

• The full all-target suite: 462 passed, 0 failed, 7 ignored (source 3c7765a), with dedicated Pedersen, aggregate, K1, attack and cross-language vector suites.
• 17 named Pedersen known-answer vectors. Flipping one proof byte makes every verify vector refuse.
• Rotation vectors are checked in JavaScript and in Rust, so two independent languages agree byte for byte.

The CoreSeal signing step: 46,696 signatures/sec, about 0.022 ms each (median of an 8-run local bench suite on commit f002cf2; local hardware, no network round trips).

Method and limits on Proof