Verifiable Delay Function (VDF)

A Verifiable Delay Function (VDF) is a cryptographic tool designed to produce a result that takes a specific amount of time to compute, even with significant computational resources, but can be quickly and easily verified by others. This characteristic makes VDFs particularly useful in scenarios where it's important to ensure that a certain amount of time has passed before a result is known, while still allowing for rapid verification.​

💡 How Our VDF-Based Randomness Works

To ensure fairness in our games, we use a Verifiable Delay Function (VDF) combined with the blockhash of the transaction’s block to generate randomness that is:

• Unpredictable before the bet

• Unmanipulable by the user or the house

• Publicly verifiable by anyone

🔐 Why Not Just Use Random Numbers?

Traditional randomness methods can be gamed:

• The user could precompute outcomes if they know the randomness algorithm

• The house could bias results if it controls the random seed

We solve this using cryptographic guarantees, not trust.

🧠 What is a VDF?

A Verifiable Delay Function (VDF) is a cryptographic function that:

• Takes a fixed amount of time to compute, no matter how much hardware is thrown at it

• Returns a result that is fast to verify, even on-chain

• Can only be computed once the input is known, so no precomputation is possible

Think of it like a tamper-proof hourglass for randomness: once started, the output can only appear after a delay, and everyone can confirm it’s legit.

🧪 Our Randomness Source

1. User places a bet, which is included in block N

2. After confirmation, we extract the blockhash of block N. block_hash = blockhash(N)

3. We construct a unique input using: input = keccak256(user_address || stake_amount || block_hash)

4. We compute: output = VDF(input) proof = VDF_proof(input, output)

5. We use the output to generate a hash consistent with a blockhash and pass this back to the on-chain contract to use as a result source.

✅ Why This Is Fair

• The blockhash isn’t known until after the bet is mined — so no one can predict or manipulate it ahead of time

• The VDF forces a minimum delay between input and output

• The output and proof are public, so anyone can verify the fairness

🚫 Why We Don't Use Chainlink VRF

While Chainlink VRF is a popular solution for on-chain randomness, we chose not to use it due to the following concerns:

Concern	Chainlink VRF Limitation
Dependency on third-party oracle	Requires trusting Chainlink nodes to return the randomness
Cost	Each request incurs high gas and LINK token costs
Latency	Responses are asynchronous and can take several blocks
Opacity	Users cannot verify how long the oracle took to respond
Decentralization tradeoff	Although decentralized at the network level, randomness comes from a single node at runtime

By contrast, our VDF-based system:

• Is fully deterministic and trustless

• Doesn’t rely on any third-party service or token

• Is instantly auditable and reproducible by anyone

• Guarantees delay and transparency, without external dependencies

---

We believe this approach offers maximum transparency, fairness, and cryptographic integrity, without introducing the risks and costs of external oracles.

Why We Use RSA-2048 and Wesolowski Proofs (the technical bit)

We use an RSA group with unknown factorization—specifically, the well-known RSA-2048 challenge modulus—to ensure that the Verifiable Delay Function (VDF) cannot be parallelized or shortcut. The security of this approach relies on the mathematical difficulty of factoring large semiprime numbers, a widely trusted cryptographic assumption. To make the result quickly verifiable without repeating the expensive computation, we generate a Wesolowski proof, which allows anyone to validate the VDF output in constant time. This combination ensures both guaranteed computational delay and fast, trustless verification, making it ideal for provably fair randomness generation in decentralized applications. Read more on RSA modulus and the RSA Factoring Challenge