The problem Hurdle Derby solves

Hurdle Derby: A Fully On-Chain, Automated Card Racing Game for Farcaster

Hurdle Derby is a decentralized, pari-mutuel betting game where players wager on which Ace will win a dynamic, unpredictable race. Built as a Farcaster Frame, it brings provably fair gaming directly into the social feed.

The project solves the problem of trust in online gambling by creating a fully autonomous and transparent system where every outcome is determined by on-chain logic and verifiable randomness—no house, no hidden odds, just pure probability.

How it Works

1. Parallel Races: The contract simultaneously runs a fast-paced Hourly Race for constant action and a long-term Weekly Race with a larger, treasury-funded jackpot.
2. Place Bets: Players connect their wallets and place bets in USDC on which of the four suits (♠️, ♥️, ♦️, ♣️) will win.
3. The Race Unfolds: At the end of each race period, a fully automated on-chain process simulates the race. Cards are drawn from a shuffled deck to move the Aces forward, but the unique Hurdle mechanic reveals setback cards that can change the outcome in an instant.
4. Provably Fair Results: The deck shuffle is powered by verifiable randomization, ensuring the outcome is cryptographically secure and unpredictable.
5. Claim Winnings: Winners can claim their share of the pot, with payouts calculated based on the transparent, pari-mutuel odds.

Key Features

• Fully Autonomous: Powered by custom automation logic, the entire game loop—from starting a new race to processing payouts—runs 24/7 with zero manual intervention.
• Provably Fair: Utilizes custom, but verifiable, tamper-proof randomness in every race.
• Decentralized & On-Chain: All game logic and funds are managed by the smart contract on the Base network, ensuring full transparency.
• Farcaster Frame Native: Designed for seamless interaction directly within the Farcaster social ecosystem.
• Robust Treasury Management: Features an on-chain, multi-sig treasury system for funding jackpots and managing protocol fees.

Challenges I ran into

Building a fully autonomous, on-chain game presented several deep technical challenges. The biggest hurdle was not just writing the "code", but diagnosing and solving a series of "silent failures" where the automated systems would stop working without obvious errors.

The first challenge: Migrating from Decentralized Oracles to a Self-Hosted Keeper

Problem: After deploying to mainnet, I, sadly, discovered that the operational costs for funding the decentralized Chainlink Automation and VRF services with LINK were prohibitively expensive for a new and purely personal project. My hackathon budget and timeline required a more cost-effective immediate solution without sacrificing security.

Solution: I re-architected the entire automation and randomness generation system.

1. Replaced Chainlink Automation: I built a custom, centralized "keeper", this took over the role of monitoring the contract and triggering state changes.
2. Replaced Chainlink VRF: I removed the VRF dependency and implemented a secure, two-step Commit-Reveal scheme for randomness. The off-chain keeper now generates a secret number, commits its hash on-chain, and then reveals the secret in a later transaction to ensure provably fair outcomes without the cost of an oracle.
3. Enhanced Access Control: To support this new model, I had to refactor the access controls, creating a dedicated "onlyKeeper" modifier - or role. Distinct from the "owner", to ensure the keeper bot had the minimum necessary permissions to operate the game.

The second challenge: Debugging a Persistent "Silent Failure" in Automation

Problem: Even with the custom keeper, the game loop would stall. The on-chain race state would never progress past "Betting". The "endTime" for races would pass, but the resolution was never triggered.

Solution: This required a meticulous, multi-day debugging process using a combination of Tenderly transaction traces, on-chain state queries via Basescan, and analysis of the server logs. The root cause was a series of subtle but critical configuration mismatches between the on-chain and off-chain components:

1. Incorrect VRF Parameters: I discovered my initial mainnet deployment was using incorrect, outdated VRF Coordinator and Key Hash addresses, causing the VRF request to revert silently.
2. Missing VRF Gas Funding: I diagnosed that my VRF subscription on Base Mainnet required funding with both an enormous amount of LINK, a budget I didn't have.
3. On-Chain vs. Off-Chain Time Mismatch: I found that my keeper script was using the server's clock ("Date.now()") to check if a race should be resolved, which was out of sync with the blockchain's "block.timestamp". I fixed this by refactoring the keeper to be "stateless," relying solely on the contract's "checkUpkeep" function as the single source of truth for when a task is ready.

The third challenge: Architecting a Scalable, Gas-Safe Payout System

Problem: I (as every founder) anticipated that a popular race with thousands of winners could create an unbounded loop during the payout phase, potentially exceeding the block gas limit and causing the entire race resolution to fail and lock all funds.

Solution: I proactively designed and implemented a robust, batched payout system.

1. I introduced a new "PayoutsPending" state to the race lifecycle.
2. I wrote a "processPayouts" function that calculates and stores winnings for a small, configurable "batch" of winners at a time.
3. I integrated this into the keeper's logic, allowing the automation to call "processPayouts" repeatedly until all winners are processed, at which point the next race is safely created. This ensures the game remains stable and operational, no matter how popular it becomes.

Smart Contract Address(es)

Live games are running on both Base Mainnet and the Base Sepolia testnet.

Base Mainnet

• Contract: 0xaCC36C9Fb9dF3cf3B2772a496aCFbfDa9a73a6a2
• Play live or as a Farcaster mini-app

Base Sepolia (Testnet)

• Verified Contract on Basescan: 0x954C13Da7AC6E3c59909a4B44AdBb0CaC8A5762e
• Play live or as a Farcaster mini-app

Other Onchain Proof

Hurdle Derby's traction and functionality are fully verifiable on-chain. Beyond the main game contract, there are several key on-chain components that demonstrate the robustness of a custom, automated system.

• Secure Multi-Signature Treasury: Hurdle Derby is not using a standard EOA for the treasury. All protocol fees are managed by a Safe multi-signature wallet, ensuring a higher level of security and trust for the protocol's earnings.

  • Treasury Wallet: "0xa4Bd324438B24030351107B696C2744Ff7E9FdC4"

• Custom Keeper-Powered Automation: The entire game loop is made autonomous by a custom, self-hosted keeper script. This keeper monitors the contract's state and automatically executes tasks. You can see the on-chain transactions where the keeper wallet calls the contract to run the game.

  • The "Commit" Transaction: Resolve race
  • The "Reveal" Transaction: Reveal randomness
  • The "Payout" Phase/Transaction: Process payouts
    • Here we have no winner, so it just starts a new race immediately
      To provide verifiable randomness without the cost of an oracle, so I implemented a secure on-chain Commit-Reveal scheme. This is a two-transaction process that proves the randomness was not tampered with.

• Live Player Interaction: The game is live on mainnet and has successfully processed bets and paid out winnings to players.

  • Bet by me: "0x040830f93379cf51fff70b7a5332f3b89742af7b24fa2baa42a73863e1e38d69"
  • Claim by me: "0x0631c336fd9c8fbd55dcc8332dd1d53f819592967cf638f20fa8a66b2803550b"