Not an official Besu projectTested against real drand quicknet

Seal it. Nobody reads it early -- not even you, not a custodian, not me.

NexEth encrypts a payload so it can only be opened at or after a moment you choose. Release is gated by a real drand threshold signature, verified on chain via the EIP-2537 BLS12-381 precompiles, against a public key pinned at deployment. The contract trusts a pairing check -- nothing and no one else.

See how it worksReal terminal output
9f3a··c02e··71b4··e5f0
1. Message

A payload, in the clear. Any file.

Architecture

Three small pieces. The chain enforces the one that matters.

The registry stores hashes and gates a boolean. The verifier checks a pairing equation. Everything else -- encryption, key sealing, watching for rounds -- happens off chain, because none of it needs to be trusted.

On chain -- BeaconVerifier.sol
Verifies the drand signature itself

submitRound(round, signature) hashes the round to G1 (RFC 9380), then runs the EIP-2537 pairing check on chain. Permissionless and idempotent -- anyone can submit, a repeat submission just returns early. 482,068 gas, measured on a live devnet.

On chain -- TimelockRegistry.sol
Records the lock, gates the release

createLock stores a ciphertext hash, target round, and owner -- never a secret. markReleased checks BeaconVerifier.isRoundVerified(round) and nothing else. No caller-supplied round, so one lock can't be released by another lock's evidence.

Off chain -- CLI + relayer
Seals, unseals, and submits rounds

The CLI hybrid-encrypts with tlock-js and registers the lock. unseal checks on-chain state before ever contacting drand. The relayer watches LockCreated events and submits rounds unattended -- or you can always submit one yourself.

e(signature, G2) == e(H(round), pubkey)
The entire trust model, in one pairing check. If it holds, the threshold beacon really did sign this round -- there is no other way to satisfy it.
Status

Working prototype. Every number below is measured, not projected.

Run for real against a live 4-validator Besu QBFT devnet and the real drand quicknet network -- not simulated, not mocked, including a full end-to-end demo. See the worked example below for the actual run, verbatim.

103,575
gas -- bare EIP-2537 pairing check
482,068
gas -- full drand signature verification
98,105
gas -- createLock
37,093
gas -- markReleased
Phase 0
Local QBFT devnet, Prague-activated
done
Phase 1
EIP-2537 precompile spike + gas measurement
done
Phase 2
BeaconVerifier.sol -- on-chain drand signature verification
done
Phase 3
TimelockRegistry.sol -- lock/release registry
done
Phase 4
CLI (seal / unseal / submit-round / status)
done
Phase 4
Relayer -- unattended round submission
done
Phase e2e
End-to-end demo -- 4-validator QBFT Besu + real drand quicknet, on GitHub
done
Worked example

A real run. Nothing here is staged.

Copied verbatim from an actual terminal, against the live devnet, with nexeth-relayer running unattended in the background. Click through the steps.

Any file, on disk
$ echo "Board meeting minutes unlock at 15:00 UTC." > payload.txt
$ cat payload.txt
Board meeting minutes unlock at 15:00 UTC.
Why this exists

There's no such thing as timed-release encryption with zero trust. The real question is what kind of trust to accept.

Some schemes try to lock a message using a math puzzle that simply takes time to solve, no key required. It sounds trustless, but it isn't: better hardware solves the puzzle faster than expected, and a future quantum computer breaks the puzzle outright. Either way, you're quietly trusting that nobody out there has hardware you didn't plan for. Every timed-release scheme ends up trusting something.

Drand (pronounced “dee-rand,” short for distributed randomness) makes that trust visible instead of hidden through its threshold beacon. It publishes a fresh, publicly verifiable value every few seconds, and producing each one takes a known group of operators combining their pieces of a shared key -- no single operator can make one alone, and no single one can block one either. That is a very different bet than a stranger's unverifiable hardware. It isn't immune to future quantum computers either -- but if it's ever broken, everyone can see who was responsible. A silent hardware edge never tells you when it happened.

On a permissioned consortium chain, that trust is usually already in place: the people running the network are already known and already bound by contract, for reasons that have nothing to do with this. This prototype exists to show that actually works, not just that it should.

  • Agreed clockEvery node agrees on the block timestamp. “The time has come” is something the network confirms together -- not a claim made by whoever happens to run a service.
  • Immutable audit trailWhen a lock is created and when it's released are both written on chain, along with a hash of the sealed content -- anyone can check the record later.
  • An enforcement pointA smart contract checks the beacon's signature itself. Whoever submits it is just a messenger, not an authority -- they can hold a message back, but they can't fake it, backdate it, or release it early.
Scope

Explicitly out of scope

Not built (yet)

  • An HTTP API or authentication layer
  • Persistence beyond what the demo needs
  • A consumer callback pattern
  • Key rotation
  • Any threshold committee of our own
  • Production version (no demo)

Non-negotiable

  • No code path releases a lock without a verified on-chain signature
  • No plaintext or key material ever touches chain state
  • No secret ever appears in a log or error message
  • These hold regardless of flags -- there is no override

Interested in any of the above? Propose it on GitHub -- issues and pull requests are welcome.