Can blockchain solve the regulatory grey zone? Only part of it.

The same user experience can look like trading in one jurisdiction and gaming in another

The line between trading, prediction markets and gaming is becoming increasingly difficult to draw.

A user watching a live Bitcoin chart, selecting a future price range and committing capital to that view would probably describe what they are doing as trading. A financial regulator looking over their shoulder asks a different question: is this product a derivative, an event contract, or some other regulated financial instrument?

An iGaming regulator, looking at almost the same interface, asks questions that have nothing to do with instrument classification at all. What determines the outcome? Is a random number generator involved? What is the theoretical return to player? Can the operator influence the result? How is the price feed certified? What happens when connectivity fails? Can every result be independently reproduced?

So the challenge for a new generation of market-powered products is only partly technical. Most of it is regulatory architecture, and blockchain can supply part of the answer, as long as we are clear about which part.

Financial and gaming regulators approach the same product from opposite directions

Financial regulation tends to work from the outside in: it starts with what the instrument is, who operates the market and who holds the money. Gaming regulation works from the inside out: it starts with the mechanism that produces the result and asks whether that mechanism is fair, certified and tamper-proof.

None of this means financial regulators ignore the product. The U.S. CFTC treats many event contracts as derivatives and requires regulated markets to address market integrity, contract terms and susceptibility to manipulation.¹ Europe has a parallel classification problem: MiCA expressly excludes crypto-assets that qualify as financial instruments, which means the first question is often what the product actually is, rather than whether a blockchain is involved.²

Gaming regulators and their testing laboratories go somewhere financial regulators rarely do: inside the game. GLI provides testing for game mathematics, RTP, RNGs, remote game servers and event-wagering systems.³ GLI-19 requires RNG implementations that determine monetary outcomes to be independently evaluated and prohibits adaptive alteration of RNG-selected results.⁴ The UK Gambling Commission's technical standards address RNG fairness and even network latency where speed affects a player's chance of winning.⁵

That leaves market-powered games with an awkward question:

The product should not have to choose between trust models

Consider the simplest market-powered interaction. Bitcoin is moving across a live chart. The user selects a box representing a future price range and a future time window. If the market enters that box during the window, the position wins at the payout shown when the Tap was accepted.

The interface is easy to understand, but the regulatory status is not. Is this trading, event wagering, gaming, a financial derivative or a virtual event? The answer changes with the jurisdiction, with how the product is built, and even with which outcome engine sits underneath the chart.

Blockchain cannot answer that legal question. What it can do is something more practical:

Five things a regulator has to trust, and how each one becomes verifiable

Instead of asking either the financial regulator or the gaming regulator to trust the operator's internal database, the critical parts of a market-powered product can each be made independently verifiable. They follow the life of a single Tap: the money comes in, the intent is recorded, the market moves, the result is computed, and someone checks the work.

1Custody

Traditional gaming architecture runs Player → Operator deposit → Internal balance → Game → Withdrawal request. Every step after the deposit lives in the operator's ledger, and the operator's hot wallet and balance database become the two most valuable targets in the business.

A non-custodial architecture runs Player wallet → Smart contract → Game session → Settlement → Player wallet. The user never transfers ownership of their whole balance to the platform; the contract limits how much capital is available to a session and sets the rules under which it can move.

This does not automatically dissolve financial, gaming, AML or consumer-protection obligations. But it removes one important source of uncertainty, who controls the money, because the answer is written in the contract itself.

Where the key lives: embedded wallets

"Non-custodial" used to mean asking a mainstream user to install a browser extension and guard a seed phrase. That is no longer the trade-off. Embedded-wallet infrastructure such as Privy lets a player sign in with email, a social account or a passkey and receive a wallet that is generated on their device, while the platform still never holds a usable private key.

The mechanism matters for the security argument. The key is split into shares: one held on the user's device, one released only after the user authenticates, and an optional recovery share the user controls. The shares are reconstituted only inside an isolated execution environment, for the duration of a signature, and are never exposed to the application. Market Games, or a white-label operator running Tap Trading, can see the wallet address and the signed Taps. It cannot sign on the player's behalf, and neither can the wallet provider acting alone.

For a high-frequency product, the second piece is scoped session signers. Instead of a wallet prompt on every Tap, the player authorises a session key that may call only the Tap contract, only up to a committed collateral amount, only until a stated expiry. The UI feels like a Web2 game. The permission is the size of one session, not the size of the account.

How this changes platform security

A common misreading of non-custodial design is that it makes the platform "safer" in some general sense. It doesn't. What it changes is what has to be secured, and how much is at stake when something fails.

In the custodial model, the platform is a bank without a banking licence: one pooled hot wallet, one balance table, and a set of employees and servers with the ability to move both. A breach of the platform is a breach of every player at once. In the non-custodial model the pool does not exist. A compromise of Market Games' servers could degrade service, corrupt the front end or feed bad data. Those are serious problems, but they are bounded ones. It cannot drain player accounts, because there is no account to drain.

