How to Launch a Web3 Game in the EU: The Technical and Legal Checklist (2026)

What you'll learn

Every major technical decision — wallets, tokens, marketplaces, payment rails — has a corresponding legal obligation under MiCA.
MiCA applies based on where EU players are located, not where the studio is incorporated.
The moment real money or a token with market value enters your game, EU regulators have jurisdiction.
You have three viable launch paths: hold your own CASP licence, build on a licensed platform, or soft-launch outside the EU first.

Most web3 game launch guides stop at the technical layer. They cover wallet SDKs, smart contract patterns, marketplace integrations, and payment rails. They do not cover what happens legally when you flip the switch and go live in the EU.

That gap is not academic. It is the reason studios get blocked at the payment processor, lose access to banking, or find themselves on the wrong end of a National Competent Authority inquiry three months after launch.

This checklist runs both tracks in parallel — the technical decisions you are already making and the legal obligations that attach to each one.

Who this is for

Game developers who are mid-build on a web3 game, planning an EU release, and have not yet had a serious compliance conversation. You are thinking about shipping. This guide is for you.

How MiCA applies to games

MiCA (Markets in Crypto-Assets Regulation) is EU-wide law that came fully into force in 2024. It governs any entity that provides crypto-asset services to people located in the EU.

The key phrase: located in the EU. Not incorporated in the EU. Not registered in the EU. If your players are in Germany, France, or Spain, MiCA applies to you — regardless of whether your studio is in the US, UK, Singapore, or anywhere else.

The services covered by MiCA that are relevant to games:

Custody and administration of crypto-assets on behalf of clients
Operation of a trading platform for crypto-assets
Exchange of crypto-assets for fiat or other crypto-assets
Transfer services for crypto-assets
Receiving, transmitting, or executing orders related to crypto-assets

Any studio whose game includes one or more of these services needs a CASP licence (Crypto-Asset Service Provider authorisation) — or needs to operate under a platform that holds one.

Part 1: The technical checklist

1. Wallet integration

What you are building: Players need wallets to hold in-game assets. You are choosing between non-custodial wallets (players hold their own keys), embedded/custodial wallets (your platform manages keys on the player’s behalf), or hybrid approaches.

Decide on wallet model: non-custodial, custodial, or embedded with export
Choose your SDK (Openfort, Sequence, Dynamic, Privy, or custom)
Implement wallet creation flow for new players
Handle wallet recovery and account abstraction if applicable
Test gas abstraction / sponsored transactions if using account abstraction
Confirm which chains you are deploying on (EVM, Solana, Immutable X, etc.)

What this triggers legally:

If you manage wallets on behalf of players — meaning the player logs in with an email and your system holds the private key — you are providing custody of crypto-assets. That is a CASP-regulated service under MiCA Article 3.

Non-custodial wallets (where the player holds their own seed phrase) do not trigger CASP on their own. The moment you add a service layer on top — trading, transfers, fiat conversion — other CASP obligations attach.

KYC/AML obligation: Custodial wallet providers must run Know Your Customer (KYC) checks and maintain Anti-Money Laundering (AML) programmes. This means identity verification for players before they can transact, transaction monitoring, and suspicious activity reporting.

2. Token contracts and asset issuance

What you are building: Your game economy almost certainly includes tokens — in-game currency, governance tokens, utility tokens, or a combination. You are writing or deploying ERC-20/SPL contracts and defining token mechanics.

Define token types: fungible (ERC-20), non-fungible (ERC-721/1155), or both
Decide whether tokens are transferable outside the game
Write and audit smart contracts
Determine token supply, distribution schedule, and any burn/mint mechanics
Confirm whether tokens will have market value (tradeable on DEXs or CEXs)
Prepare a token whitepaper if applicable

What this triggers legally:

This is where studios most frequently miscalculate.

Most in-game tokens fall into one of three MiCA categories:

