Digital Dogs: The Case for Greyhound Racing On-Chain

A Note on Context

This was written in September 2021, at the peak of the NFT cycle and several months before the category began to unwind. It is a v1.1.1 'Genesis' discussion paper — deliberately open, with sections marked TBD and design decisions still being negotiated, rather than a finished spec.

A few choices read differently with hindsight. The RNG approach (keccak256(blockhash || timestamp)) was a common compromise at the time; Chainlink VRF was available but not yet the default it later became. The pari-mutuel wagering model was likewise more typical of the moment than it would look today, and the 'game of skill' regulatory framing has aged less well than the rest of the paper. The broader bet on blockchain gaming as a category needs no commentary — the market made one.

I've left the original technical and economic substance intact rather than retrofitting later thinking. The paper is more interesting to me now for the shape of the design problem than for the specific solutions: how to decompose an NFT-based game into asset attributes, breeding economics, racing mechanics, and a sustainable token loop — while taking seriously the premise that a digital version should exist because the real industry is broken. Whether that thesis ultimately holds is a separate question. This is what working it out in real time looked like.

Abstract

This paper proposes a new — and safer, more humane — future for the sport of greyhound racing, fighting, and hunting. It combines a range of both existing and novel economic initiatives inside a cryptocollectible video game, wherein users can own, breed, trade, and stable their Hounds in exchange for rewards. These activities are conducted on the Ethereum blockchain, across both layer-1 and layer-2, to emphasise the open, immutable, and decentralised nature of the project.

Our aim with this is twofold:

• To preserve a fundamental cultural artefact of human behaviour on the immutable blockchain — to race, fight, and hunt with dogs without the real-world physical consequences of such traditions.
• To build a truly decentralised platform game that is controlled — as greyhound racing itself once was — by the people, for the people. This relies on consensus being driven by participants, and transactional verification will occur by token/asset holders rather than a trusted third-party or development team.

For these to be achieved, a range of technological and economic decisions will need to be made — the discussions of which occur within this paper. It will cover a range of topics, such as attribute systems, advanced husbandry mechanics, stabling logic, and the broader economic implications of creating a game of skill using dynamic cryptocollectibles on the blockchain.

Below, we set out the necessary historical context, technical architecture, and the economic impetus behind the proposal — and unlike other industry counterparts, the project will aim to remain generationally relevant and dynamic as time goes on.

01 — Historical Background

On the Origins of Greyhound Racing

Since domestication some 20,000 years ago, canids have inarguably remained the closest of animal companions to the human species. For decades, anthropologists have hypothesised that the presence of domesticated dogs not only expanded the proliferation of the human species into a wider variety of climates, but naturally set the basis for formulating agrarian collectives — laying the foundation for civilisations as we know them today.

This is because unlike their feline counterparts, canines have, in addition to their companionship, held utility for the purposes of tracking, hunting, and security. Ever the competitive species, it should have come as no surprise that the next logical application of these beasts was against each other — to evaluate them based on characteristics such as speed and strength.

It is from coursing — the act of pursuing and hunting live game by these dogs — from which modern greyhound racing draws its origins. Beginning first as an experiment at the Welsh Harp Reservoir track in 1876, greyhound racing achieved more mainstream adoption in 1912 with the advent of circular tracks and the mechanical hare. Prior to this, jack rabbits were forced along narrow corridors of track to be chased and killed by the participating dogs. Horrified by this, American inventor Owen Patrick Smith developed a guide-and-rail system that enabled more races, more frequently, without the need for senseless killing of hares. In the public eye, this saw greyhound racing become closer in form and function to horse racing — and Smith opened the first commercial track in Emeryville, California, by 1919.

Since then, the sport itself has remained relatively unchanged, albeit it is now worth several billions of dollars worldwide. While Smith may have ensured the welfare of hares, the same cannot be said for the participating greyhounds.

Issues Related to Greyhound Racing

Given the economic attraction of greyhound racing, and the lucrative adjacency of gambling and betting that sits symbiotic to it, it should come as no surprise that the industry is riddled with perverse incentive problems. We explore these for the purposes of demonstrating why a digital solution is preferred to preserve this culturally important exercise.

Overbreeding and Oversupply

In the pursuit of optimal genetics, there are thousands of greyhounds born every year far in excess of industry requirements. Many of these animals will never receive registration, and as a result will never be eligible for racing. Generally this is referred to in the industry as initial 'wastage', which unfortunately becomes ongoing 'wastage' over time as greyhounds are exposed to injury and/or fail to perform. These animals are discarded, and often subsequently killed due to the ongoing expenses they accrue. It is estimated that over 17,000 greyhounds are killed every year by the industry in Australia alone.

This problem of oversupply is made worse by the fact that breeding houses charge more for appearance fees, bloodline purity, and assumed longevity — all contributing to the substantial erosion of welfare for these animals. This includes surgical artificial insemination ("AI") procedures and overlittering, resulting in huge discomfort and in many cases physical pain for dogs designated for breeding purposes. In many countries worldwide, these practices have been banned due to the ethically inexcusable conduct associated with them and the proximate harm they cause.

Exposure to Injury

Assuming that the animal is even eligible for racing, it should be noted that the serious wastage occurs as a result of injury and exposure. These animals generally begin their career at 1.5 years of age, and most are retired between 2 and 5 — assuming that they have not suffered or sustained serious injury. On average, this represents one-third (33%) of the animal's lifespan, at which point the industry has deemed them wastage and fit for euthanisation. Due to inconsistent reporting and obscurity around data, it is difficult to pinpoint the exact numbers worldwide, but it is undisputedly within the realm of thousands.