The right-hand column shows the shift. The catastrophic, everyone-at-once failures of the custodial model become bounded, per-session failures. In exchange, three new responsibilities move to the centre of the security programme: the correctness of the contracts, the integrity of the market-feed signing keys, and the integrity of the code that asks players for permissions.

We think that is a better trade. The new risks are public: contract code, signer addresses and permission scopes are all visible, so auditors, testing laboratories and the wider security community can inspect them instead of taking the operator's word about the state of an internal database. They are also capped. Session limits, expiries and player-initiated exit put a hard ceiling on how bad any single failure can get.

There are two caveats. Embedded wallets move some trust to the wallet infrastructure provider, so the platform should be able to show a regulator what that provider can and cannot do without the user. And none of this applies to the Tap Markets API product, where the licensed casino operator remains the custodian and the usual segregation-of-funds, security and audit obligations apply unchanged. Non-custodial custody is a Tap Trading property. It is what lets a crypto-native product answer the financial regulator's first question by pointing at a contract instead of a promise.

2Immutable player intent

When a player selects a market box, the exact terms of the Tap can be cryptographically recorded at the moment of acceptance:

Once the Tap is accepted, none of those parameters can be revised because the market later moved in an inconvenient direction, for the player or for the operator. The record draws a hard, cryptographic line between what was agreed and what happened afterward.

3Provable market data

This may matter even more than putting the wager on-chain. Market Games aggregates prices from multiple independent trading venues into a high-frequency market path. That feed does not need to originate on a blockchain. Forcing every market movement through an on-chain oracle would make the price path slower and poorer. The feed can stay fast and off-chain while producing cryptographically signed market records:

Thousands of these records are grouped into a Merkle tree and the root is periodically committed to a public blockchain. The chain does not store every price tick. It establishes one thing, and it is the thing that matters:

4Deterministic settlement

Once the rules, the market data and the player's selection are fixed, settlement stops being a judgement call and becomes arithmetic. The formula differs by outcome engine, but the shape is the same:

The principle is the same in every case:

Blockchain turns that principle from a policy statement into something a third party can test.

5Independent verification

A player, an auditor, a testing laboratory or a regulator should be able to take any completed Tap and answer, without asking the operator: What did the user select? What market data existed? Which algorithm version applied? Was randomness involved? What was the result? Was the settlement calculated correctly?

Today's default is trust the platform because the platform says its result was correct. The point of this architecture is to replace it with something else: verify the result independently.

The same proof layer can serve two very different regulatory classifications

This architecture becomes useful in practice when the market-facing product is split into two offerings that share infrastructure but not a regulatory wrapper.

A shared proof layer without a shared classification

Both products can commit to the same cryptographic infrastructure (market-data commitments, Tap commitments, algorithm versions, RNG proofs where randomness is used, and settlement records) while remaining two legally different things.

The blockchain does not have to execute every Tap

A player may make dozens or hundreds of Taps in a session. Pushing each one through a conventional blockchain transaction would add cost and latency without any regulatory benefit. The chain is used only where it adds something: custody, proof, immutability and settlement.

One Tap interface, several regulatory wrappers

This is where the architecture pays off. Take a single Tap interface deployed across four regulatory environments. The consumer product stays the same, and the engine and the wrapper change.

Design for regulatory separation, not around it

Companies usually approach this problem backwards. They design the product first, and then lawyers and certification laboratories try to fit the finished thing into either financial regulation or gaming regulation. Something usually has to be cut.

The better approach is to design the technology itself around regulatory separation, so that the architecture can answer each of the questions regulators actually ask, independently and without reference to the others:

Blockchain is well suited to answering those questions. It has nothing to say about the questions of legal classification.

What blockchain does not solve

Putting something on-chain does not automatically make it:

A regulator will continue to look at the economic substance of the product. In Europe, whether something is a financial instrument remains the operative question regardless of the technology, and MiCA expressly carves such instruments out of its scope.² In the United States, the CFTC continues to treat many event contracts as derivatives and is actively developing its regulatory approach to prediction markets.⁶

Gaming regulators will continue to demand game fairness, transparent rules, appropriate testing and technical controls. The UK Gambling Commission requires that rules be available before gambling begins and sets specific requirements for time-critical games where network latency can affect a player's chance of winning.⁷

Blockchain does not replace any of that.

From "trust us" to "verify us"

Financial markets have traditionally relied on regulated intermediaries. Online gaming has traditionally relied on certified centralised systems. Market-powered games sit between those worlds, and a cryptographically verifiable architecture creates a third possibility: a system in which regulators, operators and players do not need to rely exclusively on the platform's own version of events.

The market data, the wager and the randomness can all be verified. The game rules are versioned, the settlement can be reproduced, and the funds stay under clearly defined control.

None of this eliminates the regulatory boundary between trading and gaming.