How We Built BitcoinDerby: Integrating 5 Crypto Wallets Into One Unity WebGL Game

BitcoinDerby is one of the most technically complex projects we have ever shipped at Peacebox Studio — a live, real-money blockchain horse racing game running on Unity WebGL with 5 different crypto wallet integrations, 4,000+ NFT horses, and real-time multiplayer races with up to 100 spectators per race.

This post is a behind-the-scenes breakdown of how we pulled it off.

The Challenge

When the client approached us, the brief sounded simple: build a browser-based horse racing game where players race their Bitcoin Ordinals NFT horses and bet using gems. Simple enough.

Then came the requirements list.

Five different crypto wallets needed to work — each with their own SDK, authentication flow, and browser-based communication pattern. The game needed to support two different blockchains simultaneously (Bitcoin Ordinals and Ethereum). Real-time multiplayer had to support 100 simultaneous viewers per race. An in-game economy with gems, Stripe payments, and a quest system all had to function reliably in a WebGL environment.

And it all had to ship in under a year with a team of three.

Architecture: The Wallet Module Pattern

The biggest technical decision was how to handle 5 completely different wallet SDKs without duplicating core game logic.

We solved this by architecting each wallet as an independent, interchangeable authentication module. Every wallet — Magic Eden, Unisat, Leather, Xverse, and MetaMask — implements the same interface:

public interface IWalletProvider {
  Task<string> Connect();
  Task<string> GetAddress();
  Task<bool> SignMessage(string message);
  Task<TransactionResult> SendTransaction(TransactionData data);
}

This meant the game never needed to know which wallet was active. It just called the interface. Swapping wallets was a one-line change.

Multiplayer: Photon Fusion on AWS

For real-time races with 100 spectators, we needed a dedicated server architecture — not peer-to-peer. We chose Photon Fusion in Dedicated Server Mode, deployed as a headless Unity build on AWS EC2.

The key insight was separating spectators from participants. Only the 10 racing horses are full Photon NetworkObjects. Spectators receive a compressed broadcast of race state every 100ms via a custom Observer pattern — no unnecessary Photon events fired.

The Gem Economy

All in-game currency (gems) are managed server-side via a REST API, completely decoupled from the Unity client. Stripe webhooks validate every payment before gems are credited. This prevents any client-side manipulation of balances.

Lessons Learned

• Always build wallet integrations as interchangeable modules — not hard-coded integrations
• WebGL has strict memory limits. Object pooling is not optional, it is mandatory
• Decouple blockchain calls from gameplay with fire-and-forget + graceful fallback
• Test on the lowest-spec hardware your users might have, early and often

BitcoinDerby has been live for over 12 months with zero critical bugs in production. If you are building a Web3 game and want to talk architecture, reach out to us.