However, many are not fortunate enough to even reach this age, due to the high prevalence of injury in racing. These can be divided into two distinct categories: injuries relating to (1) physical over-exertion of the animal such as hypoxic seizure (i.e. from lack of oxygen), or (2) racetrack collision or accident resulting in broken bones, eroded joints, and eventual death. The circular turns of the track are cruel and collision-prone, contributing to much of the industry wastage. As a result, the industry will go to any length to ensure both the pedigree and power of an animal, regardless of cost.

Substance Abuse

In this quest for peak performance — both to prevent injury and delay wastage — the industry has relied on pumping pharmaceuticals through these animals to portend their prowess on the track. There is effectively no limit to what breeders and racers will administer; greyhounds across the ages have tested positive for everything from amphetamines through to anabolics. More recently, there has been an increase in the usage of Erythropoietin (EPO) to increase the absolute number of red blood cells, driving aerobic capacity beyond genetic limits. It is expected that the industry will continue to explore the fringes of performance enhancers, with Selective Androgen Receptor Modulators (SARMs) the next likely frontier. It should be noted that these drugs have serious physical and psychological effects on the greyhounds — none of which are widely understood, recorded, or researched.

Training Regimes

With these animals purpose-bred and pumped full of pharmaceuticals, it should equally come as no surprise that they undergo brutal training regimes to produce the speed and strength required. From birth, these animals are effectively segregated, and practices such as 'live-baiting' (i.e. the use of real hares or rabbits) are utilised to cultivate a ferocious fixation while on track. When not racing, greyhounds are effectively caged in small, often barren, single-dog kennels for prolonged periods of time. Not only does this inculcate an anti-social attitude, it means that rehabilitation of these animals is exceedingly difficult — again contributing to this universal problem of wastage.

Improper Regulation and Controls

Finally, it should be noted that there are insufficient regulatory controls placed upon the industry to control for all the aforementioned problems and the perverse incentives attached to it. In many global jurisdictions, greyhound racing is overseen by a Racing Authority, but this model of self-regulation has failed to produce meaningful outcomes with respect to animal welfare for decades. This is further exacerbated by lack of industry transparency and the failure to report — meaning that the existence of the industry and the practices that go on behind it are not understood by the population participating in it.

For all these reasons, we find ourselves at a unique juncture: it is clear that the sport of raising and racing these greyhounds is culturally relevant to humanity, but at the cruel cost of the participants' own welfare and wellbeing. However, modern technologies offer us a unique solution which enables us to both preserve and protect — by migrating this controversial convention to the blockchain.

We aim to mitigate all these issues — while still preserving the spirit of the sport and its cultural importance — by transmuting the experience to the blockchain.

02 — Decentralised Gaming

With the advent of blockchain technology, infinite possibilities for its application have exploded. From replacing fiat as the modicum of exchange to the ubiquitous 'smart contract', we exist at a unique time to explore and exploit the boundaries of technological progress. In particular, one application is generating serious interest: decentralised games and securitisation of digital collectibles. In this, players no longer need to rely upon the publisher as a trusted third-party with and for custody of their digital assets — instead, they can do so via a trustless, transparent, and censorship-resistant entity: a smart contract.

This contract, or collection of contracts, is often referred to as a Decentralised Autonomous Organisation (DAO) and is the creation responsible for the administration and governance of community-owned assets. While there are a number of ways to structure a DAO, including participation, for the purposes of this discussion — and in particular cryptocollectible games — we will limit it to those methods reliant upon non-fungible tokens (NFTs). Under this model, the user agrees to purchase and/or 'mint' (i.e. the process of generating) a non-fungible token from the DAO in exchange for some agreed modicum of exchange, likely associated with the particular blockchain the DAO is built on.

We propose this method for the Project, and intend to build on the Ethereum blockchain across both layer-1 and layer-2. For the purposes of this discussion we will reference Ethereum (ETH) and the substituent components required to transact on it: gwei (gas). We propose a system that relies on conventional aspects of existing cryptocollectible games, while implementing a range of other features to incentivise deep gamification and investment, bound together by a robust in-game ecosystem floated with its own in-game cryptocurrency. These include factors such as natural token burn and expiration, to create upward pricing pressure and forced breeding — as well as the ability to fractionalise kennels, allowing the owning of the NFTs themselves across a broader community.

This document intends to outline the holistic structure of the ecosystem to inform prospective participants about what to expect. In Section 03 we discuss the basic premise behind the cryptocollectible platform. In Section 04 we will explore the technological challenges faced by others operating in this space and how we intend to overcome them — such as randomness, trait generation, and incentivised breeding protocols. From there, in Section 05 we discuss broad Game Mechanics. This allows us to segue into discussion around our in-game currency $TOKEN for Section 06, and will permit a detailed examination of how it will be obtained, staked, and distributed amongst participants. We will then cover off implementation in Section 07, summarise the outstanding design decisions in Section 08, and close in Section 09.

Remember: greyhound racing has always been a sport for the people, by the people — and we intend to keep that spirit alive.

03 — Introduction to the Project

The Project belongs to a family of related cryptocollectible games emerging on the Ethereum blockchain, in which users obtain, breed, and race their digital Hounds for reward.

