gamblingconsultant.io Andrew Lindley · Gambling industry adviser
Fireblocks

How to design casino treasury on Fireblocks: vaults, policies and automation

A practical guide to Fireblocks for online casinos — deposit, hot and treasury vaults, policy ordering, API Co-signers, Gas Station and automated sweeping — from an operator who has deployed it.

By Andrew Lindley · · 3 min read

In 2026 I implemented Fireblocks for a newly launched online casino as an alternative to traditional payment and treasury rails. The technology is strong, but a Fireblocks deployment is only as safe as its design. Most of the work is deciding how money should move, then making the system enforce it.

This is the structure I recommend for a casino.

Example vault structure for an online casino on Fireblocks Players deposit into public-facing deposit vaults, which sweep into an omnibus vault inside a private core. A treasury vault in the core takes daily gross gaming revenue and repays the omnibus vault if revenue is negative. Hedging and liquidity vaults connect the core to outside providers. A withdrawal vault pays players. Company and capital deposits come in through a deposits vault, and payments to suppliers and shareholders go out through an outgoing vault. Fireblocks workspace Outside the core:public-facing vaults,visible on-chain Private core Playersdeposit Playerswithdraw Hedging provider Liquidity provider Company account Capital providers Suppliers Shareholders Deposit vaultUTXO coins, commingled Deposit vaultsNon-UTXO, one per player Hedging vault Liquidity vault Withdrawal vaultPlayer payouts Deposits vault Outgoing vault Omnibus vaultPlayer funds, pre-treasury sweep Treasury vaultDaily movement of GGRRepays omnibus if GGR is negative Platform automation Fireblocks automation (can start manual) Manual, under approval
Example: vault structure for an online casino. Public-facing vaults are visible on-chain, so the main balances sit in a private core that is only reached through staging vaults. Every movement is still recorded internally for audit, AML and regulators.

Start with how casino money moves

A casino has three very different flows:

  • Inbound: many small player deposits, at all hours, across several chains and tokens.
  • Outbound: player withdrawals that need to be fast, because slow payouts kill trust.
  • Treasury: the bulk of the funds, which should move rarely and only under strict control.

Each flow needs its own vaults and its own rules.

The vault structure

Fireblocks vault accounts are wallets whose keys are secured with multi-party computation (MPC), so no single device or person ever holds a whole key (Fireblocks). For a casino I use three layers:

  1. Deposit vaults. Each player gets their own deposit address, so every deposit is attributable.
  2. Hot vaults. Hold only what is needed for withdrawals over a short period.
  3. Treasury vaults. Omnibus accounts holding the bulk of funds, kept apart from day-to-day operations in a ring-fenced liquidity pool.

Policies: write them like a lawyer

Fireblocks policies decide which transactions are allowed, blocked or sent for approval, based on who starts them, where funds come from and go to, and how much is moving. Rules are checked in order, so the most restrictive rules should come first (Fireblocks).

My approach:

  • Block by default. Anything not explicitly allowed fails.
  • Treasury can only send to whitelisted internal vaults, never directly to external addresses.
  • Hot wallets can pay players, within per-transaction and daily limits.
  • Anything over a limit, or to a new destination, needs approval from more than one person.

API Co-signers: automation without a single point of failure

Automation needs something to sign transactions without a person tapping a phone. That is the API Co-signer: software you host yourself in a secure enclave, such as AWS Nitro Enclaves, Azure with Intel SGX, or Google Cloud Confidential Space (Fireblocks).

The important part is the callback handler. Before the co-signer signs, it asks your own server whether the request is legitimate. Your server checks it against your business rules — does this withdrawal match a real, approved player request? — and can reject it. If the handler does not answer within 30 seconds, the request fails. That gives you a second, independent check on top of the Fireblocks policies.

Automations that keep it running

  • Sweeping: deposits move automatically from player deposit addresses into the omnibus treasury.
  • Hot wallet top-ups: treasury refills hot wallets within set limits, so withdrawals keep flowing.
  • Gas: Fireblocks Gas Station automatically funds vaults with the base asset needed to pay network fees on EVM chains and TRON (Fireblocks).

Privacy and auditability together

Treasury addresses do not need to be publicly linked to your brand. Keeping them separate makes you a harder target. But every movement must stay fully recorded internally, so you can show auditors, banks and regulators exactly where funds went.

Common mistakes I see

  • Hot wallets holding far more than a day or two of withdrawals.
  • One admin able to change policies and approve transactions.
  • Co-signers deployed without a callback check, so they approve everything.
  • No testing of what happens when the automation fails.

If you are planning a deployment or want an independent review of an existing one, see Fireblocks for gambling operators or get in touch.

Fireblocks is a trademark of its owner. I am independent and not affiliated with Fireblocks.

Sources

Andrew Lindley
Andrew Lindley

Gambling industry business adviser. Holds a solicitor's practising certificate but does not give legal advice through this business. Co-founder of Lottoland and Lot.to, former CEO of Sportech plc and former General Counsel of the Tote. More about Andrew

Related insights