Designing a Web3 Sportsbook That Feels Like Web2: The Bookmaker.XYZ Playbook

For product designers, founders, and CTOs building betting or DeFi products on decentralized infrastructure, deciding how much of that infrastructure users should ever see.

A bettor does not care that their wager settles against a liquidity pool smart contract on Gnosis Chain. They care that the odds are live, the bet confirms, and the payout arrives. Every decentralized betting product eventually collides with this fact: the architecture that makes it trustworthy is the same architecture that makes it unusable.

Seed phrases, gas tokens, network switching, bridge interfaces: each is a conversion wall. Traditional sportsbooks solved onboarding decades ago with an email field and a deposit button. Web3 sportsbooks inherited superior settlement guarantees and inferior everything else.

We spent four years designing Bookmaker.XYZ, the first betting frontend on the Azuro protocol and, by mid-2024, the most popular and highest-earning application among 28+ frontends connected to it. This article is the playbook: the specific UX decisions that let a non-custodial sportsbook compete with Web2 platforms without hiding what it is. The design evolution story is covered in Bookmaker.XYZ: The Invisibility Engine. Here, we focus on the mechanics behind those decisions.

TL;DR

• Bookmaker.XYZ launched in June 2022 as the first frontend on the Azuro protocol; by April 2024 it had processed 198,833 bets and $1.47M in operator revenue, later passing $2M and ranking #1 among 28+ Azuro frontends.
• Account abstraction was the highest-leverage UX decision. Users sign in with email, Twitter, or Discord to create a non-custodial smart account, then pay gas in USDT or DAI rather than first acquiring MATIC or xDAI.
• The funding hub went through two versions. The first ran swap and bridge as separate in-product flows for every network and token combination. The second reduced this to one deposit modal with three simple paths in.
• Every bet carries an explicit state (accepted, live, pending, won, lost, cashed-out, redeemed) instead of leaving users to guess whether a wager registered.

Why Does Web3 Sportsbook UX Fail for Mainstream Bettors?

Early decentralized applications asked users to tolerate friction as proof they belonged there: a wallet extension, a seed phrase, a native gas token, an RPC network, all before the first bet. That worked while the audience was protocol enthusiasts. It stopped working once the audience widened to people who just wanted to place a bet.

The failure points are consistent across the category:

1. Onboarding requires infrastructure knowledge. Installing a wallet extension, storing a 12-24 word phrase, acquiring a native gas token, and configuring an RPC network, all before the first bet.
2. The wrong-token, wrong-network problem. A user holds ETH on Arbitrum; the sportsbook settles in USDT on Polygon. Historically they left the product to bridge and swap manually.
3. Unexplained latency. On-chain confirmation takes seconds to minutes. Without designed feedback, waiting reads as failure.
4. Interfaces that showcase the chain instead of the bet. Explorer links where a bet history should be, hex addresses where a profile should be.

Every one of these is an interface problem rather than a protocol one, which means it is fixable at the design layer without touching the decentralized core.

What Is a Non-Custodial Sportsbook?

A non-custodial sportsbook does not keep user balances in an operator-controlled account. Before a wager, users control funds through their own wallet or smart account; once placed, the wager is executed and governed by smart contracts. There is no deposit ledger to freeze and no withdrawal queue: settlement happens automatically once the smart contract resolves.

Bookmaker.XYZ runs on this model on top of Azuro, an infrastructure layer that provides pooled liquidity, automated odds, and oracle-based settlement across EVM chains including Polygon, Gnosis Chain, Arbitrum, and Base. The frontend concentrates entirely on user experience, brand, and acquisition; market pricing and counterparty risk live at the protocol level. By mid-2024, cumulative volume across all Azuro frontends had passed $350M, though those are ecosystem figures, not one operator's. The frontend's own job is narrower and harder: make betting against a protocol feel like betting, full stop.

At the interface level, we treated blockchain visibility as a verification layer rather than a navigation layer. Bet history and states lived inside the product, while a "View on Explorer" link remained available for users who wanted to inspect the underlying transaction.

How Bet States Are Made Explicit

The clearest proof of that principle sits in the bet slip and betting history, where every wager carries one of a defined set of states rather than a blockchain hash a user has to interpret:

• Accepted: the bet is confirmed and active.
• Live: the match has started and the bet is in play.
• Pending / Pending resolution: waiting on the match or the settlement oracle.
• Won / Lost: the outcome is settled.
• Cashed-Out: the user closed the position early, with the cash-out value shown.
• Declined: the bet did not go through, with a refund path attached.
• Redeemed: winnings have been claimed.

The same taxonomy applies uniformly whether the wager is a single, a combo across several matches, a freebet, or a boosted-odds promotion. A user never has to guess whether a bet registered. The state names the wait.

‍

How Does Account Abstraction Change Sportsbook Onboarding?

Account abstraction was the point where Bookmaker.XYZ stopped asking users to be crypto users.

We designed the onboarding flows around the platform's account abstraction integration, built on the Etherspot SDK. Two things changed:

