Game frontend & backend
Owns players, matchmaking, skill rules and result verification. The API signing secret remains in the backend.
- Creates a unique match ID
- Starts play after both deposits
- Submits player1, player2 or draw
Match Escrow adds programmable, non-custodial settlement to an existing competitive game. Your backend remains the authority on gameplay; the smart contract holds equal stakes and accounts for the verified result.
The product does not replace matchmaking, identity, gameplay or result verification. It connects a studio's existing backend to a fixed 1:1 settlement contract.
That separation keeps integration focused: the game decides what happened; Match Escrow enforces what the verified result pays.
A small surface area makes the system easier to integrate, monitor and reason about.
Owns players, matchmaking, skill rules and result verification. The API signing secret remains in the backend.
Authenticates create and resolve operations, validates the 1:1 invariant and submits resolver transactions.
Holds equal player deposits and deterministically credits the winner, refunds or fee recipient.
Players approve, deposit, refund and withdraw directly. The Worker receives neither player funds nor keys.
Match Escrow runs on Cloudflare's global edge network. Instead of depending on one regional API server, requests are served through Cloudflare's worldwide edge infrastructure and executed close to the requesting client.
This makes the API layer edge-native by design. Base Mainnet remains the final settlement layer, while the Worker handles authenticated orchestration, validation and durable request state.
Match Escrow is designed for contests where the outcome comes from player performance and the game backend can identify a winner or draw. The contract does not roll dice, price odds or invent a result.
The contract protects custody and settlement rules. The integrating backend remains trusted to submit the correct result.
The API behaves like an escrow adapter between your backend, player wallets and Base.
Persist both wallet addresses, equal stake, chain and deterministic match ID. Send one authenticated, idempotent request.
POST /api/matchesThe public API returns chain-bound unsigned calldata. Each player signs approve and deposit from their own wallet.
approve() → deposit(matchId)Wait for confirmed chain state, submit player1, player2 or draw, then update progression after resolve finality.
POST /api/matches/:id/resultContract state is authoritative. If a wallet receipt succeeds but the application callback fails, reconcile the confirmed transaction instead of asking the player to pay again.
The guided demo replays a controlled production run from the SkillChess integration. It does not fabricate transactions or submit new ones during the presentation.
invite-mrmhrcsjPmzC45on0xfc6494…501b8dFive practical properties make the system useful to studios and verifiable by technical teams.
No. USDC moves from player wallets into the MatchEscrow contract. The Worker never receives or controls those tokens.
The authorized game backend does. Match Escrow validates match state and settles the result supplied by that trusted backend.
Settlement follows a result produced by player performance and verified by the game. The payment layer remains independent of game-specific rules.
A draw returns both full stakes with no platform fee. After an unresolved funded deadline, either player can trigger a fee-free refund for both stakes.
Yes. The game needs two wallet addresses, a stable match ID, a stake and a trusted result. Matchmaking and gameplay remain unchanged.
A controlled Base Mainnet real-USDC lifecycle is operational and verified. The contract remains unaudited, so public rollout and larger stakes require independent review first.
No wallet. No funds. Every displayed transaction comes from a completed Base Mainnet run.