In the initial release of the decentralised application (dApp), a user will be able to 'mint' their Hound, which will be assigned characteristics that determine speed, strength, and appearance. The output of these factors will determine rarity or desirability — but this function will be market-determined rather than mathematically provable, owing to the unique interactions users may have with the game. Another important note is that these attributes will be procedurally generated and likely non-collisional, meaning that the initial genesis of Hounds minted will not hold any optimal combination — forcing network participants to engage in breeding activities in order to min-max. More on this will be expounded in Section 04.

In addition to the process of collecting and breeding Hounds, we propose that their first-order functionality will allow users access to both the Marketplace (i.e. for the purposes of buying and selling Hounds) and the Racetrack (i.e. to pit them head-to-head). These interactions will rely on our in-game currency $TOKEN, which can either be obtained through ongoing participation in the game or exchanged for with ETH. More details on this are included in Section 06.

Each Hound is owned and controlled by a particular address on the Ethereum network. Hounds will therefore be recorded on the blockchain — protecting them from modification, replication, or indeed destruction. However, the team is still determining whether our approach will rely on layer-1 or layer-2 solutions. While layer-1 is attractive, the explosion in new NFT projects has resulted in network inefficiencies and 'gas wars' due to improper pricing below the market clearing rate. As a result, the team has begun to explore layer-2 because it affords far higher transactions-per-second (TPS) and gasless trades and interactions. In this case, though, the team will need to rely on a suitable solution that solves well for the common custody problem — and additionally it will need to be flexible enough to handle our proposal for Kenneling: the idea that users may want to contribute their individual Hound to a pool for the purposes of breeding and racing as a syndicate. More details on this are included in Section 05.

Each Hound, as mentioned, will come with a unique set of characteristics related to speed, strength, and appearance. In time, across the roadmap, the team will enable Hounds to acquire experience — providing lasting boosts to these attributes or fundamental changes to their appearance. In this way, while the initial calculation of these remains unchangeable, it suggests that repeated racing and exposure to the underlying mechanics of the game increase the performance of Hounds — incentivising participation.

Fundamentally, we expect four categories of user to emerge:

• The individual owner/operator (IO)
• The kennel-master (KM), who focuses on breeding activities
• The kennel-contributor (KC), who participates in kennel governance
• The observer (O), who owns no assets but stakes $TOKEN on events

In this way, there are several goals which a user may optimise toward singularly or in combination. Perhaps the IO obsesses over improving their own Hound, and maintains a rigorous schedule of races to ensure absolute dominance in their category. By contrast, the KM might be focused on managing the assets of the kennel, sourcing new Hounds to breed for attribute maximisation. As a result, we expect the game to be dynamic and constantly changing, with players discovering new and perhaps sometimes unintuitive metagames to optimise against. It is exactly this type of open-endedness that builds toward the truest version of the metaverse.

The game begins with the first minting event, which will spawn 9,999 Hounds, according to a flat minting price of 0.05Ξ. This will result in the treasury controlling approximately 500Ξ from which to execute against the roadmap. While this will account for the initial player base, over time we expect to introduce other systems (such as free-to-observe and fictional wagering) to expand the community around the game, in addition to secondary sales.

Marketplace

Universal to almost all NFT-centric projects is the idea that these are tradeable on either internal and/or external marketplaces — such as OpenSea. Enabling users to trade the genesis mint within 24 hours of it occurring will be not only preferential but necessary to generate interest amongst prospective participants who may have been unaware of the project's existence. We expect that external trading will commence, with an internal marketplace later configured by the founding members to retain fees within the network rather than on third-party platforms.

Racing

The first interactable functionality and utility of these Hounds will be the Racetrack. It will enable users or kennels to submit their Hounds to race against others for the promise of reward. The mechanic of award distribution here is no different to the existing industry, relying on a certificate-based system which divides dogs by class and then a system of pari-mutuel betting to pay out.

Hounds will race against each other on a single circular track. The length of this track will be the digital equivalent of 480m, the standard industry size. In each race, there will be no more than 6 participants allowed. These participants will be evaluated and classed according to certificates, and entry fees paid by either the IO or the KM controlling the Hound. Fundamentally, this game is one of skill. Owners (either as IOs or KMs) will need to determine the best Hound and gate from which to enter, according to their attributes and experience. In this way, we avoid regulatory issues related to games of chance, and instead rely on the discretion and skill of the owner to determine their relative appetite for risk — the same of which is true for those observing and wagering against outcome.

Certificate System

To determine eligibility for racing, we propose a certificate system not dissimilar from the current industry standard, which accounts for (1) underlying traits about the animal and then (2) the relative experience it has had racing. We effectively take these variables on-chain and express them as a score, which itself accords to a certificate that provides for the category of race each Hound is eligible for. Over time, as Hounds race more — and achieve more experience for their Track Preference — their tiering will increase, enabling them to participate in better tracks with larger prize pools, prompting players to continuously interact with the game.

Treasury Payout

The Certificate System thus accords to the respective Treasury Payout associated with winning the race. These are funds drawn down directly from the total supply of $TOKEN minted, and paid out to the top three (3) finishers for each race.

If a Hound wins, the owner is paid out by the Treasury. We propose a negative logarithmic scalar to enforce faster adoption of the Project — for early races, larger rewards will be up for grabs, and this will decrease proportionally to the total number of races that have occurred. If the owner happened to wager on their own Hound, then equally they will receive corresponding payouts according to the method above. In this way, there are no entrance fees being charged, and so the in-game ecosystem is heavily reliant on both wagering and breeding to ensure the Treasury has a buoyant supply of $TOKEN. More is discussed at length in Section 06. However, there are additional ways to earn $TOKEN via racing.

Pari-mutuel Betting