Utility tokens — tokens that provide access to goods or services. Subject to MiCA disclosure requirements including a published crypto-asset whitepaper for tokens issued to the public.
Asset-referenced tokens (ARTs) — tokens referencing other assets, currencies, or commodities for stability. Subject to stricter authorisation requirements.
E-money tokens (EMTs) — tokens referencing a single fiat currency. Require authorisation as e-money institutions.

A token that looks like pure utility — an in-game currency — can leave the utility category the moment it trades at a market price on an exchange. Once players can buy and sell it for real money, regulators see a crypto-asset with financial characteristics.

If you are issuing tokens to EU players and those tokens have market value, you need a whitepaper filed with your National Competent Authority before issuance.

3. NFT contracts and asset minting

What you are building: In-game items, characters, land, cosmetics, and collectibles — typically deployed as ERC-721 contracts (one token per unique item) or ERC-1155 contracts (batch-efficient, supports both fungible and non-fungible balances in a single contract). You are defining token metadata, storage strategy, minting mechanics, and royalty enforcement.

Choose NFT standard (ERC-721 for unique items, ERC-1155 for fungible/semi-fungible batches)
Define metadata schema and storage strategy (on-chain, IPFS, or hosted server)
Implement minting contracts with appropriate access controls
Decide on royalty enforcement (EIP-2981 or marketplace-specific)
Plan reveal mechanics if applicable (blind minting)
Audit contracts before launch
Document which NFTs are “unique” vs. collection-based (relevant for MiCA classification)

What this triggers legally:

MiCA technically excludes NFTs that are “unique and not fungible with other crypto-assets.” In practice, that exemption is narrower than most studios assume.

Regulators look at whether an NFT is genuinely one-of-a-kind or simply one of 10,000 similar items from a generative collection. Large collections of identical or near-identical assets — skins, avatars, item variants — can fall within MiCA scope because they behave like fungible assets regardless of what they are called. The classification question turns on the economic substance of the token, not the label.

Marketplace interaction: If your NFT collection is tradeable on a marketplace — covered in the next section — the CASP obligation for operating that marketplace applies independently of how the NFTs themselves are classified. NFT exemption under MiCA does not exempt the platform facilitating the trade.

Metadata and player protection: Most NFT metadata is stored off-chain — on IPFS or a regular server. If that server goes down, the NFT’s pointer to its image, stats, and attributes is broken. For game items this is a real player protection issue, not just a technical risk. Regulators in several jurisdictions are beginning to treat metadata durability as a consumer protection question, particularly for items players have purchased.

Whitepaper requirement: If your NFTs are classified as crypto-assets under MiCA rather than purely unique NFTs, a crypto-asset whitepaper must be filed with your National Competent Authority before any public offering. Studios issuing large generative collections should get a legal opinion on classification before launch, not after.

4. Marketplace

What you are building: An in-game marketplace where players list, buy, and sell NFTs or tokens — either player-to-player or via a game-controlled shop.

Choose marketplace model: primary sales only, P2P secondary market, or both
Implement listing, bidding, and settlement smart contracts
Decide on fee structure and royalty enforcement
Handle currency: native token, stablecoin, ETH, or fiat
Integrate price oracles if needed
Test settlement and escrow flows end-to-end

What this triggers legally:

A player-to-player marketplace where crypto-assets are traded is an operation of a trading platform for crypto-assets under MiCA. That is one of the core CASP-regulated services.

Running an unlicensed marketplace with real crypto-asset value is not a grey area. It is a straightforward MiCA violation in the EU.

Transfer of Funds Regulation (TFR): Any CASP processing crypto transfers must also comply with TFR — the EU’s implementation of the FATF Travel Rule. Transfers above threshold require originator and beneficiary information to travel with the transaction. A licensed platform handles TFR at the infrastructure level; a studio building its own marketplace inherits this obligation.

5. Payment rails (fiat on-ramp and off-ramp)

What you are building: Players need a way to buy in-game currency or assets with real money (credit card, bank transfer) and potentially cash out earnings.