1. ‍Social login creates a real wallet. A new user signs in with email, Twitter, or Discord. Behind that familiar action, a non-custodial smart account is created: no extension, no seed phrase ritual, no custody compromise. Experienced users still connect MetaMask, Phantom, or WalletConnect through the same modal. One entry point, two levels of ceremony, zero forced education. The onboarding steps that follow (rules, welcome screen, first deposit) are structurally identical for both paths; only the entry action differs.
2. Gas disappears as a concept. A paymaster lets users pay transaction fees directly in the stablecoin they are betting with, USDT or DAI, instead of first acquiring MATIC or xDAI. Holding a token you don't want, purely to move the token you do, is the most arbitrary tax in Web3 UX. Removing it converts traditional bettors who would never pass that step.

‍

The design principle underneath: abstraction is progressive, not total. A casual user can place ten bets without ever seeing a network name. A professional can inspect every transaction on-chain. The blockchain is deferred rather than hidden.

This is the pattern we would argue is now mandatory for any consumer Web3 product: the seed phrase ritual filters out precisely the users a growth-stage platform needs most.

How Do You Design One Interface for Crypto Natives and Traditional Bettors?

We covered the dual-view approach in The Invisibility Engine: cards for browsing, dense rows for scanning. Underneath both sat one design system, with over 500 components covering betting, wallet, casino, and GameFi flows, and states for insufficient funds, minimum-bet limits, and support escalation mapped before UI.

Depth followed the same logic. Each match page carries an odds-movement chart with configurable price alerts and a statistics tab with market predictability: tools professional bettors expect from trading-grade platforms, invisible until sought. Anonymity got the same treatment: the profile module tracks full betting history under a wallet address instead of a username, preserving non-custodial anonymity without sacrificing the utility of an account.

How Do You Handle Latency, Bridging, and Token Mechanics in the UX?

Three sources of friction cannot be removed from a decentralized product. They can only be designed around.

Multi-chain liquidity. The first version of the funding hub handled every combination inside the product. A "Select Crypto" step read the user's network and token, then routed to Swap Tokens, Bridge Tokens, or both in sequence. The route depended on whether the wallet held the wrong network, the wrong token, or both. Swaps ran through 1inch, bridging through Hop or Connext. That covered every case correctly, but it meant designing and maintaining three separate multi-step flows for what should have been a single action: add funds.

‍

The second version cut the surface without cutting the capability. A single Deposit modal asks for one thing: send USDT on the network the product runs on. It then offers three ways to arrive there. Buy on an exchange and send directly to the shown address. Buy with a card. Or use an aggregated bridge-and-swap link for anything already sitting on another chain or token. The complexity did not disappear. It moved off the critical path, so a first-time user is no longer shown three technical states before they can fund an account.

On-chain latency. Confirmation time cannot be designed away, so the interface has to make intermediate states explicit and predictable. The bet-state taxonomy above is what carries this in practice: a user waiting on a "Pending" bet is watching a labeled state, not a spinner.

Chain-specific mechanics. Some complexity must surface, Gnosis Chain's WXDAI redemption, for example. Where it does, we translated it: a plain-language explainer covering the liquidity pool, unwrapping, and spending caps, placed exactly where the user encounters the mechanic. Education happens at the moment of need, not as a prerequisite.

The same discipline applied to the product's marketing surface: a banner template system, covered separately, replaced ad hoc design work for each new promotion.

What Did the Numbers Show?

Working on a product this transparent has one advantage: the metrics are on-chain and public.

• June 2022: Bookmaker.XYZ launches as the first betting frontend on Azuro's Gnosis Chain mainnet.
• April 2024: on-chain analytics record 198,833 bets and $1,469,584 in cumulative operator revenue attributed to the frontend.
• Mid-2024: cumulative revenue passes $2M; Bookmaker.XYZ is the most popular and highest-earning of the 28+ frontends connected to the protocol (Cryptorank research).
• The casino vertical, added under our ongoing product engagement, grew to 3,500+ titles, hedging revenue against seasonal sports calendars.

One structural note worth stealing: unlike prediction markets whose volume spikes and dies with election cycles, sports-led products capture repeating volume tied to athletic calendars. Protocol-wide data from mid-2024 shows football at 69.4% of volume and basketball at 18.6% (DappRadar), a spread of activity across recurring events rather than a single binary bet.

We cannot claim the design caused the ranking; frontend success on a shared protocol compounds from first-mover position, acquisition, and incentive programs like Azuro Score. What the design demonstrably did is stop losing the users acquisition brought in: onboarding that converts Web2 traffic, and an interface professionals do not outgrow.

What Carries Over to Any Web3 Product?

Four decisions from this playbook generalize beyond betting:

1. Trust is structural, so make the structure legible. Non-custody means nothing to a user who cannot see their funds and bet states inside the product.
2. Abstract progressively. Social login and gasless transactions for entry; full on-chain inspection for those who want it. Never force the ceremony.
3. Serve cognitive modes, not personas. Dual views cost one design system and doubled the addressable audience.
4. Design around irreducible friction. Latency, bridging, and token mechanics don't disappear, but explained friction retains users, and unexplained friction churns them.

The metrics in this playbook did not come from hiding the protocol. They came from designing every point where a user would otherwise have to stop and think about it. That is the difference between a Web3 product that survives its own architecture and one that is eventually beaten by it.