For the game to have a source of continuous funds flowing within the network — for both participants and developers — wagering will be enabled in the form of pari-mutuel betting. All wagers are constructed and payable in $TOKEN. For context, this system operates by collecting wagers into a pool, deducting the 'vigorish' or the 'house-take', and then calculating dividends by dividing the pool remainder by those who wagered on winning positions. Unlike other conventional forms of casino wagering, participants are competing against each other — not the house — which provides stability for the game as the bank cannot be broken.

We use the following example to demonstrate.

Assume a race with the following participants and their corresponding stakes:

The total pool of assets wagered on this particular race is 648.00 $TOKEN. The race is run, and Hound 4 is observed as the winner. Assume a winner-takes-all payout. Let us then assume that the vigorish is similar to other betting houses at 14.25% — meaning that the network takes 92.34 $TOKEN for facilitating the race and the subsequent wagering. We then take the remainder of the pool, 555.66 $TOKEN, and divide that amongst those who wagered on Hound 4: 555.66 ÷ 110.00 = 5.05, or approximately 5 $TOKEN returned per 1 wagered. The payout represents the 1 $TOKEN return on stake plus an additional 4 in profit. Odds here are therefore calculable as 4-to-1.

Algebraically, this is expressed as:

W_T = Σ (W_i) for i = 1 to n

After wagering occurs, the network deducts commission rate r from the pool and then distributes winnings amongst the successful bettors:

W_R = W_T · (1 − r)

As should be clear, the combination of both race entry fees and the vigorish on wagering should be more than sufficient to keep the treasury buoyant, and will enable the developers to hire more resources to deepen the roadmap.

This should broadly provide an overview of how we view the Project, and we will now proceed to a discussion on technical challenges and the required solutions in order to stabilise the game for release.

04 — Technical Challenges

Given the relative lifecycle of decentralised gaming built on Ethereum, there are several limitations that must be recognised and obeyed. However, this will largely be dependent on whether we pursue a build on layer-1 or layer-2. Challenges will be discussed for each of these respectively.

Layer 1

Given the relative youth of decentralisation, flaws are already being exposed in the early blockchain infrastructure. While Ethereum has certainly developed in recent years with the launch of EIP-1559 and other fee-related improvements for transaction speed, the network is still vastly handicapped relative to competing chains.

Recently, miners raised the transactability of Ethereum by lifting the gas limit to 15M post the Berlin hard fork. While this was a somewhat helpful measure to combat congestion, the recent spike in NFT interest has resulted in crippling 'gas wars' as participants attempt to outgame one another by bribing miners. This has significantly impacted genesis minting events, and resulted in thousands — if not millions — of lost capital as new entrants to the space wrangle with smart contract logic and the Ethereum network broadly.

If we assume that actions such as total population, racing, and breeding Hounds are likely to be affected by fluctuations in the gas price and overall network congestion, then fundamentally we need to consider limiting these actions and activities to keep bandwidth acceptable.

Similar to peers, and primarily as a result of these limitations not being solved, in-game currency is not simply an economic tool but a necessary one to control for population, cost of breeding, and additionally race fees and wagering. All these mechanics need to be built around the current gas limits — and while there may be a possibility that some issues will be solved with the advent of Ethereum 2.0, it will be hard to predict.

Layer 2

By contrast, there are a number of layer-2 solutions which are looking increasingly attractive due to the issues of layer-1: namely (1) low scalability, (2) poor user experience, (3) slow developer speeds, and (4) illiquidity due to underlying asset properties of NFTs. Layer-2 refers to moving the transactions to a sub-level, wherein instant trading, gasless minting and exchanging, and scalability are all possible — without necessarily disrupting or impacting asset security. Colloquially, this is referred to as the 'custody' problem, and is solved using what is called a 'rollup'. In this, the rollup executes a transaction outside the main Ethereum chain (layer-1), but posts transaction data to this layer. As the data is on layer-1, and the data is the single source of truth, it means rollups can be secured immutably. There are two primary types of rollups explored, each with a varying model or method of security: the ZK-Rollup and the Optimistic Rollup. It is beyond the scope of this paper to discuss both these in depth, but for the sake of completeness it should be noted that ZK-Rollups are the preferred method here because the sheer volume of transactions generated via game interactions will require it.

These ZK-Rollups consist of two user types: transactors and relayers. The former initiate the transfer and broadcast it to the network. This transmission contains four key pieces of information: the "to" and "from" addresses, the value to transact, the network fee, and a nonce. This can be compressed to a three-byte indexed version to reduce computational load and resource requirements. Depending on which side of zero (0) the transaction falls determines whether a withdrawal or a deposit is performed. The smart contract then records the data across two separate Merkle Trees: one for addresses and the other for transfer amounts. Relayers then gather a number of these transfers to perform the rollup. In performing this function they must generate the SNARK (Succinct Non-Interactive Argument of Knowledge), itself a cryptographic proof representing the delta — or change — in state of being for the blockchain. A comparison is then made between the post-transfer and pre-transfer blockchain, with changes reported in a verifiable hash to the mainnet.

The fundamental trade-off specifically around layer-2 and ZK-Rollups broadly is that they are not a truly decentralised construct. This is because on initial configuration the ZK-Rollup is assumed to be in a trusted state, when this cannot be empirically or mathematically proven. This exposes the method to social hacking, such as code manipulation or backdoor vulnerability. Another fundamental flaw of this approach is that it is not quantum secure, due to the higher probability that the SNARK can be guessed than the current level of encryption offered.

Proposal

