ZED RUN: how the NFT horse racing game worked and how to build one like it

ZED RUN was a digital horse racing game in which every horse was an NFT with a bloodline and a genotype. Owners raced horses for prize pools and bred them to sell the foals. This guide explains the original game and its successor, ZED Champions, and shows how to design an NFT racing game and marketplace with a stable economy.

ZED RUN showed that players pay for racing assets with an on-chain pedigree. It also showed how fast a breeding economy loses value when new horses arrive faster than new players.

How ZED RUN worked

Virtually Human Studio built ZED RUN and launched it in 2019. Every feature on the platform supported one of the game's four actions: own a horse, race it, breed it and trade it.

Horses as NFTs with genetics

Each horse was a non-fungible token with attributes that affected the game:

• Bloodline. ZED RUN had four bloodlines named after figures from crypto history: Nakamoto, Szabo, Finney and Buterin. Nakamoto was the rarest and most prestigious, and Buterin the most common.
• Genotype (Z-number). Each horse had a number from Z1 upward, and a lower Z-number was rarer and was meant to carry stronger genetics. Genesis horses had low numbers, and a foal received a Z-number derived from its parents, so breeding pushed the numbers up over time.
• Breed type and coat. Labels such as genesis, legendary or cross described the breed. Coat colors changed how much buyers wanted a horse but did not change its speed.
• Hidden performance stats. A horse's race results depended on stats that players could not see, so players estimated them from race history.

This design created a pedigree market, in which buyers studied race records and parentage the way real bloodstock buyers do.

Races and classes

Owners entered horses in races of different distances. A paid race charged an entry fee, and the fees formed a prize pool for the top finishers, with the platform keeping a share. A class system grouped horses by recent results, so new or weak horses did not always race against champions. Free races let owners practice.

The game server computed each race off-chain and showed an animation to spectators. Players could not verify results on-chain, and many players distrusted the results for that reason.

Breeding and stud fees

An owner could list a male horse in the stud farm, and the owner of a female horse paid a stud fee to breed with it. The foal was minted as a new NFT to the female's owner. Each horse could breed only a limited number of times in a given period, but the whole system still produced a steady stream of new horses.

Chain and marketplace

ZED RUN started on Ethereum and moved to Polygon in 2021, because Ethereum gas fees made small races too expensive to enter. Horses traded on the ZED RUN marketplace and on general venues such as OpenSea.

Why the original ZED RUN ended

Virtually Human Studio cut staff, changed the racing and reward model several times, and finally replaced the original game. Five problems led to that decision:

• Supply with no cap. Breeding created horses faster than new players arrived. More horses competed for the same prize pools, so each horse earned less and sold for less.
• Rewards paid from new money. Prize pools came from entry fees. When player numbers stopped growing, the game had no outside revenue to pay rewards.
• Hidden mechanics. Hidden stats and server-side races made value hard to judge and manipulation easy to suspect.
• Little gameplay. Owners did not control the race; they could only enter it, wait and watch.
• Frequent rule changes. Each change to the economy changed the value of horses that players had already bought, and players lost trust.

ZED Champions: the relaunch on Base

ZED Champions is Virtually Human Studio's new version of the game. Its Season 0 launched on April 28, 2025, and it uses the $ZED token on Base, an Ethereum Layer 2 network. The ZED Champions help center says original ZED RUN horses stay in their owners' wallets as NFTs but do not carry over to the new game. The rest of the ZED RUN treasury moved to ZED Champions.

The ZED Champions help center describes these rules:

• Fixed racing pool. Only 4,320 horses race at one time, and the game enters horses into races automatically by leaderboard standing.
• Matchmaking. Each race has eight horses, matched by matchmaking points.
• Stakes. Each horse holds an internal $ZED balance and stakes up to 10% of it in each race, and the result moves the balance up or down.
• Retirement. An owner can retire a horse after any race and withdraw its remaining $ZED. A horse whose balance falls too low is retired by force.
• Breeding auctions. Only racing-retired horses breed. Mare owners bid in $ZED for a stud, and bids stay open for up to seven days.
• Breeding limits. A horse gets five breeding slots minus its generation number, and no horse can breed more than ten times. Extra slots cost Forge Tokens, which come mainly from burning retired horses.
• Breeding payment split. 70% of the winning bid becomes the foal's starting balance. The game treasury, Virtually Human Studio and the stud owner each receive 10%.

