Esports betting platform,
for the next generation.

Where the new players are

The fastest-growing iGaming audience grew up on mobile and crypto. Crash games and esports betting are how you reach them — short sessions, social mechanics and provable fairness.

These products pair naturally with a crypto-ready platform and wallet.

Esports data is not a sports feed

A football match has a canonical state. One clock, one score, a small number of official suppliers whose output is contractually the truth. Esports has nothing like it. Match state lives inside a game engine owned by a publisher, and what you can read depends on the publisher, the tournament organiser, the tier and the season. Some titles expose a proper API. Some expose it only to the organiser. For others you are reading an observer client, a scoreboard overlay or a stats endpoint that was never designed to settle bets.

So an esports betting platform is a data engineering problem before it is a betting problem. You are not consuming a feed. You are reconciling several partial ones, per title, and deciding which to believe when they disagree.

Every title needs its own event model

The unit that markets settle on is different in each game. A Counter-Strike round is short, discrete and nearly atomic, with an economy that resets on a defined boundary. A Dota lane phase has no clean boundary at all — it is continuous, and "when did it end" is a judgement. A League objective is an instantaneous state change that moves win probability further than anything else on the map. One generic sports-event schema cannot hold all three. Builds that try either drop the state the pricing model needs, or grow a hundred nullable columns nobody trusts.

What works: a per-title adapter that normalises into a small common core — fixture, participant, market, selection, settlement — and keeps the title-specific state in a typed payload the model reads directly. The core stays stable when you add a title. The adapter absorbs the mess.

The series hierarchy bites too. A best-of-three has maps that may never be played. A bet on map three when the series ends 2–0 is a void, not a loss, and that rule belongs in settlement code, not in terms and conditions where a support agent has to apply it by hand.

What happens when the feed lies

Feeds fail in ways that cost money. A connection drops mid-round. A scoreboard resets on a technical pause. A scraper reads an overlay that froze two minutes ago. A match is remade and the old state is still streaming. Each one can settle a market wrong, and wrong settlement is the fastest way to lose both a licence conversation and a player base.

• Never settle from one source when a second exists. Disagreement means suspend and escalate, not pick the newer one.
• Timestamp at the source, not at ingest. Skew between the two is itself the signal that something is wrong.
• Treat silence as suspect. A live feed that stops updating mid-round is not telling you that nothing is happening.
• Keep the raw event log immutable. Settlement resolves from a replayable stream, never from a mutated current-state row. Disputes and regulators both work backwards through it.

Suspension is the hardest problem in in-play esports

The primitives carry over from sport. If you know our sports betting software development work, you know the shape: price, expose, suspend, settle, limit. What does not carry over is the ground truth underneath. A sportsbook engine pointed at esports data without a per-title state layer looks correct in a demo and settles wrong in production.

Nowhere is that gap wider than in-play. Something decisive happens on the game server. Your feed learns about it some time later. The broadcast the player is watching is delayed deliberately, to stop the teams being ghosted. Between those clocks sits a window in which somebody already knows the answer and your prices do not — and that somebody is at the venue, in a call with a person at the venue, or on a regional restream with a shorter delay than the one you assumed.

Your exposure on any in-play market is the sum of three times you control: time to detect, time to decide, and time to suspend on every client. Everything below is about shortening those three.

What triggers an automatic suspension

• Price movement past a threshold inside a window — the model already knows something changed.
• Stake pattern — a burst of correlated stakes on one selection from accounts that should not be correlated.
• Feed anomaly — sources disagree, a heartbeat gap opens, or the state jumps somewhere it could not legally have jumped.
• Model uncertainty — the pricing model's own confidence collapses. A model that cannot tell you it is lost is worse than no model.
• Title-specific precursors — a bomb plant with a known number alive, a Baron start, a buyback. These are the events before the market-moving event. Suspending on the precursor is how you buy back latency you cannot otherwise remove.

Over-suspending costs more than it looks

Two failure modes, and only one shows up in your numbers. Suspend too little and you get picked off — not at random, because arbitrage players find the slowest book and stay on it. That loss lands in the P&L with a name on it. Suspend too much and the market is dead: this audience bets small and often, and a book that greys out every twenty seconds is not a product they will use. That loss arrives as volume you never had, which is why over-suspension survives for years in books that would never tolerate the equivalent leak.

So measure suspension rather than feel it. Log every one with its trigger, its duration and the price move that followed. Triggers that reliably precede a real move earn their keep; triggers followed by nothing are noise you can tune down with evidence instead of argument.

Why the suspension decision lives next to the odds engine

