Poker software with
a fair, fast core.

Integrity and speed, because poker punishes both

Online poker players are unforgiving about lag and cheating. We build a low-latency engine with a provably-fair shuffle and an integrity layer that flags collusion and bots in real time.

Liquidity matters too, so the lobby, tournaments and rewards are designed to keep tables full and players coming back.

The shuffle is the part you cannot fake

A deal is one permutation of fifty-two cards drawn from a space of 52 factorial. The engine has to pick one uniformly at random and — separately — prove afterwards that it did. Two different problems, and most rooms solve only the first.

Two ways a shuffle goes wrong

Entropy is the first. A generator seeded from a clock or a process ID produces a deterministic deck: the seed is the deck. A lab will ask where your entropy comes from and what happens on a cold start — a freshly booted node with a thin pool is the moment worth attacking.

The algorithm is the second. Fisher-Yates is correct; the standard way to break it is modulo bias, reducing a random 32-bit integer with % n to pick an index. When n does not divide 2³² evenly, low indices come up slightly more often — invisible in play, and exactly what a lab's test vectors find. Rejection sampling removes it for the price of a retry loop.

Auditable means reproducible

Shuffle the whole deck once, at the start of the hand, and hold that ordering: one artefact to hash, one to log, one to hand a regulator. Drawing lazily as the hand runs turns "was this deck fair?" into a question about your entire execution path. And the deck never travels — a client learns what its seat may know, never the burn card, the muck or the undealt stub.

What "provably fair" actually proves

Commit-reveal is the standard construction: the server publishes a hash of its shuffle seed before the hand, the client contributes a seed, and afterwards the server reveals its seed so any player can recompute the deck. Be precise about the limit, because the players who care will test it. This proves the deal was fixed before the action started. It does not prove the generator is unbiased — that needs a certified RNG and lab testing of the source.

Which is why "trust us" fails certification. A lab tests source, an entropy design and reproducible outputs. If your shuffle sits inside a third-party binary you licence, you hand over none of those — only the supplier's certificate, scoped to the supplier's deployment. Own the engine and you hand the lab your code, a difference that shows up on your first licence application and every one after.

Read that honestly. A network sells the one thing a custom build cannot ship on launch day: a full lobby. With no traffic and no funded plan to buy it, joining a pool is the rational move, and we will tell you so. The case flips once you have players — then you are paying a percentage of the rake, your only revenue line, indefinitely, on players you acquired and a game you cannot change. Poker sharpens the usual custom versus white-label argument: here the licence fee and the revenue model are the same number.

Cheating in poker is a data problem

In casino games the cheat attacks the house, so the house notices — it shows up in the margin. In poker the cheat attacks other players. Your P&L on the hand is identical either way: you take the rake. Nothing tells you. That asymmetry is why rooms under-invest in integrity until a forum thread does the investigating for them — and the winning players, who set a room's reputation, leave first.

Three attacks, three signatures

• Collusion. Seats sharing hole-card information. The tell is not that they win; it is that they stop playing poker against each other. Pairwise aggression collapses while their aggression against everyone else holds. They soft-play heads-up and squeeze a third player between them.
• Chip dumping. Deliberate loss to move value between accounts — bonus abuse, or laundering with the rake as the fee. The tell is bet sizing no strategy explains. Drawn as a directed graph, net transfer between an account pair persists across sessions in one direction.
• Bots and real-time assistance. The tell is timing entropy. A human's decision time is a wide, noisy distribution that widens when the spot is hard and the pot is big. Solver-assisted play flattens it, or correlates it with the complexity of the decision tree rather than the money at stake. The second signature is volume without fatigue drift — humans get slower and looser late in a session. Software does not.

So the signals worth building are per-player action-timing distributions sliced by street, hole-card-conditional aggression (which you can compute and the player cannot see), a pairwise net-transfer graph, a shared-identity graph over IP, device and payment instrument joined to your KYC and AML records, and seat-selection behaviour — two accounts that keep arriving at the same table within seconds are describing their relationship for you.

Real-time, and built for the analyst

A nightly batch report finds the collusion after the withdrawal cleared, which is a recovery problem rather than an integrity one. The flag has to fire while the funds are still yours to hold — not to confiscate on suspicion, but to allow a graduated, reversible response: hold the withdrawal, freeze the seat, restrict the account.

Then a human decides, because none of these signals is proof. A tight player who folds to a friend is not a colluder. The system's job is to raise a scored, evidenced flag — hands, timings, graph edges — and put it in front of an analyst who has a replayer showing every hole card, a filter by account pair, an exportable evidence pack, and a record of who did what and why. You will be asked to show your process, not your accuracy.

