Custom iGaming platform

We joined to build the growth system

xGame was already feature-complete when we joined. Its original team had built a polished crash game with custom animations and strong mobile performance. A multiplier increased during each round, and players had to cash out before a hidden crash point.

Player funds remained on the blockchain. Bets ran in the game's backend, and final payouts settled back on-chain.

A two-person Leet Software team designed and built the leaderboard and affiliate analytics inside the existing product. The system ranked players and affiliates by winnings, profit and loss, wager volume, referrals, and related metrics.

Referral relationships extended through multiple levels. The underlying activity existed as individual blockchain events rather than one readable total. We built an indexer that consumed live events, backfilled historical events, and aggregated the results off-chain for the leaderboard.

Tracing made the failures diagnosable

The existing systems had logs, but no way to follow one player action across services. We introduced OpenTelemetry traces, propagated trace IDs between services, and included those IDs in structured logs sent to Better Stack.

Players had already found inconsistent round behavior during beta. The traces helped us follow each action across the leaderboard, the game services, and the blockchain transaction. They confirmed that our leaderboard worked correctly and helped narrow the launch blocker to the game's transaction flow.

Our lead engineer then paired with the partner CTO on reliability and launch readiness. The rest of both teams continued to support the wider product.

A finished game that didn't feel live

PulseChain was central to the product's brand, community, and commercial strategy. The game also supported Base and BNB Chain, but most launch activity happened on PulseChain.

PulseChain confirmed blocks about every ten seconds. Its third-party infrastructure APIs could disagree about the latest state or report that a transaction failed after it had landed.

Most rounds encountered some delay or inconsistent state. Players could remain on a loading or unexplained error screen for seconds or minutes. They could not place another bet or withdraw funds until the round completed.

Their money was not at material risk because administrators could reconcile it. The game was still unlaunchable. Nobody could judge its polished animations or gameplay while its core loop behaved unpredictably.

Making uncertain transactions safe

One backend wallet handled round transactions for each room of roughly 100 players. A single pending transaction could block every transaction behind it.

Before creating a round, the backend compared confirmed and pending transaction sequences. If an earlier transaction was stuck, it replaced that transaction with a zero-value transfer that used the same sequence and progressively higher network fees.

New round transactions also retried with higher fees. After every attempt, the system checked whether any earlier attempt had already landed. This protected against infrastructure APIs that reported failure after accepting the transaction.

We compared fee estimates from two independent sources and used the higher estimate. Every external call had bounded retries with exponential backoff and jitter.

Giving failed rounds a safe ending

If every transaction attempt failed, the round entered a visible error state for all players. The system retried its recovery flow, reconciled the off-chain state, marked the round as interrupted, cleared its bets, refunded players on-chain, and returned to a waiting state.

The contract prevented a round from being created or settled twice. Replacement transactions reused the same sequence, so retries could not create duplicate writes.

An uneventful launch

Launch stabilization occupied the final weeks of an engagement that lasted about three months. Both teams monitored the first two weeks closely.

xGame handled $300k in first-week volume, mostly on PulseChain. There were no stuck rounds, lost balances, emergency fixes, or meaningful user-visible reliability incidents.

What followed

The tracing system remained useful after launch. The partner CTO later told us that it had repeatedly helped him diagnose production problems. The same observability approach then spread to other projects within the partner team.