A suspension that must cross a network hop, a queue and a service boundary before it reaches bet acceptance is a suspension you do not have. The decision and the acceptance gate belong in the same process, reading the same event, in the same memory. Publish outward for the UI by all means — but the authoritative gate is local, and the UI is a view of it, never the enforcer.

Two details get skipped and then get expensive. Acceptance must be idempotent, because a phone on a venue network will retry. And every accepted bet must record the market version its price came from — "which price was live when this bet landed" is a question you will be asked by a player, a trader and eventually a regulator, and the only good answer is a stored row, not a reconstruction.

Pricing automatically, overriding manually

Volume is priced by model, per title, with margin applied per market rather than globally — a match winner and a map-three handicap do not deserve the same overround. Liability limits sit per market, per selection and per customer segment, enforced at acceptance: a limit that only exists in tomorrow's report is not a limit.

Then there are the cases where history is a bad guide and a human trader takes the wheel — a tier-three fixture with barely any prior data, a roster change announced two hours before the match, a patch that quietly rewrote the meta the model trained on, or any market the model has itself flagged as low confidence. The model carries the volume, the trader carries the exceptions, and the platform's job is to make that handover fast rather than heroic.

This is where owning your platform stops being a philosophical point. Esports margins are thin, and your pricing model is the only durable edge you have. Rent the odds and you have rented your differentiator — from a supplier selling the same prices to the book next to you, who takes a share of your revenue for the privilege. Renting versus owning is a real trade-off across iGaming; in esports the arithmetic is harsher, because once the prices are identical there is little left to compete on.

Integrity, and the product this audience expects

The fixing risk lives at the bottom of the pyramid

It is not the majors. A tier-one event has prize money, contracts, careers and an organiser with every incentive to investigate. The exposure sits underneath: online qualifiers, regional leagues and third-tier events where what a player earns from the match is small next to what someone could win betting on it. Identity makes it worse — a competitor is a handle, not a passport, and stand-ins are routine, so the roster you priced may not be the roster that plays.

The controls that matter are code, not policy documents:

• Market caps scaled to tier. Lower tier, lower maximum stake, fewer markets — set on the market template and derived from the fixture's tier the moment it is created, not a rule a trader is meant to remember at 2am.
• Unusual-pattern detection. Stake distribution against the book's own baseline for that market type; accounts correlated by device, funding instrument or timing; accounts that only ever bet one region, tier or team. None prove anything alone — together they are worth a human's attention.
• Suspend first, escalate second. An alert that only lands in a queue is worthless while the match is live. The trigger should hold the market and page a person in the same action.
• A reporting path that exists before you need it. Wire the route to the organiser and the relevant integrity body into the workflow. Operators who build it after the first incident build it badly.

Be honest about the limit: detection is probabilistic, and no model tells you a match was fixed. The platform's job is to surface the pattern fast enough, and cheaply enough, that a human can act while the event is still running.

They arrive from a stream, not a homepage

This audience is young, mobile and stream-native. Their expectations were set by the games they play and the apps they already use, not by a sportsbook. They arrive mid-match, on a phone, and want a bet on before the next round starts. Two taps to the slip, odds legible beside the stream, no reload between rounds. A desktop-first book with a mobile skin reads as a museum piece to them, whatever its market depth.

It is also why crash, mines and plinko sit next to esports markets rather than in a separate product. Same instant-outcome loop, same wallet, same session shape — a player waiting out a map change starts a crash round. That adjacency only pays if moving between them costs nothing: one wallet, one balance, one session, no interstitial. If your casino games and your esports book are separate products bolted together, the player feels the join and you lose the session.

The skins question, answered honestly

Much of this audience learned to bet with skins, and skin-driven acquisition is a genuine temptation. It is also where regulatory attention concentrates. A skin is a virtual item with a real out-of-platform market value, which can pull you into gambling regulation — and into anti-money-laundering rules on value transfer — in ways a plain cash wallet does not. Treat anything skins-adjacent as an iGaming licensing question before it is a product question, and confirm the position for each target market with your regulator and your counsel. This area moves, and it tends to move against operators who assumed.

The same applies to age. This audience sits materially closer to the legal limit than a sportsbook's, so KYC and AML controls cannot be a friction problem you solve after launch. Verification belongs in onboarding from the first sprint, in a form the regulator you are applying to will accept.

When custom is the wrong answer

White-label is genuinely faster and cheaper to launch. If the plan is one brand, one market and a test of whether anyone wants what you are selling, rent it. Custom earns its cost when you have volume, when the product itself is the differentiator, when you run several brands or markets, or when you intend to sell the company — because then the platform is the asset, and you cannot sell what you licensed. Esports pushes harder toward custom than most verticals, for the reason above: a shared pricing model is not an edge. Our low-latency infrastructure exists so that model's decisions land before the bet does.