Search projects, hackathons, sponsors and tech

    ← All projects

    Demo

    About

    The problem it solves In traditional online betting platforms, users face several issues: -Lack of transparency – Users have to trust centralized operators who control the odds, outcomes, and funds. -Custodial risk – Funds are stored off-chain by third parties who can mismanage, freeze, or lose them. -Unverifiable outcomes – Game results and randomness are often hidden from public scrutiny. -Slow settlement – Winnings may be delayed or disputed due to manual processes or centralized bottlenecks.

    How it's made

    Challenges we ran into One of the most stressful bugs I encountered was while integrating Chainlink VRF into my betting game smart contract. Specifically, I ran into an issue with the VRFCoordinator contract that caused a hard-to-trace overflow error. The bug happened because the contract attempted to perform a subtraction like: block.number - 1 At first glance, this seemed harmless. But since I was testing the contract using Anvil (a local Ethereum testing environment), the chain had just started and the block.number was 0. So the operation 0 - 1 resulted in an underflow, which caused the contract to revert. Since the VRFCoordinator is a library contract I didn't write myself, it was a tough debugging process. I had to go through every internal call until I isolated the exact line causing the failure. I learned how important it is to understand how test environments behave differently—especially with block numbers, timestamps, and other context-sensitive variables. After identifying the issue, I modified my test environment to manually mine a block before requesting randomness, ensuring the block number was always greater than zero. This challenge reminded me that even small assumptions—like expecting a block number to be greater than zero—can break things when working with low-level blockchain mechanics.