Building an NFT racing marketplace like Zed Run

Zed Run was a digital horse-racing game where every horse was an NFT with a genotype and bloodline, owners entered races for prize pools, and breeding created new horses for sale. It proved that people will pay for racing assets with on-chain pedigrees, and it also showed how quickly a breeding economy inflates when supply grows faster than demand. A new racing marketplace should copy the asset design and fix the economics.

How Zed Run worked

Zed Run was built by Virtually Human Studio and launched in 2019. Its loop had four parts: own a horse, race it, breed it, trade it. Everything else on the platform supported one of those four actions.

Horses as NFTs with genetics

Each horse was a non-fungible token carrying attributes that mattered to gameplay:

• Bloodline. Four bloodlines, named after crypto figures: Nakamoto, Szabo, Finney and Buterin, in descending order of prestige and scarcity.
• Genotype (Z-number). A number from Z1 upward. Lower Z-numbers were rarer and, in theory, carried stronger genetics. Genesis horses had low Z-numbers; bred offspring inherited a Z-number derived from their parents, so breeding pushed numbers upward over time.
• Breed type and coat. Labels such as genesis, legendary or cross, plus cosmetic coat colors that affected desirability but not performance.
• Hidden performance stats. Actual race performance depended on underlying stats players could not see directly, inferred only from race history.

The design created a pedigree market. Buyers studied race records and parentage the way real-world bloodstock buyers do, which gave the collection depth beyond "rare picture."

Races and classes

Owners entered horses in races of various distances. Paid races required an entry fee; the fees formed a prize pool, distributed to top finishers, with the platform taking a cut. A class system grouped horses by recent performance so new or weaker horses were not always racing champions. Free races existed for practice and to keep horses active.

Race outcomes were computed off-chain by the game server and animated for spectators. Results were not verifiable on-chain, which became a recurring point of distrust.

Breeding and stud fees

Male horses could be listed in a stud farm. Owners of female horses paid a stud fee to breed, and the offspring was minted as a new NFT to the female's owner. Breeding had limits per horse over a time window, but the system as a whole still produced a steady stream of new horses.

Chain and marketplace

Zed Run started on Ethereum and moved its activity to Polygon in 2021 to escape mainnet gas fees, which had made entering low-stakes races uneconomic. Horses traded on its own marketplace and on general marketplaces such as OpenSea.

What went wrong

Zed Run's decline is well documented in its own community. The studio cut staff, changed the racing and reward model several times, and eventually moved away from the original game toward a relaunch under a new format. The specific causes are useful to anyone designing a similar product:

• Uncapped supply growth. Breeding created new horses faster than new players arrived. More horses chasing the same prize pools meant falling returns per horse and falling prices.
• Returns funded by new money. Prize pools came from entry fees. When the player base stopped growing, the economy had no external revenue to sustain rewards.
• Opaque mechanics. Hidden stats and server-side race resolution made it hard for players to judge value and easy to suspect manipulation.
• Thin gameplay. Owners did not control the race. Once the novelty faded, there was little to do besides enter, wait and watch.
• Frequent rule changes. Each economic adjustment changed the value of assets people had bought, eroding trust.

Designing a better racing NFT marketplace

The asset model is the part worth keeping. The economy is the part to redesign. Here is how the main components compare.

Smart contracts you will need

• Racer NFT contract (ERC-721), with on-chain or content-addressed metadata for immutable traits and an updatable record for race history.
• Breeding contract that checks cooldowns and eligibility, collects fees, derives offspring traits from parents plus verifiable randomness, and mints.
• Race entry and payout contract that escrows entry fees and pays out based on a signed or verifiable result.
• Marketplace, ideally built on an existing order protocol rather than a new exchange.
• Optional ERC-20 for in-game currency. Think hard before adding one; see the economics notes below.

Verifiable races

Players will tolerate losing. They will not tolerate suspecting the result was rigged. A workable pattern: the race engine is deterministic given (horse stats, track conditions, random seed). The seed comes from a verifiable randomness source requested after entries close. The engine code is published, so anyone can recompute the result. Only the seed and the final standings need to touch the chain.

The economy

Model the economy before you write contracts. At minimum, simulate: new players per week, assets created per week through breeding, fees burned or retained, and reward outflows. If rewards only come from other players' entry fees, the game is a zero-sum (negative-sum after fees) wager, which also raises gambling questions in many jurisdictions. Our NFT gaming platform guide and the broader notes on blockchain game development cover sinks and faucets in more detail.

The marketplace itself

A racing marketplace is a pedigree market, so its listing pages need more than a picture and a price. Buyers want to filter and compare on:

• bloodline, generation and parentage, with a navigable family tree;
• race history: starts, wins, placings by distance and class, and recent form;
• breeding status: offspring count, cooldowns and remaining breeds;
• stud listings with fee, availability window and offspring performance.

Two marketplace mechanics are specific to this genre. First, stud rentals: the owner of a male racer lists breeding rights for a fee without selling the racer, which is a time-limited approval rather than a sale. Second, racer leasing: an owner lends a racer to another player for a season and splits winnings. Both should be enforced by contracts with expiry, not by off-chain trust, and both create the same royalty and fee questions as normal sales. Because general marketplaces will not show race data, an in-game marketplace with these filters is a genuine advantage, but keep listings in a standard order format so racers can also trade elsewhere.

Build sequence

1. Write the game design and economy model first, including supply caps and reward sources.
2. Build the race engine off-chain as a deterministic simulator and test it for balance with thousands of simulated races.
3. Design the asset schema: which traits are immutable, which change, and where each lives.
4. Implement contracts for racers, breeding, entries and payouts on a low-fee chain.
5. Integrate verifiable randomness and publish the engine.
6. Build the marketplace with pedigree search, race history and stud listings.
7. Audit the contracts, especially breeding and payouts. A smart contract audit is not optional when contracts hold prize pools.
8. Get legal review of race entry fees and prizes in your launch markets before going live.

Cost and timeline drivers

The 3D race presentation and the simulation are usually the most expensive parts, not the contracts. As a reasoned estimate, a minimum viable racing game with 2D or simple 3D races, breeding, entries and a marketplace on one chain needs roughly a game developer or two, a backend engineer, a smart contract engineer, a designer and an artist, for six to nine months. High-fidelity 3D racing, mobile clients and esports-style events extend that significantly. Audits and legal review are separate line items.

Frequently asked questions