Due to the incredible demand for NFTs and the subsequent architectural and resource crowding occurring on layer-1, we are proposing a hybridised approach. Similar to other companies operating in this space, it is clear that our users are less concerned with decentralisation, and more concerned with minimising fees to increase participative value for all actors. As a result, we propose that any actions related to minting (i.e. via genesis or breeding) occur on layer-1, with all other interactions occurring on layer-2. There are a number of protocols we are currently exploring to implement this architectural decision.

Issues on Randomness

As a broad phenomenon, randomness is difficult to achieve. It is either real — and observed with respect to natural outcomes in the world around us — or simulated, utilising algorithms. The latter, while on the surface appearing random, is actually illusory: if an attacker were to know both the original input and the randomisation function, then results could be reproduced — leading us to assert that in fact we have achieved only pseudo-randomness, and not true randomness.

If we examine other industries that implement this approach — notably online gambling — we arrive at the conclusion that the true test of randomness is only that it must be sufficiently difficult for all other parties to obtain the numbers. This means that validating the actual randomness of the numbers produced is itself an almost uncertain principle problem; measuring by the maker almost always results in a different set of results, tending toward a recursive loop.

Ethereum makes even this process impossible, due to the fact that it is a deterministic Turing machine. As a result, external solutions must be explored to impute some randomness to a decentralised application.

Relying on Oracles

Under this approach, a trusted third party — such as Oraclize — is responsible for providing the externalised pseudo-randomness. It is a relatively simple approach, but equally requires two separate blockchain transactions and additionally may be compromised should the oracles themselves fall.

Relying on DAOs

Similarly, the dApp could request this value from RANDAO — a DAO working as a pseudo-random number generator. While likely secure, it will be expensive to process due to fees and is unlikely to be performant, with high turnaround times depending on network congestion.

Relying on the Block Hash

Using the block hash itself is another possible solution for pseudo-randomness. The upside to this approach is that it is quick and cheap; however, it is susceptible to miner manipulation if perverse incentives exist.

Relying on Future Blocks

Additionally, the participant could send a transaction to an RNG smart contract. These are queued and then satisfied after some n blocks have been mined by the network. The pseudo-randomness could be performed by some generated random number which is then hashed, for example using SHA-256. However, this approach is not performant — and additionally, the Ethereum Virtual Machine only allows a lookback of 256 blocks, meaning a user could simply skip whatever number was generated if it did not suit their preferences.

Relying on the Signidice Algorithm

Outlined in the Gluk256 repository, this method relies on the generation of public and subsequent hashing of private key to produce the required random number. This method was, like in other comparable projects, deemed too complex to implement.

Current Solution

Given the instantaneous need for random numbers across various parts of this project, the ideal implementation needs to exhibit the lowest possible latency and cost. According to the above, the best method would be relying on the block hash — utilising existing data from a blockchain block to simulate the randomness. Given we expect every transaction to carry some abstract permutation of Hound attributes (speed, skill, ferocity), it should mean that even when the same random number is generated by bundling several transactions into a single block, the output should be consistently different. This is enforced via timestamp augmentation and utilisation of the Keccak (SHA-3) hashing system:

uint256(keccak256(abi.encodePacked(blockhash(block.number - 1), now)))

Open considerations: whether to replicate Dragonereum's exact transformation or apply another; Keccak vs. KangarooTwelve; whether to quantum-harden (likely not needed at this stage).

Solving for Miner Manipulation

Given the utilisation of timestamp in the above algorithm, it is exposed to the possibility of alteration by the block miner — and many transactions can be lumped in order to discover the _seed which matches the desired value. The approach below was crafted by the Dragonereum team to overcome this.

In order to resist attack, the timestamp submitted by the miner must:

• Be greater than the timestamp of the parent block
• Not be set too far into the future
• Be earlier than when the block was actually mined, in order to reduce difficulty and system load

Despite these rules, it should be noted that a malicious miner could feasibly manipulate the timestamp several times within a window of approximately 10 seconds if they are large enough. This means that larger miners can have 10x the possibilities to manipulate the RNG outcome on the above method. As a result, the impact of malicious behaviour should be examined in respect of the Project and the potential exploits these miners may achieve.

Racing Manipulation

There is a large question — still largely unresolved — as to what element randomness (synthetic or not) plays in determining the outcome of racing. In order to avoid regulatory scrutiny, the team has opted to prevent the introduction of randomness in the initial launch. This is because having such features would place us squarely along the boundary between a game of skill and a game of chance — one that saddles us with reporting obligations and compliance burdens. Instead, racing will be determined by the attribute combination of any given Hound with respect to the track they race on, and the present conditions on race day. More on this in Section 05.

Breeding Manipulation

By contrast, we fundamentally believe randomness is fundamental to the breeding system. This, however, comes with consequence: due to limited mint size and population control, perverse economic incentives will exist for miners to manipulate. If we utilise the original algorithm proposed by the Dragonereum team, then each attacking miner has a high chance to produce an ideal gene set.

We believe the augmentation Dragonereum proposed is an elegant one — that is, to utilise Nest (now Litter) logic into the breeding process. Rather than allowing the miner to sample, almost infinitely, throughout the breeding process to hit a suitable moment, they proposed the idea of the Nest: a container holding two (2) eggs for incubation. At any given time, only one egg can be sent to the Nest, and each forthcoming egg (i) opens the earliest placed egg that is already inside the Nest (i-2). We rely on identical logic with different nomenclature — the Litter — to enable the same level of attack resistance by timegating the possible exploit window and ensuring that the odds of predicting the timestamp variable are uniform across all players.