Choose on-ramp provider (MoonPay, Transak, Ramp, or custom)
Implement fiat-to-crypto flow in the game client
Decide whether players can cash out (off-ramp) to their bank
Handle regional payment method requirements (SEPA for EU)
Test edge cases: charge-backs, failed transactions, partial fills

What this triggers legally:

Fiat on-ramp providers are themselves regulated entities. They perform KYC on behalf of their partners. But your game’s integration with them creates obligations too:

Money transmitter rules apply when your platform facilitates movement of value between players
Off-ramp (player withdrawing real money from the game) is the highest-scrutiny activity — it is the clearest signal to regulators that you are operating a financial service
Payment processors and banking partners increasingly require proof of compliance before onboarding web3 games. Without a CASP licence or a licensed platform layer, you may be denied access to payment processing entirely

6. Analytics and transaction monitoring

What you are building: You need visibility into your game economy — player behaviour, token velocity, marketplace volume, suspicious patterns.

Instrument blockchain events alongside game events
Track wallet activity and transaction volume per player
Set up alerts for unusual patterns (wash trading, bot activity)
Retain transaction records in a queryable format

What this triggers legally:

Under MiCA and AML5/AML6 directives, CASPs are required to:

Monitor transactions for suspicious activity
Retain records for a minimum of five years
File Suspicious Activity Reports (SARs) with their Financial Intelligence Unit
Conduct ongoing due diligence on high-risk customers

This is not optional analytics. It is a regulatory obligation. A platform integration that includes transaction monitoring handles this at the infrastructure level. A studio building its own stack owns it.

Part 2: What “launching in the EU” specifically means

The EU is not one country. It is 27 member states with a single regulatory framework.

What MiCA gives you: One CASP licence from any EU National Competent Authority gives you the right to provide services across all 27 member states. This is called passporting. It is one of MiCA’s major advantages over the US model, where you face state-by-state licensing.

What MiCA does not cover: The UK, Switzerland, and Norway are not in the EU. They have separate frameworks. An EU CASP licence does not extend to UK players.

When does the obligation start? The moment you accept real money from EU players or process a transaction involving a crypto-asset on behalf of an EU player. Not at incorporation. Not at launch announcement. At first transaction.

What counts as “targeting” EU players? Active marketing to EU residents, pricing in EUR, support in EU languages, app store presence in EU markets. Any of these signals that you are offering services in the EU.

Part 3: The three launch paths

You have three viable options. Choose based on your timeline, budget, and risk tolerance.

Path 1: Full independent compliance

Obtain your own CASP licence. Build your own KYC/AML stack, transaction monitoring, and compliance function.

Who this is for: Well-funded studios with a 12–18 month pre-launch runway, existing regulatory relationships, and the budget for €500K–€1M in year-one compliance costs.

Realistic timeline: 6–12 months to obtain the licence after submitting a complete application to an EU NCA. Add 3 months minimum for preparation. Total: 9–15 months before you can go live in the EU.

Ongoing cost: €200K–€500K per year for the compliance function (staff, audits, reporting).

Upside: Full control over your compliance stack. No revenue share with a platform. Maximum optionality.

Path 2: Build on a licensed platform

A licensed infrastructure provider holds the CASP licence and provides the regulated services — custody, marketplace, payments, KYC/AML, Travel Rule — as a platform layer. You integrate via SDK and operate within their regulatory perimeter.

Who this is for: Studios that want to launch in the EU without the 12-month licence queue or the seven-figure compliance budget. Most indie and mid-market studios.

Realistic timeline: Integration timeline (weeks to months depending on complexity) rather than licence acquisition timeline.

Tradeoff: Revenue share or platform fees. Less direct control over the compliance stack. Dependency on the platform’s licence remaining in good standing.

Genesis Engine is pursuing the CASP licence in Sweden (Finansinspektionen) and provides regulated infrastructure as a platform layer for web3 game developers.

Path 3: Soft-launch outside the EU first

Launch in markets with lighter regulatory requirements. Build revenue, player base, and product validation. Use that to fund a proper EU compliance effort.

