Market Games / Insights / Built to Be Verified
Insights · Perspective

Built to be verified. Why fairness in market-powered games has to be proof, not a promise.

Casino fairness has always been a certificate. A laboratory tests the random number generator, the operator frames the badge, and the player is asked to trust it. Market-powered games change the question. When the outcome is a real price, the player deserves to see the price, the exact tick their bet ran on, and evidence that nobody rewrote it afterwards. This is how we think about that, and how we built it.

Market Games titles on floating panels: Tap Markets, Market Race, DigitX, Turbo Markets and High/Low, with a finger about to tap a multiplier box
Every title in the Market Games lineup settles on a market path. The question a player should be able to answer is the same for all of them: was that the real path, and was it the one my bet ran on?
Section 1

Trust is the product

In trading-style gaming, trust is not a compliance line item. It is the thing being sold. A player who taps a box over a live chart is making a small, fast decision about where a price is going. The entire experience rests on one assumption: that the price on the screen is the price that decided the round, and that nobody could nudge it after the fact.

Most platforms in this space still operate like a black box. A price moves, a bet is placed, a result appears. The player is expected to believe the outcome was fair because the operator says so, because a licence hangs in the footer, or because a testing lab signed off on a random number generator a year ago. All of those things matter. None of them show the player anything about the round they just played.

That gap is where suspicion lives. Every "the price never touched my box" support ticket is a player who could not check, and so assumed the worst. Every crash-game controversy of the last few years followed the same shape: a result the player could not reproduce, and an operator asking to be believed.

Don't trust the result. Verify it.
Section 2

What "provably fair" got right, and where it stops

Crypto casinos deserve credit here. The provably fair pattern, in which the operator commits to a hashed server seed before the round, the player contributes a client seed, and the outcome is derived from both, has been standard for a decade. It let players recompute a dice roll or a crash multiplier themselves, and it moved fairness from a certificate to a calculation.

It also has a boundary. Provably fair proves that a random number was not tampered with. It says nothing about a price. When a game settles against the real Bitcoin index, there is no seed to commit to. The "randomness" is the market itself, arriving tick by tick from outside the game. A player asking whether the feed was honest is asking a question provably fair was never designed to answer.

Our synthetic titles, the certified-RNG line, use the provably fair pattern in full: a committed seed, a generated market path, a box touch and a settlement that anyone can replay. For the real-price titles we needed something else. We needed the same standard applied to a live feed.

Section 3

Three questions a real-price game has to answer

Strip the problem down and a player, an operator's risk team, and a regulator are all asking the same three things.

Was this the real price? Not a single exchange, not a feed the operator can edit, but a composite of approved venues with filters for outliers and stale ticks, and a rule that bad data voids the round rather than being quietly repaired.

Was it the price my bet was placed on? A game can have an honest feed and still be unfair if a bet can be silently moved to a friendlier tick. The bet has to be pinned to one specific update at the moment of acceptance.

Could anyone change it afterwards? A record that can be edited after settlement is not a record. Whatever the player sees must be tamper-evident, and the evidence has to be available to them, not only to an auditor months later.

Rate Integrity is our answer to all three. It is the fairness layer under the Live Markets titles, and the rest of this article is about how it works and what it looks like on the player's screen.

Section 4

Fingerprint every price. Chain every fingerprint.

The mechanism starts the instant a price update reaches the server. Before it is used for anything, the server computes a SHA-256 fingerprint of the update: the instrument, the bid, the ask, the rate and the timestamp. Crucially, the fingerprint also covers the fingerprints of the five updates before it.

hash = SHA-256(instrument | bid | ask | rate | timestamp | prev1 … prev5)

That last detail is what turns a list of hashes into a chain. Each fingerprint depends on its neighbours, so altering, removing or inserting a single price would break the fingerprints of everything that followed. The fingerprint then travels with the quote to the game client. It is not computed on the player's device; it is received from the server exactly as the server produced it, and displayed as is.

Because new updates keep arriving, the chain keeps growing. Any attempt to rewrite history would have to outrun a live market that adds new links every few hundred milliseconds. In practice, that means the record seals itself as it is written.

