Chess Clash

Imagine chess games where the moves don’t just happen on the board — they happen in the marketplace of support and rivalry.

Every player in our game has their own token, a digital asset representing their presence and style. When a match is about to start, players (and even fans) can tweet their move, idea, or smack-talk and back it with tokens. This is what we call a Clash.

Example: ♟️ Player A tweets: “I’ll dominate with my aggressive opening.” They stake their Player Token. ♜ Player B responds: “Your defense won’t hold past 10 moves.” They stake their own token.

Now, fans and the community can pick a side by buying and holding one of the two players’ tokens. If Player A gains momentum on the board and on social media, demand for their token spikes — supporters win because their token rises in value. If Player B turns the tables, their token rallies instead.

This creates a thrilling feedback loop:

On the board → strong moves, bold plays, and outcomes.

On social media → witty tweets, narrative, and influence.

In the token market → value shifts based on who’s winning hearts, minds, and games.

The beauty? Even if you’re not playing chess yourself, you’re part of the clash. You can back your favorite player, hedge by trading between sides, or ride the hype of a viral moment. Suddenly, every move and every tweet isn’t just entertainment — it’s a chance to be rewarded for your support and instincts.

Our project transforms chess clashes into economic clashes, making the game more social, more interactive, and more rewarding for players and fans alike. That keeps chess at the center while tying in:

Tokens = players

Tweets = moves + personality

Fans = traders/supporters

Market = outcome of clash

Stack & Networks

Chain: Base Sepolia (for fast, cheap demo)

Contracts: Solidity (Foundry), some deployments via Remix for speed

DEX: Uniswap (v3 router today) behind a thin Swap Adapter (so we can swap in v4 hooks later without changing app logic)

Frontend: Next.js 14 + TypeScript, wagmi/ethers, Tailwind + shadcn/ui

Wallets & Onramp (sponsor-friendly): Coinbase CDP Wallet (Embedded), optional Onramp

Indexing: Read straight from chain (wagmi) + event subscriptions (no subgraph needed for MVP)

Smart Contracts (MVP)

PlayerTokenFactory

Batch mints 6–8 Player Tokens (ERC-20) for the roster (e.g., Magnus, Gukesh, Hikaru, etc.).

Stores metadata so the frontend can fetch the full roster (getAllPlayers()).

Optional faucet cap per address for easy testnet distribution.

PlayerToken (ERC-20)

Standard OZ ERC-20 with owner mint (for LP seeding) + optional faucet (faucetMint) gated by a per-address cap. 18 decimals, interoperable with any DEX.

ChallengeEscrow (core of the product)

Users create a “tweet” challenge and stake Token A (e.g., MAGNUS).

First counter-stake sets Token B (e.g., GUKESH). Everyone else can stake either side.

Resolve (hackathon mode): owner (mock oracle) picks the winner token after the real-world chess result.

On resolve:

Sells loser token → USDC via the Swap Adapter

Buys winner token with that USDC

Winners claim winner tokens pro-rata (no cash payouts—value concentrates into the winning token)

Swap Adapter (ISwapAdapter)

Pluggable module. MVP uses Uniswap v3 router (UniV3Adapter) with a fixed fee tier (e.g., 0.3%).

Later we can swap in Uniswap v4 Hooks (e.g., fee rebates, auto-buy on resolution) without touching the escrow.

MockUSDC (optional)

If a test USDC isn’t available, we deploy a simple 18-decimals mock to seed pools and run the demo.

Onchain Flow (end-to-end)

Roster setup

Deploy PlayerTokenFactory Call createBatchPlayerTokens(names, symbols, initialSupply, faucetEnabled, faucetCap)

(Optional) Seed tokens + USDC into DEX pools for each player token (TOKEN ↔ USDC)

User actions

Tweet & Stake: createChallenge(tokenA, text) → stakeForA(id, amount)

Counter: stakeForB(id, tokenB, amount) (first counter sets B)

Resolve (owner only for demo): resolve(id, winnerToken, minOuts…) → Adapter sells loser to USDC, buys winner; escrow holds winner tokens

Claim: winners call claim(id) to receive winner tokens pro-rata

Data

Frontend reconstructs state by reading:

challenges(id) struct + user stakes

Events: ChallengeCreated, CounterSelected, Staked, Resolved

Frontend UX

Home Feed: Create a statement (“tweet”), select Token A, stake; cards show A vs B, live stakes, status (Open/Settled)

Challenge Detail: Stake for A or B, see totals and your position, claim after settlement

Roster: All player tokens, balances, Faucet button (respects cap)

Admin Panel: One-click Resolve for demo; minOuts default to 0 to keep swaps simple

Why these choices

Adapter pattern decouples the challenge logic from the DEX. We can ship fast with v3 and later showcase Uniswap v4 Hooks integrations (auto-rebalance, fee streaming, custom pricing) for the Uniswap prize, without rewriting the product.

Token-in, token-out settlement (winner tokens only) aligns with our vision: no binary payouts, value compounds into the winning side. Event-only indexing keeps infra light—no subgraph needed for a weekend build.

Security & Constraints (honest MVP)

Oracle is manual (owner resolve) for hackathon speed. In production we’d use a permissioned resolver set and/or a decentralized oracle service with dispute windows.

Faucet & owner mint are present for demo; in production we’d lock/limit minting and remove faucet or gate it with proofs.

Slippage controls are parameters on resolve (minOut…). For demo we pass 0 to keep swaps deterministic.

What’s next (post-hackathon)

Uniswap v4 Hooks: auto-route resolution swaps, fee rebates to challenge LPs, dynamic fees on volatile clashes.

Results Oracle: Chainlink Functions / Data Streams or a council signer set with time-locked disputes.

Creator tools: allow anyone to propose new tokens (with curation + supply policy) and spawn markets from social momentum.

Social graph: onchain follows/mentions, notifications, “challenge threads.”

Mobile & onramp: smooth CDP wallet flows + fiat onramp to join clashes in seconds.

Demo script (judge-friendly)

Faucet a bit of MAGNUS & GUKESH

Post: “Magnus beats Gukesh today” (stake MAGNUS)

From a second wallet, counter-stake GUKESH

Admin resolves to MAGNUS → adapter swaps loser→USDC→winner

Winner wallet clicks Claim and receives MAGNUS tokens