It is at this point that it should be noted: the team here has so far stood on the shoulders of giants. The Dragonereum team proposed many of these solutions previously, and they will be implemented to effect in the Project.

05 — Game Mechanics

This section breaks down the fundamental mechanics of the game — in respect of minting, breeding, kenneling, racing, and all the associated interactions intrinsic to these functions. However, before covering this, there needs to be a brief description of a Hound, the unique underlying traits that make them non-fungible, and what determines their aptitude on the track.

Attributes

Fundamentally, there are four characteristics that determine the ability of a Hound — these create a unique output known as the Pedigree Potential (PP). This will differ for genesis Hounds and their subsequent offspring, with the former holding higher-on-average base stats than their non-genesis counterparts. We use the PP to determine the suitability of the Hound for breeding activities, and expect that rarer attributes will lead to higher prices in the secondary market.

This, however, is distinct from Race Potential (RP) — which informs how a Hound will actually perform on the track. We account for in-race discrepancy by introducing two new factors beyond the PP to determine RP: Track Preferences, and Exhaustion & Expiration. All of these will be explained below.

Pedigree Potential

As mentioned, Pedigree Potential is an algorithmic combination of four key attributes calculated during the minting process: ancestry, genotype, speed, and coat — weighted according to that order. This is not dissimilar from ZED RUN. These factors combine to not only determine the base stats for racing, but equally inform breeding prices and speeds to preserve scarcity.

Ancestry

Within the Project there are four (4) primary ancestries: Argussian, Peritasian, Lelapsian, and Eosian. Ancestry is the single largest indicator of Hound quality and therefore informs the relevant breeding price, weighting it accordingly. This is because the rarer the ancestry, the faster the Hound.

In order to secure this scarcity, it will be proportionally more expensive to breed Argussian Hounds relative to the more common Lelapsian and Eosian. In this way, we can keep populations controlled and the game engaging.

In determining the average breeding price, we weight ancestry by 80% and then apply the following multiples to the base price:

• Argussian: +2.0×
• Peritasian: +1.5×
• Lelapsian: +0.5×
• Eosian: +0.1×

From these values we are able to derive the minimum prices for stabling Hounds of certain breeds. All of these considerations are important to the preservation of scarcity.

Genotype

As the name suggests, genotypes are properties inherited during the mint of a new Hound. For the purposes of launch, we propose a similar method to ZED RUN — combining the properties of lineage and rarity to produce a scoring method that feeds into the Pedigree Potential. While we could have explored a more complicated genetic route, this likely would not have resulted in additional functionality at this stage. Instead, we simply scale and index all initial Hounds by their genesis mint rarity, labelling them from G1 to G256. From this, the new genotype is calculated simply by summing the parent genotypes together.

As an example, assume an Argussian Hound of G1 breeds with an Eosian at G34: the resulting genotype for that Hound will be G35, and it will belong to the lowest associated genotype band.

We weight the genotype by 20% in the breeding calculation. In terms of evaluating the genotype, we split the pool out as follows:

• G1 to G10: Legendary, cannot be reproduced (8%)
• G10 to G50: Rare (12%)
• G50 to G125: Uncommon (30%)
• G125 to G256: Common (50%)

Speed

Another core attribute to determining the Pedigree Potential is the speed of the actual Hound itself. This number is generated externally during the minting process for genesis Hounds, or for subsequently bred Hounds is calculated by examining the speed attributes of their parents [precise formula TBD]. Speed itself has no residual impact on breeding costs and is simply used in calculating how the Hound will perform on the track.

Coat

The final attribute is coat. While it is not a factor utilised to generate race performance, it is something that will be desired by players for breeding and kennelling purposes alike, given it will drive price in the secondary marketplaces. [Coat distribution table TBD.]

Race Potential

With Pedigree Potential now covered, it will now be important to explain how this variable is used to produce Race Potential (RP). If we consider PP as the underlying 'base stats' of any given Hound, then the two factors that feed into Race Potential should be considered environmental effects: Track Preference, and Exhaustion & Expiration. Neither of these two factors have any implications on the breeding of Hounds — just race performance.

Track Preference

Each Hound, at mint, will have a track preference within our ecosystem. Over time, as they compete in more of these race types, this value increases, resulting in better outcomes. In order to prevent aggressive min-max behaviour, we augment this only up to a hard cap, at which point owners are informed.

Initially, it may be thought that this will encourage track-specific racing only, where owners and breeders only enter Hounds in races matching their affinity. While this would ordinarily be true, we offer attractive payout multipliers to Hounds racing in uncomfortable categories — utilising these to incentivise cross-track competency.

Exhaustion and Expiration

Nothing lives forever, and we feel the same should be true even on the blockchain. As a result, one final parameter we use to compute the race potential of any given Hound is their exhaustion and expiration factors. The first, exhaustion, is a handicap applied to Hounds that have previously raced in the last N hours, and will significantly impede their performance should they race again within that window. It is a flat reset, and will be removed as soon as the time has elapsed. The second, expiration, is more universal in application, and allows us to emulate the life of a real greyhound. Effectively, once the Pedigree Potential and Track Preferences are combined, expiration applies a negative logarithmic scaler to the entire set of variables to demonstrate the decrease in performance. The y-value here correlates to the number of total races involving the particular Hound, before again similarly stabilising at a hard cap. While this does not render the Hound entirely obsolete, it enforces that each one has a finite life — and once expired, should be allowed to retire comfortably to the kennel for breeding purposes.

