← Nihilium
Problem Idea Use cases Actors Mechanism Security
Technical overview

Nihilium

Every threshold recovery system shares one blind spot: operators can quietly collude to rebuild your secret, and nobody can prove it happened. Nihilium closes silent collusion.

Lock a secret behind any condition, recover it only when those conditions are met, and make every attempt to cheat leave permanent, provable evidence.

Start reading See how it works
The core problem

Silent collusion is the hole every recovery system leaves open.

If a quorum of operators cooperates off the record, they reconstruct a secret with zero evidence, no forensics, no accountability. Todays options each fail this test in a different way.

Perspective 1
Custodial recovery
Convenient, but your access depends on one counterparty staying alive, cooperative, and free from coercion. Trust a company, forever.
Perspective 2
Non-custodial recovery
Write down a seed phrase and hope it survives. Real self-custody, but it demands perfect operational security from people who are not security professionals.
Perspective 3
Threshold / MPC systems
Split the key across k of n operators. Strong in theory, but if those operators collude they rebuild the key with no on-chain evidence and no consequences.
Nihilium keeps the threshold guarantees of the third option and adds the one thing it lacks: collusion that cannot stay silent.
The idea

A sealed payload becomes recoverable the moment its conditions come true.

Proof-of-life lapse, time elapsed, an identity check, a multi-party sign-off, or any rule you can express as a smart contract, including zero-knowledge proofs. The client proves the conditions; independent processors validate the proof and release the key. Nobody holds your secret hostage.

No custodian
Your ability to recover never depends on one company staying alive, cooperative, or uncoerced.
No ceremony
No setup ritual between operators. Pick your own cohort of processors, per seal, on your own terms.
Conditional by design
The rule set is open. Any verifier compiled to bytecode can gate a seal, including conditions nobody has imagined yet.
What it can do

Conditional recovery, at consumer scale.

Built for the cases where the alternative today is usually no recovery at all.

Wallet key recovery
Forgot your seed? Prove your email or passport identity and unseal the password that decrypts it, no custodial reset.
Emergency access to medical data
The moment you most need clinicians in your records is often the moment you cannot grant access yourself. Seal it behind an emergency condition so care teams get in exactly when it counts.
Dead-man switch & inheritance
Release only if a revocation signal lapses. Append updated records over time, a living estate vault opened just once.
Compliance break-glass
Access gated by cryptography, not policy: k-of-n sign-off, no legal hold, a time delay, every attempt on-chain.
Provable non-access
A regulator or investigator keeps a credible access path, and because every attempt is auditable, the data owner can prove that no access has ever occurred.
Key exchange, without prior keys
Encrypt to provable conditions instead of a known public key. You can seal something for a recipient defined by a rule, not by a cryptographic key you had to obtain up front.
The cast

Four actors, one clean separation.

The client proves. The processor validates. The datastream makes it auditable. The chain keeps everyone honest.

Holds the secret
Client
Defines the conditions, generates every proof, seals and unseals. All the cryptographic heavy lifting lives here.
Stakes & validates
Processor
Independent, stateless operators. They check the proof and release a partial key, never coordinating with each other.
Anchors & proves
Datastream
Anchors the data and posts a public marker for every unsealing attempt before decryption. This is what makes access auditable: anyone can see an attempt happen, or prove one never has.
Keeps everyone honest
Blockchain
Registration, slashing, forced execution. The enforcement layer that turns provable evidence into consequences, keeping every party honest.
The mechanism

How a Nihilium seal works.

Four moving parts, built from the same set of pieces. Step through them.

{{ tab.label }}
Client
Public key
Hiddenprivate key
Conditions
Commitment
Processor
Client
Public key
Hiddenprivate key
Conditions
Commitment
Processor
Client
Public key
Hiddenprivate key
Conditions
Commitment
Processor
Client
Public key
Hiddenprivate key
Conditions
Commitment
Processor
3 / 5
{{ stepTitle }}
{{ stepBlurb }}
Timelocks Expirations Signatures ZK proofs Composed paths
Identity proof AND Timelock OR 3 of 5 sign-off
Extendable without protocol updates
If the hidden key surfaces before conditions are met, the commitment slashes the processor's entire stake.
{{ stepLabel }}
The enforcement layer

Cryptography makes cheating provable. Economics makes it costly.

A processor's stake is reputation capital across every seal it has ever committed to. One provable slip forfeits all of it, permanently.

Detection
Any key material that leaks outside a valid unsealing is cryptographically traceable to the exact operator that produced it.
Punishment
Attribution triggers permissionless on-chain slashing. Anyone who spots the leak can start the challenge.
Enforcement
Refusing a valid request is forced on-chain, the same slashing offence as leaking early. There is no quiet way out.
Cheat and lose everything. Refuse to serve and lose everything. Whatever prevents collusion is the same force that compels an answer.
Overview Conditions Sealing Unsealing Threshold Properties Primitives SDK