Several of these rules answer the problems of the original game. The fixed pool caps how many horses compete for rewards, breeding slots fall with each generation, and most of each breeding payment stays inside the new horse as its racing balance.

How to design an NFT racing game

A new NFT racing game can keep the ZED RUN asset model and redesign the economy, as the table below shows for the main components.

Smart contracts for a ZED RUN clone

• Racer NFT contract (ERC-721). Fixed traits live on-chain or in content-addressed metadata, while race history lives in a separate record that can change.
• Breeding contract. The contract checks cooldowns and eligibility, collects fees, derives the foal's traits from the parents and a random number, and mints the foal.
• Race entry and payout contract. The contract holds entry fees in escrow and pays winners from a signed or verifiable result.
• Marketplace. Build the marketplace on an existing order protocol, not a new exchange contract.
• Optional ERC-20 token for in-game currency. The economy section below covers the risks.

Verifiable races

Players accept losing a race, but they leave when they suspect that a race was rigged. One working design has four parts:

1. The race engine is deterministic, so the same horse stats, track conditions and random seed always give the same result.
2. The seed comes from a verifiable randomness service, and the game requests the seed after entries close.
3. The studio publishes the engine code, so anyone can recompute any race.
4. Only the seed and the final standings go on-chain.

The game economy

Model the economy before you write contracts, covering new players per week, horses bred per week, fees burned or kept, and rewards paid out. If rewards come only from other players' entry fees, players lose money as a group after fees, and a game of that shape also raises gambling questions in many countries. The NFT gaming platform guide and the page on blockchain game development explain sinks and faucets, the ways tokens leave and enter a game.

The racing marketplace

A racing marketplace sells pedigrees, so a listing page needs more than a picture and a price. Buyers filter and compare on:

• bloodline, generation and parentage, with a family tree they can click through;
• race history: starts, wins and places by distance and class, and recent form;
• breeding status: number of foals, cooldowns and remaining breeding slots;
• stud listings with the fee, the time window and the race results of past foals.

Two marketplace features belong to this genre. A stud rental lets the owner of a male racer sell breeding rights without selling the racer, because the rental is an approval with an end date, not a sale. A racer lease lets an owner lend a racer to another player for a season and split the winnings. Contracts with expiry dates should enforce rentals and leases. General marketplaces do not show race data, so an in-game marketplace with these filters gives buyers information they cannot get elsewhere. Keep listings in a standard order format so racers can also trade on other venues.

Build sequence for an NFT racing game

1. Write the game design and the economy model. Include supply caps and the source of every reward.
2. Build the race engine off-chain as a deterministic simulator, and run thousands of simulated races to test balance.
3. Design the asset schema. Decide which traits are fixed, which change, and where each one is stored.
4. Write the contracts for racers, breeding, entries and payouts on a low-fee chain.
5. Add verifiable randomness and publish the race engine.
6. Build the marketplace with pedigree search, race history and stud listings.
7. Audit the contracts, especially breeding and payouts. Contracts that hold prize pools need a smart contract audit.
8. Get a legal review of entry fees and prizes in each launch market before going live.

Cost and timeline drivers

The 3D race graphics and the simulation usually cost more than the contracts. The following team and timeline are an estimate from the component list, not a quote. A minimum racing game with 2D or simple 3D races, breeding, entries and a marketplace on one chain needs one or two game developers, a backend engineer, a smart contract engineer, a designer and an artist for six to nine months. Detailed 3D racing, mobile apps and esports-style events add months. Audits and legal review are separate costs.

Frequently asked questions