Where the milliseconds go

A slot spin resolves server-side and 200ms of delay is invisible. Poker differs in kind: the action clock is public. Every seat watches how long you took, so a slow fold is a tell. Network jitter is therefore not a comfort issue — it leaks information about your players, and the information is false. Someone on a flapping mobile connection broadcasts hesitation they never felt.

Consistency beats the headline number. A room with a 40ms median and a 600ms 99th percentile is worse than a flat 90ms room, because the flat room lies to nobody. Budget on p99, not the mean.

The anatomy of one action

A fold, call or raise travels: client input, socket to the nearest edge, edge to the process owning the table, validation, state mutation, hand-history append, fan-out to every seat, render. Four places lose most of the budget.

• Distance. Light in fibre is the one constant you cannot engineer around. If the table process sits on another continent from the seat, the budget is gone before your code runs. Tables get regional affinity and the lobby routes on it.
• Hops. Every hop between the socket and the table's state costs. One process owns one table, single-writer, state in memory. No distributed lock per action, no database round-trip to work out whose turn it is.
• Persistence. Keep the disk write off the critical path: acknowledge from memory, append to an ordered log asynchronously. But the log must be durable before the hand settles to the wallet, or you have traded latency for a reconciliation incident.
• Pauses. A stop-the-world garbage collection freezes the whole table at once. That is a runtime and allocation-discipline choice made in week one, not something you tune in month nine.

Multi-tabling multiplies all of it: one player on twelve tables is twelve subscriptions and twelve fan-out targets, so the ceiling is set by sockets and message volume, not headcount. Size the room by concurrent seats and place the compute accordingly — the same reasoning behind our iGaming infrastructure work, and the reason poker and casino games do not belong on the same latency assumptions.

Liquidity is the product. Rake is the tax on it.

A slot works with one player in the building. Poker does not. What your player came for is other players, so your inventory is manufactured by your own demand. A player who opens the lobby, sees nothing at their stake and closes it has made the lobby emptier for whoever looks next. That compounds downward, and every dying poker room dies the same way. Software cannot manufacture players. It can stop you wasting the ones you have.

Concentrate, don't decorate

The instinct at launch is to offer every variant, every stake, every format. It is precisely wrong: forty tables running three-handed is a worse lobby than twelve running full, with the same players. Seating should actively consolidate — fill a table before opening the next, merge short tables, break tournament tables on a schedule. Run tournaments when your players are awake, not around the clock. Fast-fold pools are the strongest structural answer to a thin player base: seat the player at a new table the instant they fold, and a modest pool feels busy because nobody waits.

Shared liquidity is a per-seat problem

Pooling across your own brands, or across jurisdictions where the regulator permits it, is the other lever — and the engineering trap is treating it as a table-level setting. One table can seat players from several regulatory perimeters at once, each carrying their own deposit limits, responsible-gaming interventions, reality checks and reporting obligations. That is policy attached to the seat, evaluated per action. Design it in from the start; retrofitting it into a table engine that assumed one jurisdiction is a rewrite, and you will be doing it under a certification deadline. The same principle drives our multi-brand platform core.

Rake and rakeback are one model

Rake is not a revenue line in poker. It is the revenue. Raise it and the pool bleeds in the worst order: the winning players do the arithmetic first and leave, then the recreational players who were funding them have nobody to lose to, so they leave too. Rakeback and loyalty are a rebate, and the highest-volume players collect most of it — frequently the same winners the rake was quietly slowing down. So rake and rakeback are one model, per stake and per format, adjustable without an engineer. On a licensed network you pay a share of that rake: not a share of profit, not a fee against a milestone, but a percentage of the only money the product makes, for as long as it exists. That is the argument for owning the engine in its narrowest form.

Hand histories are the record you are judged on

Every hand must be reconstructible from a log, exactly, months later: seed commitment and revealed seed, deck order, every action with its server timestamp, stacks before and after, rake taken, and which rule resolved the pot. Append-only, hash-chained, so tampering is detectable rather than merely prohibited.

Three parties read it and want different things. A player disputing a hand wants it replayed. A regulator handling an escalated complaint wants evidence that your record is independent of your support team's opinion. Your analysts want to query across it. Cannot reproduce a hand exactly? You settle every dispute in the player's favour — the cheap outcome — and you have nothing to file when you are asked, which is not. The log is also an asset: your integrity models train on it and your rake decisions are tested against it. On somebody else's network it sits under somebody else's retention terms, and when the contract ends, so does your history.