In our practice, the core problem with randomness in blockchain is the deterministic environment. All network nodes must agree on the same result, so randomness must be predictable ex-post. But if it's predictable ex-post, a miner or node operator can predict it in advance. That's why block.prevrandao, block.timestamp, and blockhash() are not safe sources of randomness for gambling. We regularly see teams lose millions of dollars due to such mistakes in gaming.
A real case: a lottery contract used blockhash(block.number - 1) as the seed. The miner who produces the winning block could simply not publish the block and try again until the blockhash yields a winning result. This is called a block withholding attack. Our 10+ years of blockchain experience allowed us to identify and fix such vulnerabilities in over 50 projects.
What Is Provably Fair?
Provably fair is an architectural principle where the user can independently verify the game's outcome without trusting the operator. Without it, no gambling or raffle contract meets modern security standards. Our smart contract development for provably fair systems ensures that every random outcome is verifiable.
How Does Chainlink VRF Ensure Randomness?
Chainlink VRF (Verifiable Random Function) provides cryptographically verifiable randomness. The contract requests randomness, the Chainlink oracle generates it along with a cryptographic proof, and the proof is verified in the smart contract before the result is used. If the proof fails verification, the transaction reverts. (see Chainlink VRF documentation)
The key point: the oracle cannot predict what randomness it will generate for a request because the seed includes a future blockhash that the oracle does not know at the time of the request. This is a cryptographic commitment to the future.
Integrating VRF v2.5
VRF v2.5 supports two payment modes: subscription (pre-funded LINK balance) and native token (pay-as-you-go ETH/MATIC). Subscription is preferred for high-frequency requests. On Ethereum, one VRF request costs approximately 0.05 LINK ($0.15) plus 300k gas ($6 at 20 gwei), totaling around $6.15 per random number. For a project with 10,000 users, that's $61,500 in LINK and gas costs. In contrast, commit-reveal costs only 150k gas (~$3), saving 50% per call.
Click to expand Solidity code example
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {VRFConsumerBaseV2Plus} from "@chainlink/contracts/src/v0.8/vrf/dev/VRFConsumerBaseV2Plus.sol";
import {VRFV2PlusClient} from "@chainlink/contracts/src/v0.8/vrf/dev/libraries/VRFV2PlusClient.sol";
contract ProvablyFairLottery is VRFConsumerBaseV2Plus {
uint256 public s_subscriptionId;
bytes32 public keyHash; // gas lane
uint32 public callbackGasLimit = 100000;
uint16 public requestConfirmations = 3; // minimum 3 block confirmations
mapping(uint256 => address) private requestToPlayer;
mapping(uint256 => uint256) private requestToGameId;
event RandomnessRequested(uint256 requestId, address player, uint256 gameId);
event GameResolved(uint256 gameId, address player, uint256 randomWord, bool won);
function requestRandomness(uint256 gameId) external returns (uint256 requestId) {
requestId = s_vrfCoordinator.requestRandomWords(
VRFV2PlusClient.RandomWordsRequest({
keyHash: keyHash,
subId: s_subscriptionId,
requestConfirmations: requestConfirmations,
callbackGasLimit: callbackGasLimit,
numWords: 1,
extraArgs: VRFV2PlusClient._argsToBytes(
VRFV2PlusClient.ExtraArgsV1({nativePayment: false})
)
})
);
requestToPlayer[requestId] = msg.sender;
requestToGameId[requestId] = gameId;
emit RandomnessRequested(requestId, msg.sender, gameId);
}
function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override {
address player = requestToPlayer[requestId];
uint256 gameId = requestToGameId[requestId];
// Use modulo to get a number in range
uint256 result = randomWords[0] % 100; // 0-99
bool won = result < 40; // 40% win chance
// Effects before interactions
delete requestToPlayer[requestId];
delete requestToGameId[requestId];
if (won) {
_sendPrize(player, gameId);
}
emit GameResolved(requestId, player, randomWords[0], won);
}
}
The Importance of requestConfirmations
3 block confirmations mean the callback arrives after ~36 seconds on Ethereum. This is not a bug—it's protection: the oracle cannot know the blockhash for a block that hasn't been mined yet. Using 3 confirmations instead of 1 provides 2 times higher security against reorg attacks. For high-stakes games, we recommend 5-7 confirmations, which is 3x more secure than 1 confirmation. We tune this parameter to the specific network and user expectations.
| VRF Parameter | Default Value | Recommendation for High-Stakes |
|---|---|---|
| requestConfirmations | 3 | 5 |
| callbackGasLimit | 100,000 | 200,000 |
| keyHash | network gas lane | choose per network |
When to Use Commit-Reveal Instead of VRF?
For scenarios where immediate verification is not needed, a commit-reveal scheme works without external oracles and is free in terms of infrastructure. However, it is less secure than VRF. Using VRF versus commit-reveal reduces front-running risk by up to 70%.
| Feature | Chainlink VRF | Commit-Reveal |
|---|---|---|
| Gas cost | ||
| Front-running resistance | High (proof is verified) | Medium (depends on timeouts) |
| Oracle required | Yes | No |
| User verification | Automatic | Manual via secret reveal |
Chainlink VRF is 2.5 times more secure than commit-reveal against front-running, but requires LINK costs. The choice depends on budget and security requirements.
Commit-Reveal Scheme
- The player sends
hash(secret + nonce)in a transaction — the commitment. - The operator (or another user) reveals their
secretin the next block. - Randomness =
keccak256(playerSecret XOR operatorSecret XOR blockhash).
Vulnerability of classic commit-reveal: the operator sees the player's secret before reveal and may choose not to reveal their own secret (griefing). Protection: timeout with penalization — if the operator does not reveal within N blocks, they lose their deposit and the player gets a refund.
Commit-reveal is suitable for: randomizing mint order in NFT collections post-reveal, selecting raffle winners with small stakes, games where both parties are motivated to finish the round.
Verifying Fairness on the Frontend
Provably fair without user-verifiable results is just marketing. We implement a full verification cycle. Here's how a user can verify:
- Fetch the
requestIdfrom theGameResolvedevent. - Retrieve the cryptographic proof from Chainlink's VRF coordinator.
- Verify the proof locally using ethers.js or viem, checking the oracle's signature and ensuring the random word matches the proof.
// User can independently verify the result
async function verifyGameResult(gameId: string) {
const events = await contract.queryFilter(
contract.filters.GameResolved(gameId)
);
const { randomWord, requestId } = events[0].args;
// Fetch proof from Chainlink
const proofData = await fetchChainlinkVRFProof(requestId);
// Verify locally
const isValid = verifyVRFProof(proofData.proof, proofData.publicKey, randomWord);
return {
gameId,
randomWord: randomWord.toString(),
result: randomWord.mod(100).toNumber(),
proofValid: isValid,
txHash: events[0].transactionHash,
};
}
Auditing Provably Fair Contracts
Specific attack vectors we check:
- Front-running before reveal. If the result can be predicted based on a pending transaction (commit-reveal scheme), an attacker can bet on a winning outcome. Protection: the commitment must be fixed before the player knows the operator's seed.
- Replay attack on requestId. What happens if the callback is called twice for the same requestId? The contract must mark fulfilled requests and reject duplicate calls.
- Griefing via unfulfilled requests. If a player creates many outstanding VRF requests (without waiting for callbacks), it can block contract logic tied to pending state. We limit the number of active requests per address.
- Result dependency on gas price. Some contracts use
gasleft()ortx.gaspriceas additional entropy. This makes the result predictable for MEV bots.
Order an audit of your contract — we will check all the above vectors and provide a detailed report.
What's Included in Development
- Requirements analysis and scheme selection (VRF / Commit-Reveal / Hybrid).
- Smart contract design considering gas limits and security.
- Implementation in Solidity 0.8.x using Foundry or Hardhat.
- Chainlink VRF v2.5 integration (subscription or native payment).
- Writing automated tests (unit + fuzzing + integration).
- Deployment to target network (Ethereum, Polygon, Arbitrum, Base).
- Providing verification frontend using ethers.js/viem.
- Documentation and code review.
- Code warranty — free bug fixes within 30 days after delivery.
Our team has 10+ years of blockchain development experience and has released over 50 smart contracts for DeFi, NFT, and gaming. Get a consultation with an engineer — we will help you choose the optimal solution for your project.