Section 5

Your bet names its tick

An honest feed is necessary but not sufficient, so the second half of the design is about the bet. When a player taps, the bet is opened against one specific price update, identified by its time and its fingerprint. That claim is recorded with the bet and is checked by the engine before it prices the cell.

The consequence is simple to state and important in practice. A bet cannot be quietly moved to a different tick, because the tick it names is part of the bet. The claim is visible on the result screen, next to the payout the client computed and the payout the server settled. If those two numbers ever disagreed, the player would be the first to know.

Section 6

Put the proof where the player is

None of this is worth much if it lives in a database an auditor visits once a year. So the proof is on the result screen, one tap away from the outcome it explains.

Open any completed bet and the chart is split into three windows: the price updates before the bet, the updates the bet ran on, and the updates after it. Each window lists its updates with the server's fingerprint on every row. The update that entered the player's cell is highlighted with its exact time and price, so the payout traces back to one visible event.

Below that sits a button labelled "Recompute hashes and verify". It re-derives every fingerprint in the browser from the server's price record and checks the specific update the bet claims. A counter next to it shows how many later updates have arrived since the bet, each one locking the earlier ones in further. And the Claim and Payout rows show the tick the bet was opened on, and the client and server settlement side by side.

The design principle behind the screen is that the game never asks to be believed. Every hash shown is the server's. The screen never computes one on its own, and it never hides the ones that matter.

Anything that affects player money should be independently verifiable.
Section 7

Why operators should want this

It is tempting to file all of this under compliance. We think it is a commercial argument first.

Disputes end with evidence. The most common complaint in any price-based game is that the price never reached the box. With Rate Integrity the answer is on the player's own screen: the tick, its time, its fingerprint, and a recompute that either passes or fails. Support conversations get shorter and less emotional.

It is a visible difference in the lobby. Crash and slots ask players to trust the feed or the RNG. A game that lets players check the feed is a different proposition, and one that is easy to explain in a sentence. In a category where several suppliers now offer tap-to-trade mechanics, fairness that can be shown rather than claimed is a real point of separation.

Regulators and laboratories get an audit trail, not an assurance. From market data to player action to claim to settlement, every step is recorded, fingerprinted and replayable. A lab can reproduce a round without asking us. So can an operator's own risk team.

Section 8

What is still ahead

We would rather describe the system as it is than as it will be. The hash chain makes the tick record tamper-evident today, and the verification screen is live in our reference deployment. The next step is to seal each day's record into a block and anchor it outside our own infrastructure, so that even the operator of the server could not rewrite history without leaving a trace. That work is in development and will ship with the server-anchoring release.

On the synthetic side, the certified RNG line continues to prove fairness the way regulated casino games do: a committed seed, certified mathematics, a published RTP and a replayable round. Two engines, two proofs, one standard.

Section 9

Built to be verified. Not built to be trusted blindly.

This is bigger than a feature. It is the principle across Tap Trading, Tap Markets and everything we build next: anything that affects player money should be independently verifiable, by the player, at the moment it matters.

Fairness certificates were the right answer for a generation of games whose outcomes came from a sealed random number generator. Market-powered games bring the outside world into the round, and with it a new obligation. If the market is the game, the player should be able to check the market. We built Market Games so they can.

Every price. Every tap. Every outcome. Verifiable.

Further reading
  1. Market Games, Verifiable by Design: Rate Integrity. The fairness page, including the regulator's checklist and the hash-chain diagrams.
  2. Market Games, Tap Trading. The real-price title that carries the Rate Integrity panel on every result.
  3. Market Games, Reference deployment. Place a bet, open the result, recompute the hashes.

Product details describe the Market Games reference deployment as of 8 September 2026. Sealed daily blocks and external anchoring are in development and are described as such above.

See it live

Place a bet. Open the panel. Check the chain.

The reference deployment runs the same engine and the same Rate Integrity panel your players would get. We can also walk your compliance team through the checklist.

Book a Demo