THRESHOLD BLSDISTRIBUTED KEY GENx/beacon

UNBIASABLE
ENTROPY.

Fairness starts with the seed. Exohash uses a distributed beacon to generate randomness that no single validator can predict or manipulate.

ALGORITHM

BLS-12-381

Standard pairing-friendly curve for threshold signatures.

LATENCY

~1 Block

Randomness is revealed and verified in the commit phase.

SECURITY

T of N

Requires collusion of >67% of validators to halt (but cannot bias).

The beacon operates in rounds. Validators produce partial signatures that are aggregated into a final, verifiable random seed.

BLOCK #84920

PROPOSE

Proposer Selected

Validator 0x7a... proposes block
+ DKG share

CONSENSUS_PROCESS

1. Propose (New Block)

The proposer includes their "Partial Signature" share in the block header. This is the first piece of the randomness puzzle.

2. Vote (Precommit)

Other validators verify the block. To vote "Yes", they MUST also sign the randomness share using their BLS secret key.

3. Commit (Aggregation)

Once +2/3 votes are collected, the signature is mathematically aggregated into the final Random Seed. It is now unchangeable and public.

Mechanism

The Distributed Beacon.

Why this is safer than a block hash or a centralized oracle.

1. Distributed Key Generation (DKG)

Before the network starts, validators participate in a DKG ceremony. They collectively create a Master Public Key. No single node ever knows the Master Private Key.

2. Partial Signatures

For each block round, every validator signs the Round ID using their private key share. This produces a 'partial signature' which they broadcast to the network.

3. Aggregation & Verification

Once the threshold (T) of partial signatures is collected, they are mathematically combined into a single Group Signature. This signature is the random seed. It can be verified against the Master Public Key.

The "Unbiasable" Guarantee

Cannot be predicted: The output is deterministic ONLY if you have T private keys. No single node can know the output in advance.

Cannot be manipulated: A validator cannot "try" different signatures to get a lucky result. There is only one valid signature per round.

Liveness: Even if some nodes go offline, the beacon continues as long as T nodes (67%) are active.

Comparison

Why not just use Block Hash?

Block hashes are manipulatable by miners (grinding). VRFs are good but often centralized or slow. Exohash builds the beacon into the consensus layer.

Block Hash

Miners can discard blocks that result in "bad luck" for them (e.g. they lose a bet). This is called "Block Withholding" or "Grinding".

Unsafe for High Value

External Oracle (VRF)

Chainlink VRF is excellent but introduces an async delay (request -&gt wait -&gt callback) and external dependency costs.

Good, but Async

Exohash Beacon

Randomness is produced by the validator set itself during block construction. It is synchronous and native.

Fast & Native

Navigate the Architecture.

RANDOMNESS HOUSE ENGINES ECONOMICS

System Status: Devnet Active