These cumulative factors set the foundation for the Project's universe, and likely the market conditions that will drive price and performance, leaving players to explore a number of paths across both breeding and racing.

Minting

Every player deserves a chance at greatness. It has become far too common in the video game industry — especially Multiplayer Online Battle Arenas (MOBAs) — to enable pay-to-win functionality. We believe this is antithetical to both the nature of racing and entertainment broadly, and to combat this we propose a system of complete decentralisation.

In order to do this, there must be two main principles at play:

• Randomness must be imputed into the process of minting a Hound on the blockchain
• This must be extended to all breeding functionality also, which should also be conducted on-chain — visibly to all

Given we have covered randomness already, the remainder of this section details broadly the intended smart contract logic for the genesis mint, and additionally the size and scale of the mint proposed.

Smart Contract Logic

[Detailed smart contract logic for the mint TBD — to be published with the contract code prior to genesis.]

Genesis Mint

We intend to run a genesis mint of approximately 9,999 Hounds, with properties and rarities striated across the aforementioned ancestry and genotypes listed in Section 05. This population should provide for two things: (1) a sufficient starting point to kickstart the player base, and (2) a decent liquidity pool for the early team to commence rapid development of all the adjacent features. As of writing, the common methodology is to conduct the mint as the initial funding event with an aligned community, and then deliver against the roadmap — rather than the other way around, which is commonplace in the venture capital world. Additional details of the mint will be released closer to the date.

Breeding

Once the initial pool of Hounds has been minted, the only way to obtain new Hounds will be via breeding. It should be noted that to preserve the inherent value and economic system within the Project, breeding accrues fees — payable in $TOKEN — by the actor that initiated the breed. In order to breed, a user will need at least one (1) male and one (1) female Hound — but they do not necessarily need to own both. This is because we understand that many inside our ecosystem would like to earn passively from retired Hounds via the breeding function, and so may choose to retire their Hounds when their expiration value caps out. In doing so, they receive a large portion of the breed fees paid, while the Treasury takes the residual. To perform this breeding function, users rely on the Kennel — a construct that facilitates (a) the breeding of owned Hounds independently, or (b) access to the Hounds of others (males) for the purposes of breeding.

Kennels

Kennels are an essential part of the ecosystem. In the Kennel, a user can choose to pair existing Hounds together to breed new ones, or they can browse an open marketplace of Hounds on offer from other Kennel Masters. The stable gives you a picture of all available Hounds, and when some are engaged in breeding, will equally prevent you from racing those Hounds.

To breed, users simply access the Kennel from the interface and are immediately able to view the pool of eligible males across the ecosystem, including their own. From here, they are able to observe the attributes — or Pedigree Potential — of possible mates, and the associated breeding fees. When a suitable match is found, the user simply selects the intended mate, pays the $TOKEN breeding fee, and the minting process begins.

Similarly, if a user wishes to passively earn from their Hound, they effectively 'stake' the dog to the pool (to borrow a reference from the centralised finance world). Here, the user is prompted to select the amount of time they wish to lock their Hound in for, and the recommended breeding price generated from the Pedigree Potential. It should be noted that based on the Expiration value, a Hound only has N breeds available, so users will need to consider this as they stake to the Kennel Pool.

Fractionalised Kennels

Additionally, we want to explore the idea of fractionalising kennel ownership. Effectively, users should be able to pool their Hounds — not dissimilar from modern racing houses — to better manage, organise, and reap rewards from our ecosystem. While you can go fast alone, to go far you need to go together.

The notion of fractionalised NFT ownership has yet to be explored in depth, but fundamentally we can extrapolate using modern financial examples. If we assume each Hound — itself an NFT — could be pooled into a group of other similar assets, then we have by extension and proxy formed something akin to an Exchange Traded Fund (ETF). In the foreseeable future, we see Kennels not just as micro-communities within the broader ecosystem, but effectively individual pools of assets — ETFs of NFTs — that are earning fractionalised holders dividends based upon the breeding, sale, and racing of these Hounds within the game. While this may not be possible on first release, we recognise it as a key difference from other major blockchain games in the market today. In addition to staking Hounds for breeding, these Kennel communities will also have the ability to accrue in-game currency by staking it as a group also — providing liquidity for the house to power racing and a range of other community functions. This type of guild-based architecture will be important for early community adoption and future governance.

06 — In-game Currency

Rather than rely on layer-1 and the need for some currency like WETH to power interactions (especially if they occur on layer-2), we have decided to opt for the creation of an in-game currency, $TOKEN. The purpose of this is to afford and award control of the ecosystem back to the players, rather than allow external economic effects (and actors) to simply buy their way in.

At genesis, a total supply of 60,000,000 $TOKEN will be minted. Given there is no requirement for entrance fees on racing, the largest source of additional $TOKEN for the Treasury will come from both breeding and wagering. These two functions are required to ensure that the Treasury has a healthy pool available for race payouts in the ecosystem. While we have considered implementing DEX functionality for the community to swap (W)ETH for $TOKEN, we figure this may result in unusual manipulation, at least early on, and will reserve the decision for community consensus in the event it is needed later. It should be noted that such an event may result in some seignorage risk — and these concerns should be floated and discussed openly prior to any votable proposal.

Allocation Breakdown

Treasury — 60%

The Treasury must control the highest percentage of $TOKEN, as it needs to afford racing payouts. Given the cybernomics of the game and the early-adopter benefits, we expect this to deplete fast initially, then stabilise overall as more players begin to both breed and wager within the ecosystem — the two in-game community-driven mechanics for replenishing the Treasury.

