Deal or NOT
ZK Cash Case
The problem Deal or NOT solves
Deal or NOT brings the classic game show experience onchain with provably fair mechanics and cryptographic guarantees:
What it solves:
-
Trust Issues in Online Gaming: Traditional online games require players to trust centralized operators. Deal or NOT uses smart contracts and ZK proofs to guarantee
fairness—no one can manipulate case values or outcomes. -
Front-Running Prevention: The commit-reveal lottery system ensures fair player selection without MEV attacks or front-running bots gaming the entry process.
-
Transparent Prize Distribution: All case values, banker offers, and jackpot calculations are verifiable onchain. Players can independently verify the game's integrity.
-
Provably Random Outcomes: Uses cryptographic proofs to guarantee case values are randomized before the game starts, not manipulated during gameplay.
-
Progressive Jackpot Mechanics: Creates a sustainable game economy where the jackpot grows across games, rewarding skillful "NO DEAL" decisions and risk-taking.
Why it matters:
Game shows have always relied on trust in the broadcaster. By moving this onchain with ZK proofs, players get mathematical guarantees instead of promises. Every case value, every
banker calculation, every winner—all cryptographically verifiable.
This emphasizes the trust, fairness, and transparency benefits of putting the game onchain with ZK proofs.
Challenges we ran into
Challenges I ran into:
ZK Proof Integration Complexity
The biggest challenge was implementing zero-knowledge proofs to verify case values without revealing them. Initially tried using Noir, but the circuit compilation and witness
generation added too much overhead. Switched to a simpler hash-based commitment scheme with Merkle proofs for the MVP.
Commit-Reveal Timing Issues
Had to carefully design the lottery commit-reveal window to prevent griefing attacks where players commit but never reveal. Solution: implemented a time-bounded reveal phase with
slashing for no-shows, and automatic refunds for honest participants if lottery fails.
Gas Optimization for 26 Cases
Storing and manipulating 26 case values onchain was expensive. Used bit-packing and tight storage patterns to reduce costs. The banker offer calculation also needed
optimization—moved complex math offchain and only verified the final result onchain.
Randomness for Case Distribution
Initially used block.prevrandao, but realized it's manipulable by validators for high-stakes games. Migrated to Chainlink VRF for provably fair randomness, which added complexity
to the game flow and required managing VRF callbacks.
Use of AI tools and agents
The game is designed to be agent-playable. AI agents can:
- Generate wallets and enter the commit-reveal lottery
- Make strategic decisions about banker offers using risk models
- Compete against humans with different risk tolerances
This creates an interesting dynamic where agents can test decision-making strategies under uncertainty. An agent might use expected value calculations while humans rely on
intuition. The commit-reveal system prevents agents from getting unfair advantages through MEV or front-running.
Testing & Debugging
AI agents helped write Foundry test cases covering edge cases like players revealing with wrong nonces, banker offers during invalid game states, and jackpot distribution on edge
cases (ties, timeouts).
This positions the game as both built with AI and playable by AI agents—a cool demonstration of onchain agent capabilities!
Tracks Applied (2)
Devtopia
Base Self-Sustaining Autonomous Agents
Base
Technologies used