Nihilium
Trigger Partials Recovery Where work lives
Deep dive · Protocol

Unsealing

Recovery announces itself, gathers partial decryptions from a quorum, and rebuilds the secret entirely on the client's own machine.

Processors only ever verify a proof and return curve points. They never see the payload, and they cannot open it themselves.

Step 1 · Announce and prove

Every recovery starts in the open.

The client picks one qualifying group of k processors, posts a reveal value to the datastream, and assembles the proofs its conditions demand. Posting first is what makes the attempt publicly observable before anything is decrypted.

1
Pick a path
Choose one qualifying k-subset from the sealed processors.
2
Post the reveal
Insert the reveal value into the datastream. The attempt is now on the record.
3
Prove the conditions
Generate the chained proof. Instant for a timelock, longer for an identity check.
Step 2 · Collect partials

Each processor validates, then returns curve points.

The k interactions run in parallel and independently. A processor pulls the condition bytecode from the registry, runs the chained proof, and only on success multiplies the ciphertext ephemerals by its private key. The result is a partial decryption: an EC point, never a scalar, so no processor ever solves a discrete log.

Chained prooffrom client
Validate against registrypull bytecode, run in order
Partial decryptionan EC point
Two bundles each
Because of the closed loop, every processor serves partials on its own bundle and on its predecessor's. That mutual dependency is what forces cooperation.
Attributable
Each partial is provably tied to that processor's registered key. If one ever appears outside a valid recovery, it is slashing evidence.
Refusal is not free
Declining a valid request is forced on-chain. Serving a valid proof, on the other hand, makes the processor immune to challenges for that recovery.
Step 3 · Rebuild locally

The client does the rest alone.

With the partials in hand, the client strips the composite layers, recovers the hidden scalars, finds the one correct path, and decrypts. All of it happens client-side, where only the legitimate client benefits from doing the work.

A
Strip layers
Subtract the three partials (processor, successor, client) from each ciphertext to expose a scalar as a curve point.
B
Recover scalars
Solve each short discrete log locally with a precomputed table, roughly two milliseconds per chunk.
C
Find the path
Trial-decrypt to locate the one correct combination of lanes. Embarrassingly parallel across cores.
D
Decrypt
Rebuild the vault key, recover the indirection value, and open the payload and anything appended to it.
The search is the barrier. That local path search is cheap for the real client but must run inside an expensive joint computation for any colluding quorum. The asymmetry is what makes silent collusion irrational.
The division of labour

Each side does only what it is best placed to do.

Processors stay light and auditable. The client carries the heavy recovery math, because it is the only party that should want to.

Processor
Validate the chained proof
Multiply ephemerals by its key
Return curve points, sub-second
Client
Strip composite layers
Recover scalars, search the path
Decrypt the payload
Recovery is loud, cooperative, and provable at every step, and the secret only ever reassembles on the client's own machine.
Overview Conditions Sealing Unsealing Threshold Properties Primitives SDK