On-chain Randomness · on KUB

Randomness your contracts can prove.

Verifiable randomness for onchain games and finance on KUB. Provably fair, ownerless, and adversarially reviewed: every result is recomputable from public chain data. No oracle, no VRF service, no trusted operator.

Try a live draw How it works

Two blocks. One number
nobody could predict.

Randomness comes from the hash of a future block, unknown to everyone (including the caller) at commit time. Settlement is permissionless and stays entirely on-chain.

01 / Commit
request(seed)
Your contract reserves the next block and receives a request id. Funds and intent are committed at this step.
02 / Sealed
blockhash(B+1)
The seeding block is mined. Its hash was unknowable at commit time, which is the source of entropy.
03 / Reveal
reveal(id)
Anyone can settle. It returns keccak(blockhash, id, caller, seed): fixed, recomputable, and fair.
✓

Atomic grinding is impossible. Because reveal reverts until the next block is mined, an attacker cannot compute the result and revert on a loss inside one transaction. The most common on-chain gambling exploit is closed by construction.

Built to be trusted,
and to be checked.

A primitive that handles value should never overclaim, so we document exactly what it defends and what it does not. It has been tested and adversarially reviewed across multiple passes, with zero confirmed vulnerabilities so far. A formal third-party audit is still pending.

✓
Ownerless & immutable
No admin keys, no upgrade path, no pause. Nobody can change or stop it once deployed.
✓
Atomic-grind proof
Request and reveal cannot share a transaction, so the revert-on-loss attack never reaches the outcome.
✓
Provably fair
Each result is keccak(blockhash, id, caller, seed). Recompute it from public chain data and confirm it was never touched.
✓
Verified & reviewed
Source verified on KUBScan; 15/15 tests plus a multi-agent adversarial review, with zero confirmed vulnerabilities. A formal third-party audit is pending.
!
Cap your value
A block producer can bias a single block, the irreducible limit without a real VRF. The honest mitigation is economic: cap per-round and aggregate value.

Two calls.
The whole integration.

No package to install on-chain. Import one interface, point at the canonical address, and call two functions. Read the full integration guide, with ABI and frontend snippets →

GigaKingMint.sol
// the deployed, verified DurianEntropy on KUB (chainId 96)
IDurianEntropy constant entropy = IDurianEntropy(0xf2DF5c645d84Deb994979d07C0b02410D718754E);

// commit: take payment, reserve a future-block roll
function commitMint() external payable {
    require(msg.value == PRICE);
    pending[msg.sender] = entropy.request(bytes32(uint256(uint160(msg.sender))));
}

// reveal: permissionless, mints to the user, no re-roll possible
function claimMint(address user) external {
    uint256 r = entropy.reveal(pending[user]);
    delete pending[user];
    _mint(user, pickTier(r));   // grind-proof: payment already committed
}
Lottery, 6 digits from one reveal
uint256 r = entropy.reveal(drawId);
uint256 winning = r.digits(6);  // 482917
Roulette, one pocket
uint256 r = entropy.reveal(spinId);
uint8 pocket = uint8(r.pick(0, 37));  // 0 to 36

Function reference

request(bytes32 seed) → uint256 idcommit; the id comes back on the Requested event
reveal(uint256 id) → uint256settle once the reveal block is mined; returns the randomness (permissionless, idempotent)
status(uint256 id) → uint80 NONE · 1 WAITING · 2 READY · 3 EXPIRED · 4 FULFILLED
results(uint256 id) → uint256the stored randomness (0 until revealed)
requests(uint256 id)requester, revealBlock, fulfilled, seed — for off-chain recompute
Download the full guide (.md) ↓ Open in browser ↗

One primitive, every game.

Derive as many independent values as you need from a single reveal with the MIT helper library. Each demo draw below commits and then waits for a real future block to seal, so it can't be rushed.

Coin flip
Heads or tails for keeps. Stake escrows on commit, settles a block later.
r & 1 == 0 ? HEADS : TAILS
—
Lottery
One draw, one number, everyone checks the same fair result.
r.digits(6)
—
Roulette
European single-zero, fair pocket, no keeper bot required.
r.pick(0, 37)
—
NFT tiers
Random rarity on mint, grind-proof when you commit first.
r.pick(0, weights)
—

How good is the randomness?

Every value is keccak256 of a real, unpredictable KUB block hash, so the output is uniformly distributed and nothing the caller controls can bias it. Pick any game and run it hundreds of times from a single block, then watch the distribution level out. The one caveat is economic, not statistical: a block producer can bias a single block, so cap per-round value.

Pick a game, then run 600 draws from one future block.

Draw a number,
live on KUB.

Connect a wallet and the draw runs the live DurianEntropy contract for real: request() then reveal(), two transactions, about 0.003 KUB. No wallet? Run a gasless read-only preview that reads the same block entropy.

network KUB Chain · chainId 96
contract0xf2DF…754E ↗ · live & ownerless
entropyhash of a real future block
DURIAN ENTROPY · LIVE DRAW
0
0
0
0
Connect a wallet to draw on-chain.

The details, in full.

Network
KUB Chain · chainId 96
Contract
DurianEntropy, ownerless, immutable, ~95 lines
Address
0xf2DF5c645d84Deb994979d07C0b02410D718754E ↗
Deploy tx
0x8809…8eaf ↗ · block 32,878,724
Source
Verified on KUBScan ✓ ↗ · read the exact Solidity, call it from the Read/Write tab
Interface
request(bytes32) · reveal(uint256) · status(uint256)
Entropy
keccak(blockhash, id, caller, seed)
Settlement
Permissionless, idempotent, 256-block reveal window
Cost
~0.0096 KUB deploy, ~0.0027 KUB per draw (caller pays)
Compiler
solc 0.8.24 · optimizer 200 · evm paris
Assurance
15/15 tests, multi-agent adversarial review, 0 confirmed vulnerabilities
Third-party audit
Pending (not yet audited by an external firm)
License
Source-available, free to use, core © Durian

Questions, answered
without spin.

Is this a VRF? +
No, and we never call it one. Durian Entropy is blockhash-based commit-reveal randomness, not a cryptographic Verifiable Random Function. It is grind-proof against ordinary users and contracts. The one residual trust assumption, a block producer biasing a single block, is disclosed openly and mitigated with value caps.
Is it safe to use with real value? +
Yes, for the vast majority of on-chain games and randomized mints, when you follow the documented value caps. Atomic grinding is impossible by construction. Very high-stakes outcomes would want a real VRF, and none exists on KUB today, which is exactly why this exists.
Who can use it, and what does it cost? +
Anyone. Any contract or app may call the canonical deployment freely, with no fee and no permission gate. The caller pays gas, roughly 0.0027 KUB for a full request and reveal.
Has it been audited? +
It passes 15/15 tests and a multi-agent adversarial review that returned zero confirmed vulnerabilities, and every result is recomputable on-chain so anyone can verify it. A formal third-party audit is planned but not yet complete, and we will not claim one until it is.
What if no one reveals in time? +
Each request has a 256-block reveal window. Consuming contracts must treat expiry as a forfeit for the requester, never a refund-and-re-roll, which removes any incentive to induce expiry. The reference consumer demonstrates the safe pattern.

The randomness layer for onchain finance on KUB.

Open the SDK reference → Download the guide (.md) ↓ View on KUBScan ↗
↓ Guide.md