Founders — [TBD]%

Once the smart contract is deployed, the respective team members will receive an allocation of tokens to their personal wallets, according to individual contributions made from a funding, development, and design standpoint prior to Genesis. The largest holder amongst the founders has agreed to lock these in a liquidity pool for Treasury use across a multi-year time horizon.

Core Team — [TBD]%

The initial team committed full-time to the project will receive an allocation in respect of assistance pre- and post-Genesis. The team's funds will be held at a multisig address [to be published at Genesis].

The Foundation — [TBD]%

The remainder will be utilised to develop out the ecosystem, and additionally provide for charitable aims in alignment with the vision set out herein. This includes, but is not limited to, the following actions:

• New team members and advisors
• Liquidity pool (e.g. Bancor)
• Airdrops
• Security audits
• Bounties
• Charitable donations (e.g. animal welfare organisations)

To further this emphasis on community ownership, it should be noted that the developer team will have no prolonged control of the $TOKEN stored within the Treasury once both upgradability and halting mechanisms have been solved for — effectively resulting in transfer to the 0x000…0001 address.

07 — Implementation

While we understand that decentralisation is not inherently desired by the userbase, we definitely want to migrate away from the current state of affairs within the modern video game industry. Centralised publisher control of both player behaviour and in-game economy tends toward poor outcomes from a community perspective; we would only need to examine the recent press cycle of Activision Blizzard to see that.

While ideally this game runs decentrally from the outset, we acknowledge that some level of control will be required early to pause and update smart contracts in the event of critical errors. However, once scale is achieved and the system has stabilised, transfer of the smart contracts will occur either to a DAO or just the 0x000…0001 address.

The upgrade proposal is identical to Dragonereum's:

• A new version of a required smart contract is deployed
• Ownership is transferred to the UpgradeController
• A migrate function with old and new smart contracts is called by the multisig

As time goes on and blockchain technology continues to develop, we hope that a fully decentralised system will be possible. Currently we plan to have the game accessible by the browser, with a master account broadcasting race events on Twitch.tv — or whatever decentralised equivalent emerges in the future.

In terms of player data, we do not require account registration or extraneous information. The private keys stored within their web3 wallets are sufficient to act as validating ID.

The data layer contains the two ERC-721 NFTs which will represent the two possible states of a Hound (pup and Hound) and an ERC-20 which will represent the in-game cryptocurrency. The business logic layer encapsulates the interactions of the marketplace and racing.

We will explore the use of backend servers for quality-of-life improvements such as filtering on the marketplaces, race details, and notification delivery while the player is not on browser.

08 — Outstanding Design Decisions

In keeping with the discussion-paper nature of this document, the following remain open design questions to be resolved prior to launch:

• Breeding cap. How many covers (i.e. successful breeds) should each retired Hound be permitted in their lifetime? This affects scarcity, the secondary breeding market, and long-term population dynamics.
• Smart contract architecture for the mint. The specific contract for genesis minting still requires implementation, audit, and gas-cost benchmarking.
• Population and currency simulation. Predictive models for in-game currency velocity, breeding rates, and population growth need to be developed prior to launch to stress-test the tokenomics.
• PP / RP algorithm finalisation. The precise weighting and curve shape for the Pedigree Potential and Race Potential calculations require further iteration with playtesting data.
• Currency issuance schedule. Whether to issue $TOKEN purely via in-game mechanics (breeding, wagering vigorish) or to introduce additional supply mechanisms requires further community input.
• Coat colour distribution. The full coat colour table and rarity distribution requires aesthetic and game-design sign-off.
• Roadmap population. Detailed milestone and timeline planning for post-Genesis phases is in progress.

09 — Closing Remarks

This document is, by intention, a briefing rather than a finished whitepaper. It was prepared to circulate amongst a small set of interested parties and prospective collaborators ahead of any public announcement or funding commitment. The presence of open design questions, placeholder allocations, and outstanding architectural decisions reflects that framing: a document for negotiating direction with partners, not for marketing one to the public.

The argument the briefing aims to advance reduces to three claims, which together justify the proposal:

1. The real-world industry is ethically indefensible in its current form. Section 01 surveys the historical record on wastage, substance abuse, training practice, and regulatory failure. None of these findings are seriously disputed amongst welfare bodies or the relevant academic literature.
2. The cultural artefact is nevertheless worth preserving. Greyhound racing sits inside a much older tradition of coursing and canid utility, and the cultural infrastructure surrounding it — kennels, breeding lineages, the wagering ritual — is structurally interesting independent of the animals involved.
3. A cryptocollectible substitute can preserve the artefact while removing the harm. Sections 03 through 06 outline how this would work mechanically: attribute-driven racing, on-chain breeding, a fractionalisable kennel structure, and a $TOKEN-denominated economic loop sustained through wagering vigorish and breed fees, with the Treasury acting as the buffer that smooths early payouts.

What the document does not yet contain — and what any serious prospective partner would reasonably expect to see before committing capital — is a finalised tokenomic allocation, an audited smart contract architecture, a regulatory opinion on the pari-mutuel design across the jurisdictions of interest, and a detailed go-to-market plan. These omissions are not oversights but the work to be funded; a briefing at this stage is the vehicle for agreeing on direction before those workstreams are commissioned.

The team is targeting a genesis mint at the end of October 2021, and is actively seeking partners and capital to move from this briefing into a funded build phase. Interested parties are invited to engage with the team directly.

Discussion paper, v1.1.1 — Genesis.