Build it
Twelve to eighteen months, a games team, a payments team, and an odds engine you must get provably right before one player trusts it.
Eight games, crypto deposits that credit themselves, and a back office your own team runs. Live in a day, because nothing gets rebuilt to make it yours.
Every screen on this page is the real product, photographed — not a mockup.
Twelve to eighteen months, a games team, a payments team, and an odds engine you must get provably right before one player trusts it.
Your logo in the header, someone else's name in the wallet screen, and your
players in a shared table with a column marked operator_id.
Fast, but you do not own the brand, the domain, the player relationship or the data — and you cannot take any of it with you when you leave.
Name, logo, compact mark, favicon, support link, Telegram bot name — and eight theme colours. Brand art renders at sixteen places across seven games, and every one of them follows what you set: the header, the sidebar, the sign-in card, the loading splash, and the felt under every table.
Nothing is rebuilt. Nothing is redeployed.
Set in your own console. Applied on your players' next page load.
Players reach you at your address. Your Telegram Mini App is signed by your bot token, so sign-in, the welcome message, the daily nudge and your own operator alerts all come from your bot. Nothing your players see or receive carries our name.
Not a shared table with a tenant column. A separate Postgres database per partner. The platform refuses to start if two brands are ever pointed at the same one — that check exists precisely so the isolation cannot quietly stop being true.
Your players, balances and history are in a database only your brand can reach.
USDT on six chains. Every player gets their own permanent deposit address, so an incoming transfer identifies itself and credits without anybody confirming a hash. Manual confirmation stays available as the fallback — never as the default path.
Your staff sign in to your console, not ours.
One engine decides every result, and it is the same engine across the platform — which is what makes the odds consistent and auditable rather than a per-brand improvisation. Your house edge is tuned per operator; the mechanism is shared.
Most white-label separation is a promise. Here it is a property of how the thing is built — and each of these is checkable.
No shared player table. No tenant column. No row that belongs to two brands.
The platform refuses to boot if two entries share one. There is no shared
table where a missing WHERE clause becomes somebody else's players.
A request arriving on a domain nobody has registered is refused outright. There is deliberately no "fall back to the first brand" branch — because a sensible-looking fallback and a cross-brand leak are the same line of code.
Each brand's session tokens are signed with a key derived for that brand. A token from one site does not merely get rejected by another — it was never valid there.
Your own engine operator, your own signing secret, your own bot token, your own deposit wallet. If one partner's key is ever compromised, it is one partner's key.
Settle the rate and buy your opening credits.
One action in our console creates your operator, arms your account and prints your configuration.
Point your domain, connect your bot, set your brand. Between step two and a live site is DNS propagation and however long it takes you to upload a logo.
You buy credits up front at an agreed rate. Credits are consumed by wagered volume, not by your revenue — so what you owe is knowable in advance, and never a surprise share of a month you have already spent.
Every purchase and every consumption is a ledger entry. The balance is the sum of the ledger, and that equality is asserted continuously — a disputed invoice is answered with rows, not with an assurance.
The console shows days of runway. A balance alone says nothing: fifty thousand credits is a fortnight or an afternoon depending on how busy you are.
Credit is checked when a round opens and consumed when it resolves, so a float running dry mid-session never strands a player mid-bet.
| You | Us | |
|---|---|---|
| Your brand, logo and colours | ● | |
| Your domain and Telegram bot | ● | |
| Deposits and withdrawals — decisions | ● | |
| Your players and their history | ● | |
| Pausing and starting your tables | ● | |
| Your own activity log | ● | |
| Games, odds engine, fairness | ● | |
| Platform, hosting, updates | ● | |
| Chain infrastructure and node access | ● | |
| Treasury and settlement custody | ● |
No. Your players, balances, deposits and history live in a database only your brand can reach. What is shared is the engine that decides results and the infrastructure that runs it — the same way two banks share Visa.
The platform is shared, so an outage would be shared. The mitigation is structural: the part that serves your site scales horizontally and is separate from the part that runs the game loops, so the common failure takes rounds offline rather than your whole site.
Your database is yours. Export terms and notice periods are part of the agreement, and we would rather settle them before you sign than after you want to leave.
We do, per operator, and you can see the effective return in your console. Partner staff cannot change the house edge — which protects you as much as us, because it means nobody on your team can quietly change what your game pays.
Anyone who needs to own the odds engine, and anyone who needs to hold their own settlement keys. Both are ours, deliberately, and no arrangement changes that.
That is jurisdiction-specific and it is yours to answer with your own legal advice. Nothing here confers a licence or an opinion about legality in any particular market.
You have the audience and no product to send it to.
You want a second brand without a second build.
Mini App sign-in means no app store, no install, no password.
See a brand that is already running, then decide.