Engineering notes
How the games are made fair, what a wallet integration actually has to do, and what the numbers on a game page mean. Written for the people who integrate rather than the people who buy.
- 7 min readProvable fairnessCrash
How a provably fair crash round is actually generated
A crash multiplier is derived from a hash of a server seed the operator committed to before the round, combined with a client seed the player controls. Publish the commitment first and anyone can check afterwards that the result was not chosen.
- 8 min readWalletIntegration
What a casino wallet integration actually has to do
Five endpoints: balance, debit, credit, refund and rollback. The only hard requirement is that debit and credit are idempotent on the transaction id you are given — everything else is detail.
- 6 min readGame mathsOperators
RTP, house edge and the number operators should actually check
RTP is the long-run share of stakes returned to players; the house edge is what is left. The number worth checking is not the advertised RTP but whether the running game reproduces it — which requires the operator to be able to see their own round history.
- 6 min readEngineeringIntegration
Idempotency in a betting API, and why the key is yours
The safest design gives the caller the idempotency key rather than generating one. If you mint the transaction id, a retry after a timeout is unambiguous — and a timeout is the one failure every integration eventually meets.
- 5 min readOperatorsCompany
Why we publish prices and hand out keys without a sales call
Every aggregator in this market asks you to book a demo before seeing anything. We publish the prices, the limits and the documentation, and issue sandbox keys instantly — because an integrator can evaluate an API far better than a salesperson can describe it.
There is an RSS feed.