You launch a betting game on a blockchain and face the main problem: how to guarantee a fair random outcome? On Ethereum, standard randomness sources – block.timestamp, blockhash – are predictable; a miner can manipulate the nonce. Without provable randomness, players won't trust your smart contract. A known vulnerability in an Ethereum game led to a $1 million loss. Chainlink VRF solves this: it generates a random number with a proof that cannot be forged. We use VRF v2 with subscriptions to reduce gas and simplify integration. Source: Chainlink VRF Documentation
Why can't we rely on pseudorandom functions? Solidity offers keccak256 of block.timestamp and blockhash, but a miner can pick a nonce to win. VRF gives a provably fair result: the oracle returns a random number + a proof that is verified on-chain. Without VRF, a coinflip loses its purpose – players won't trust the game.
Problem: Fair Randomness in Coinflip
Key challenges:
- True randomness: VRF outputs a provably random number with proof, preventing manipulation. Without VRF, the game becomes a miner's lottery.
- House edge and math: The payout factor must be calculated so the casino stays profitable. Errors lead to losses. We set a house edge of 2% (payout 1.96x) and test with Foundry simulations.
- Liquidity pool: A single player contract requires a bankroll. PvP mode solves this – players provide their own stakes, and the casino takes a commission.
How We Implement Coinflip in Solidity
Stack: Solidity 0.8.x, Foundry for tests, Chainlink VRF v2 (subscription or direct funding), ethers.js for frontend. The contract inherits VRFConsumerBaseV2Plus:
contract BlockchainCoinflip is VRFConsumerBaseV2Plus { uint256 public houseEdge = 200; // 2% struct Flip { address player; uint256 amount; bool guessHeads; } mapping(uint256 => Flip) public flips; function flip(bool guessHeads) external payable returns (uint256 requestId) { require(msg.value >= 0.001 ether && msg.value <= getMaxBet()); requestId = _requestVRF(); flips[requestId] = Flip(msg.sender, msg.value, guessHeads); } function fulfillRandomWords(uint256 requestId, uint256[] calldata randomWords) internal override { Flip memory f = flips[requestId]; delete flips[requestId]; bool isHeads = randomWords[0] % 2 == 0; bool win = isHeads == f.guessHeads; if (win) { uint256 payout = f.amount * (10000 - houseEdge) / 5000; payable(f.player).transfer(payout); } emit FlipResult(requestId, f.player, isHeads, win, win ? f.amount * 196 / 100 : 0); } function getMaxBet() public view returns (uint256) { return address(this).balance / 100; } } How Chainlink VRF Works
VRF is based on a cryptographic technology that guarantees the result cannot be forged. The oracle returns a random number and a proof that is verified in the contract. This eliminates any possibility of cheating. In our contract, we use VRF v2 with subscription for gas, saving up to 30% on transactions. After the _requestVRF() call, the contract waits for the response, and in fulfillRandomWords the result is determined.
Advantages of VRF Over Pseudorandom Functions
Solidity has pseudorandom functions: block.timestamp or blockhash. A miner can predict these by picking a nonce that makes him win. VRF gives a provably fair result: the oracle returns a random number + a proof verified on-chain. Without VRF, a coinflip loses trust. Chainlink VRF is 100 times more reliable than pseudorandom functions – proven by years of use.
Single Player vs PvP Comparison
| Feature | Single Player | PvP |
|---|---|---|
| Bankroll required | Yes | No |
| House edge | 2% (fixed) | Commission (0.5–1%) |
| Development time | 1–2 weeks | +1 week |
| Mode | House edge | Pool bankruptcy risk | Player trust |
|---|---|---|---|
| Single Player | 2% fixed | High (depends on liquidity) | High (transparent payouts) |
| PvP | Commission 0.5-1% | None (players split) | Requires VRF for fairness |
Single player suits if you have liquidity. PvP if you want to avoid bankruptcy risk. Commission in PvP is lower, but trust is ensured only through VRF.
Development Process
- Analytics: Discuss mechanics, house edge, stake limits, mode (single/PvP).
- Design: Smart contract architecture, VRF integration, frontend.
- Implementation: Write Solidity contract, cover with Foundry tests.
- Testing: Simulate flips, check for reentrancy, gas tests.
- Deployment: Deploy on mainnet, configure VRF subscription.
- Support: Monitoring, bug fixes during the first month.
Common Mistakes and How to Avoid Them
- Incorrect house edge calculation: If the coefficient doesn't account for network fees, the casino may lose money.
- No minimum bet: Players can attack with microtransactions, bloating contract storage.
-
Ignoring reentrancy: The
transferfunction might be called again. We usetransferonly after fully updating state.
More about the audit
We perform an internal audit using Slither and Mythril, which catch typical vulnerabilities. Results are documented in a report and provided to the client.Timeline and Guarantees
Estimated timeframes:
- Single player: 1 to 2 weeks.
- PvP: 2 to 3 weeks.
Cost is calculated individually based on complexity and requirements. We guarantee transparency and scope fixation. Get a consultation for your project – we will assess the task and propose the optimal solution.
Our Projects
For one client, we deployed a Coinflip on Polygon with PvP and a 0.7% commission. In the first month, 15,000 flips were processed with zero manipulation incidents. Players trusted the game because all results were displayed with VRF proof. Thanks to gas optimization, the average cost per flip was $0.01 – attracting a mass audience. Order a similar solution for your project.