Common soft-launch markets: Southeast Asia, Middle East (UAE has a relatively clear virtual asset framework), Latin America.

What to avoid: Do not geo-block the EU and then accept EU players via VPN anyway. Regulators look at actual player locations, not geo-block configurations.

Timeline to EU: 12–24 months post-initial-launch, depending on revenue growth and compliance investment.

This is a legitimate strategy. The EU represents an estimated 100 million potential players and the most valuable single regulated market for web3 gaming. Delaying that market should be a deliberate decision with a clear timeline back to it — not indefinite avoidance.

Part 4: Timeline — before go-live vs. after

Not everything needs to be solved before day one. Here is what the sequence actually looks like.

Must happen before go-live in the EU

CASP licence obtained (or confirmed platform licence covers your services)
KYC/AML programme documented and operational
Crypto-asset whitepaper filed with NCA (if issuing tokens publicly)
AML officer and compliance officer appointed (or platform confirms coverage)
Transaction monitoring active
TFR compliance confirmed
Capital reserves locked (if holding licence independently)
Player terms of service updated to reflect regulated services
Data retention policy covering 5-year minimum for transaction records

Can follow after go-live (with caveats)

Full Travel Rule automation (manual processes can cover low-volume early launch)
Expanded KYC tiers (enhanced due diligence for high-value players can be phased)
Cross-border tax reporting infrastructure (required but can be built out post-launch)
Regulatory capital optimisation (initial reserves can be conservative, adjusted later)
Full audit trail tooling (foundation must exist, full automation can follow)

The “can follow” items are not optional forever — they are obligations with timelines. The window for manual processes at scale is short.

The common mistake

Most web3 game studios treat compliance as something to handle after launch. The rationale is understandable: get the product working first, then clean up the legal side when there is revenue to fund it.

Regulators do not agree with this timeline.

The moment you accept real money or process a transaction involving a token with market value on behalf of an EU player, MiCA applies. Not when you decide to take compliance seriously. At first transaction.

Studios that launch first and comply later face retroactive exposure, potential fines, and — more practically — payment processors and banks that will not work with them until they demonstrate compliance. That is a business problem, not just a legal one.

The developers who are getting this right are treating compliance as infrastructure. Not a checkbox. Not a legal department problem. Infrastructure that they either build themselves or procure from a platform that has already built it.

FAQ

Does MiCA apply based on where my studio is incorporated?

No. MiCA applies based on where your players are located, not where the studio is incorporated or registered. If your players are in Germany, France, or Spain, MiCA applies even if your studio is in the US, UK, Singapore, or anywhere else.

When does the MiCA obligation actually start?

It starts the moment you accept real money from EU players or process a transaction involving a crypto-asset on behalf of an EU player. Not at incorporation, not at launch announcement, but at first transaction.

Do custodial wallets trigger CASP requirements?

Yes. If you manage wallets on behalf of players, meaning the player logs in with an email and your system holds the private key, you are providing custody of crypto-assets, which is a CASP-regulated service under MiCA Article 3. Custodial providers must also run KYC checks and maintain AML programmes. Non-custodial wallets where the player holds their own seed phrase do not trigger CASP on their own.

What are the three viable paths to launch in the EU?

You can hold your own CASP licence and build your own compliance stack, build on a licensed platform that holds the CASP licence and provides regulated services via SDK, or soft-launch outside the EU first to build revenue and validation before funding a proper EU compliance effort.

What is MiCA passporting?

Passporting means one CASP licence from any EU National Competent Authority gives you the right to provide services across all 27 member states. It is one of MiCA’s major advantages over the US model, where you face state-by-state licensing. It does not extend to the UK, Switzerland, or Norway, which sit outside the EU.

For a deeper look at the licence itself, see CASP Licensing for Web3 Game Developers: A Practical Guide.

For the full MiCA regulatory context, see MiCA Compliance Guide for Web3 Game Studios.

For an overview of what regulated infrastructure looks like in practice, see Genesis Engine.