# Chris Withers: full text

> Founder & CEO of klikit. Has built and run marketplace businesses across Asia-Pacific for over a decade (Uber Eats, Gojek, Pathao), and builds applied-AI systems in production. Based in Singapore.

Open to conversations on APAC go-to-market and applied AI: advisory, board and senior leadership roles.

## Expertise

### Operating across Asia-Pacific

Has launched, scaled or turned around businesses in 14 Asia-Pacific markets since 2015, as an operator, executive and founder.

- Uber (2015–18): architected the Uber Eats launch playbooks across twelve APAC markets; led the migration to Grab on the sale.
- Gojek (2019–21): SVP, Marketplace Strategy; oversaw ~US$650M of incentive spend across Indonesia, Singapore, Thailand and Vietnam.
- Pathao (2018–19): Chief Strategy Officer in Bangladesh and Nepal; took monthly burn from US$2M to close to break-even in ~14 months and raised ~US$10M.
- klikit (2022–): founder and CEO, operating in seven Asian markets with ~US$300M GTV and 40M orders a year.

### Applied AI in production

Hands-on CEO who writes code and has shipped agentic systems that run klikit's support, onboarding, analytics and growth.

- Model routing: ~80% lower token spend, escalating to stronger models only where a task needs it (OpenRouter hot-swaps, token optimisers)
- Sovereign chat & voice on a vectorised knowledge base: >60% deflection, ~50% FTR, under ~100 tickets a week (VAPI, ElevenLabs, Telnyx)
- Back-office automation via sidecar MCPs: merchant onboarding cut from 30 days to under 2, with audit-logged handoffs
- Growth loops for pSEO and GEO: ChatGPT now drives ~30% of marketing-site inbound (OpenClaw, Ralph)

### Marketplaces, pricing and allocation

Multi-sided marketplace economics: incentives, dynamic pricing, driver allocation and onboarding funnels.

- Oversaw ~US$650M in incentive spend across consumers, drivers, and merchants.
- Led the incentive and allocation redesign that saved ~US$2M/week, including tuning the Jaeger allocation function to raise trip completion at the same spend.
- Refined the dynamic-pricing algorithm to remove recursion and update lag, lifting driver acceptance 1–3 percentage points.
- Core decision team on 'Project Cabrio' with Google Maps: API performance, storage and usage economics, and an Indonesia-specific DLS.
- Built the initial case for the Tokopedia merger, then staffed the early consolidation of marketplace teams.
- Architected the APAC launch playbooks — three-sided acquisition, incentives, evergreen automation.
- Built a Markov-chain driver-onboarding predictor for Bonjour (+30% completion, ≈½ in-cycle funnel time).

### AI sovereignty and governance in Asia

Writes on sovereign AI, governance by protocol and what AI changes for states and operators in the region.

- Dawn of the Neo-Pirate Era: On the second golden age of piracy. Why the AI arsenal (opened, clumsily, by the empires that built it) has rendered the cost of defection effectively zero, and why the next generation of operators will look more like Blackbeard than the Series-B founder.
- Individualism as Idolatry: Marx caught a glimpse of the truth, but offered at the wrong altar. A reading of the failure of both modern socialism and modern capitalism, and the case for generative sovereignty as the only coherent response.
- On the Sovereign Protocol: Singapore as the only successful example of governance by protocol, and why artificial intelligence may finally let us replicate Lee Kuan Yew's administration at scale, without him.

## Experience

### klikit: Founder & CEO (2022–present)
Built klikit as a unified system of record for F&B merchants across Asia — vertical SaaS in the age of agentic software.
Markets: Indonesia, Philippines, Malaysia, Singapore, Taiwan, Japan, Thailand
- 7 markets; ~US$300M GTV and 40M orders processed annually at <0.03% error.
- On track for profitability in Q1 2027 at 95.5% CM1; headcount declining YoY as automation compounds.
- Architected v1 personally; today still ships the most code in the company.
- Sovereign chatbot stack cut inbound tickets to ~100/week (≈0.01% defect rate).
- ChatGPT and adjacent agents now drive ~30% of marketing-site inbound.

### Gojek: SVP, Marketplace Strategy (2019–21)
Partnered with the Gojek executive team to improve marketplace efficiency ahead of the IDX listing.
Markets: Indonesia, Singapore, Thailand, Vietnam
- Oversaw ~US$650M in incentive spend across consumers, drivers, and merchants.
- Led the incentive and allocation redesign that saved ~US$2M/week, including tuning the Jaeger allocation function to raise trip completion at the same spend.
- Refined the dynamic-pricing algorithm to remove recursion and update lag, lifting driver acceptance 1–3 percentage points.
- Core decision team on 'Project Cabrio' with Google Maps: API performance, storage and usage economics, and an Indonesia-specific DLS.
- Built the initial case for the Tokopedia merger, then staffed the early consolidation of marketplace teams.

### Pathao: Chief Strategy Officer (2018–19)
Placed at Pathao by Gojek, which controlled its board, to stem capital outflow, rebuild unit economics, and ship core technical infrastructure.
Markets: Bangladesh, Nepal
- Reduced monthly gross burn from US$2M to close to break-even in ~14 months.
- Raised ~US$10M in emergency capital in a market with unpriced sovereign credit risk.
- Reorganised the company from 750 to ~200 FTE without productivity loss; 20–30% MoM growth continued.
- Shipped h3-hexagonal real-time geospatial tooling (+60% pricing accuracy, –30% positioning issues).

### Uber: Head of Growth, Uber Eats (APAC) (2015–18)
Joined the Queensland ops team and rose to lead APAC growth for Uber Eats through to the sell-off to Grab.
Markets: Australia, New Zealand, Indonesia, Philippines, Thailand, Vietnam, Japan, South Korea, Hong Kong, Taiwan, Malaysia, Singapore
- Architected the APAC launch playbooks — three-sided acquisition, incentives, evergreen automation.
- Built a Markov-chain driver-onboarding predictor for Bonjour (+30% completion, ≈½ in-cycle funnel time).
- Product lead for APAC with Uber Global Engineering: Automated Driver Incentives (Hollywood) and the Surge 2.0 rollout.
- On the sale to Grab, led the migration of merchants, drivers and customers and guided Grab Engineering on the GrabFood launch.

## Education

- Bachelor of Economics / Laws (Honours), University of Queensland

## Contact

- LinkedIn: https://www.linkedin.com/in/chrswthrs/
- Email (work): chris@klikit.io
- CV request: https://www.chrswthrs.xyz/about (The Request CV form on the About page; Chris is notified of each request.)

---

## Dawn of the Neo-Pirate Era

Source: https://www.chrswthrs.xyz/papers/dawn-of-the-neo-pirate-era

## I. The Great Reset

We live in deeply uncertain times. Around us, the agora of public opinion is riddled with the anecdotes that tell us that *something* has changed. Sharp rises in cost of living and unemployment, stagnating graduate job markets, proxy wars, energy crises and fundamentally enormous advancements that are shifting the balance of power on the Rock. And so, despite the abundant 'progress' of the past few decades, the modern zeitgeist finds itself in a state of total turbulence.

With the passing of that time and technology, we learn more and more of the consequences of our dark pact with the cyberdaemon of capitalism; the struggling artist with work wholesale plagiarized by Artificial Intelligence, belligerent shareholders calling for more souls to sacrifice at the altar of efficiency; all these seem like fleeting cries from amongst what is being colloquially referred to online as the 'permanent underclass'.

Commentators like @RayDalio will tell you this is the culmination of the 'Big Cycle': a convergence of small minutiae, culminating in large sweeping changes and indeed a great reset: a systematic rewriting of the economic and social contracts that govern civilization.

I will tell you something similar, but amongst that rearchitecture, there are stories of defiance: against the odds and the system.

- **The Former Professional**, 42, laid off from a mid-tier Series-something SaaS that failed to survive the critical impact of AI. Fifteen years of institutional knowledge. Now building their own company, ungovernable, with tools his former employer was afraid to use.
- **The Upstart**, 19, who never applied to university and now operates large-scale UGC clipfarms for brands that cannot figure out how to distribute in an era of short-form content, making thousands every month.
- **The Rogue**, 27, running online gambling platforms across four jurisdictions simultaneously via cryptocurrency. Not because he is a criminal, but simply because he knows the regulatory map hasn't caught up and won't within years.

These candidates in isolation would have made perfect contributors to the system, but now remain uncategorized. They represent something new.

**We are entering the Second Golden Age of Piracy.**

The 'Neo-Pirate' Era.

## II. The Historical Mirror

There is a triumvirate of actors we must examine to understand this analogy; the empires, the companies and the individuals.

**The Empires.** On the discovery of the New World, sovereign states were the first to extol their ownership. These colonial powers were swift to move beyond their limited borders, and were willing to subjugate and dominate to secure such expansion. The New World was seen ultimately as a zero-sum game, with some to win and others to lose. This is perhaps most evident when Pope Alexander VI issued the Treaty of Tordesillas; it was a declaration on ownership of the 'New World' between two competing hegemonies: Spain and Portugal. Without consultation, European powers were locked out of the future, their colonies designated for destruction. But how do you try to continue to extract value when wars are waged?

**The Companies.** You hide behind corporate frameworks and the smokescreen of commerce. The Dutch West India (VOC) and British East India Trading (EIC) Trading Companies were set up with this express purpose. Suddenly, your naval fleets are not engaging in acts of war, but rather consented protection of commercial assets in the pursuit of common mercantile value. These companies had the license to control such vast authority; they were a vehicle, and one that trained individuals incredibly well to optimize toward that value.

**The Individuals.** As war waged across the colonies, individuals that were deserted by either empire or company were driven into a fight for survival. Resultantly, they did not choose piracy for some philosophical reason, but rather it represented the only viable path toward the future. Suddenly, incentives aligned between all three actors: empires needed companies to secure trade and prosper, and companies needed individuals to protect those assets; whether they were internal or external was irrelevant. And so, in response, the European powers began to provide their assent to such actions, offering **letters of marque**; overnight these individuals went from rambunctious rebels to legitimate state actors; a tool for carving out the future for powers that were denied it.

However when powers (either empire or companies) outgrow the need for such tools, or conversely, collapse: what happens?

**Pirates are born.**

Edward Teach. Blackbeard. Served as a privateer for the Royal Navy in Queen Anne's War under letters of marque that permitted attacks on French and Spanish fleets. Trained within the system, he proved a capable and formidable student, one who understood the nuances of maritime warfare from the inside. When the **Treaty of Utrecht** was issued in 1713, everything changed and his license was withdrawn. He had suddenly become irrelevant.

Not because he had failed. Not because he was a criminal, but because the empire had made peace and decided to discard him. The conditions that produced Blackbeard were not inherently unique to 1713. They were a template.

And that template is running again, creating individuals that will, undoubtedly, carve out the 'Neo World', albeit differently.

## III. On The *Neo World*

Turning our attention back to modern times, these three actors emerge under yet again similar conditions.

**The Empires.** Nation states struggle to maintain power and dominance in a highly interconnected world. Globalism is on the decline, and countries turn inward to preserve what little remaining power they have. Having now delegated most of their economic powers to the companies, they consider their options in a world increasingly controlled by the *globotechnocrats*. Force becomes the only store of value they have left.

**The Companies.** Advancements in technology have resulted in an unprecedented concentration of wealth by a handful of corporations. The byproduct of the internet has been that interconnectivity is now more important than ever, and just like the Trading Companies of the East and West Indies, those who control the sea lanes of data control the Neo World. Our modern VOC and EIC are Google, Meta, Amazon and X, and interestingly all buy from the same shipbuilder, the only one capable of producing the vessels: **Nvidia**. These companies are crewed, with many weapons, but recently one has proven devastating in the accumulation of value: **Artificial Intelligence**. All foundational model providers are tools which solidify the position and dominance of these companies and importantly, will be subject to the interests of the Empires. The consequence of this is real; there are and will continue to be more 'ships upon the sea of the future' (i.e. existing companies) that will have their lanes stripped and loot plundered. It is this point that underscores the emergence of our pirates.

**The Pirates.** In 1713, defection required a significant amount of both human and capital assets: captains needed ships, weapons and importantly a crew prepared to lay lives on the line for the promises of wealth, women or simply want. As such, the barrier for piracy was incredibly high, which is why *so many went to work for legitimised company institutions*. The competent sailor never considered striking out alone because the task and cost was so daunting.

However in the modern age there are two unique factors converging:

- Smaller companies without the ability to properly access or harness the weapons of AI will be subject to downsizing or closure as software consumes itself.
- The *individual* costs of defiance disappear in the age of open access to the same weapons (i.e. Claude, ChatGPT) of the largest corporations.

In pursuit of their own material and monopolistic gains, the empires and powers (arguably now foundational AI companies and their sovereign sponsors) have clumsily opened their arsenal for almost unfettered public access. While @DarioAmodei's recent paper *The Adolescence of Technology* reads like an apocryphal warning of the end times, to the right individual it reads like a set of *precise instructions on the opportunity*.

These tools unlock the ability for anyone to become the *terribly empowered extreme individual*.

They have opened the gates to the Neo World and it is ripe to plunder.

They have done so because their tools (or weapons) hasten the **broad collapse of most capitalistic companies and enforce the concentration of economic power. It therefore follows that if you are not part of those companies, or you become obsolete there, not only do you have little choice, but there is also no psychological cost of defection for the individual.**

## IV. The Raft of Medusa

It is no coincidence that *The Raft of Medusa* by Géricault was selected for this article. It is a perfect encapsulation of the circumstances unfolding around us. It depicts the survivors of a sinking French naval frigate, abandoned by their institutional officers who took the lifeboats and left the crew to die at sea. In order to survive, the remaining sailors turned to cannibalism.

Many companies (and by extension the individuals within them) find themselves now stranded upon the 'Raft of Medusa'. It is an exact allegory of what is happening in modern markets; those companies (and individuals) without the capability or nous to deploy Artificial Intelligence are left to die, and undoubtedly amongst them, there are individuals *without any other choice*.

When the institution offered security, identity, and belonging, leaving it was traumatic. When the officers escaped aboard their lifeboats, their expectation was that the system would remain intact. For those left on the raft, it did not, and so the calculus inverted.

Thus, our Neo-Pirates will be those exploiting the obvious signs of company decay, preying on their inabilities to solve coordination problems, and rather than attack them frontally, they will simply operate with sovereignty to extract wealth as the empires and institutions around them progressively crumble under the weight of globotechnocracy.

The buccaneers didn't appear because men became criminal. They appeared because the enclosure became impossible to maintain and the men trained inside it had nowhere legitimate to go.

History isn't repeating. **It's rhyming with extraordinary precision.**

## V. Conclusion

Every Great Pirate Era from inside the confines of the empires appeared as a rebellious reaction, a surge in criminality and depravity.

This is patently false; instead these were *labour corrections*.

Legitimate responses to rapidly changing circumstances that rendered capable men obsolete.

The men aboard the 'Raft of Medusa' did not choose the raft; it was chosen for them by the institutional officers when they decided to escape without their comrades on the lifeboats. What separated the survivors was not virtue or intelligence; it was the willingness to do what the situation actually required rather than what the institution trained them to expect.

The Treaty of Utrecht did not *create* Blackbeard; it merely revealed him.

*Something is being revealed right now. The only question worth asking is whether you will do what is necessary to become a Neo-Pirate or simply one of the many casualties.*

---

— C

---

## Individualism as Idolatry

Source: https://www.chrswthrs.xyz/papers/individualism-as-idolatry

## I. The Origins

Karl Marx caught a glimpse of the truth, but placed his offerings at the wrong temple, to the wrong God.

The problem is real.

Man is heterogeneous, coordination is his enemy.

To strip the individual of individualism is to coerce control in pursuit of progress. Progress is the natural output of coordination, the cost of which is the individual. Collectivism dissolves the individual into the mean. Without external pressure, genius disappears in the vacuum of merit.

For Marx however, a system of governance that does this at scale and delegates authority (if not sovereignty) is a far lesser evil than to pursue other solutions. *Das Kapital* reduces this complexity to an economic level for the reader; the proletariat are heroic, and the bourgeoisie and aristocratic classes are immoral harnesses set upon the productive capital of mankind. In our world (and his) of waning religious influences, capitalism is identified as a dangerous anathema to humanity flourishing.

## II. Ideological Fracture

Consequences originate from the fact that Marx has no solution to innovation without individualism. Marxian socialism is therefore an *entropic* solution to coordination. For collectivism to be properly achieved, this God demands compliance and assimilation to the atomic economic unit; the proletariat.

Reduction of Man to the means of production.

However, compliance to the collective can only optimize so far. Stagnation of socialist regimes is an observed phenomenon, especially within the lens of autocracy, and often, without some external stimuli or internal policy concessions or violence, this form of governance rapidly disintegrates.

Almost all autocratic socialist regimes have implemented some form of this policy; The Cultural Revolution, the Khmer Rouge Killing Fields: purging individualism with force even beyond propaganda. The diagnosis here was ultimately correct, but the solution of stripping individualism in favour of collective coordination is a parasite to the polis: it feeds and detracts, rather than propels progress.

Ironically, modern socialists are even further from the solution. Rather than attempt to solve coordination at scale without total obliteration of the self, the majority of modern socialists can only be described as radical, and often highly educated, individualists, acting as sworn enemies of capitalism.

No longer are they the proletariat, they are the professional protestor.

The majority of socialist activists masquerade as minority interest groups, cobbling together an infinite number of 'fracturing' identities that feel maligned by the God of capitalism. In their discarding of inherited categories like nationality, sexuality and even ability (labels append to their identity like false medals and stolen valour), each declaring their right to recognition. This mode of socialism is ideologically incoherent; it unifies beneath the common enemy of capitalism, but remove that, and it disintegrates under the weight of its own contradictions.

## III. Defining Decay

How did this mutation happen, especially so rapidly? The civil liberties movement of the last century had legitimate targets and outcomes: the dismantling of systemised racism, gender and economic imbalances all produced net positives across the fabric of humanity.

However, with those systems then corrected (or at least sufficiently weakened to the point of progressive deterioration), the movement metastasised into what we see today.

*When there is no legitimate target, this energy, again, becomes entropic.*

Socialism has become a hydra; new heads emerge not because real injustice demands it, but simply because there must consistently be a new target for the outrage for the movement to remain coherent. As the passing of time continues, this accelerates into larger and larger contradictions.

The conflict between Israel and Palestine puts this paradox plainly: modern feminists of the liberal left allied with the Islamic hard-right; diametrically opposed in foundation, unified against capitalism.

Zohran Mamdani is that diagnosis and contradiction made flesh. While likely to be remembered only as a minor historical footnote, his existence is living testament to the lengths at which modern socialism is comfortable to warp, bend and transmute itself to remain relevant. Zineb Riboua wrote a deconstruction of this type of weaponized identity realpolitik, and traces the origins to language promulgated by socialist thinkers around the onset and height of the Algerian Revolution (1954–1962).

She deconstructs the emergence of 'de-colonization' as a heroic narrative from the likes of Fanon, Césaire and Jean-Paul Sartre, and their unique substitution of the proletariat with a new form of oppressed: the colonized. In their works, the colonized and their culture is deemed to, almost by default, hold some virtuous characteristic, some spiritual quality that for decades or centuries has been shackled, chained and harnessed by the Western powers and their obsessive capitalistic religion.

In the case of Mamdani, Islam becomes a symbol or political marker designating him as oppressed; as Riboua puts it, *'faith recast as resistance'*. This act hollows out the entire religious value of Islam, and wears it as coalition armour, despite the fundamental tenets being totally at odds with others that rally behind the banner. It is treated as nothing but an oppression vector, and in doing so denigrates and demeans the very value of it as a symbolic and powerful religion. Mamdani is the terminal expression of the entropic project: dissolution at the doctrinal level.

## IV. False Altars

Capitalism is no safer a harbour. Although socialism stands as an abject failure to solve for coordination, capitalism does not immediately stand as the divine dichotomous opposite. Far from it, in fact. It produces even worse outcomes for humanity when weighed against the social, economic and environmental effects, but importantly the psychic toll it takes on participants. Everything is zero-sum; success and failure determined only by the yardstick of capital returns to allocators.

This compounds with globalism and the interconnectivity of the internet; comparison is the thief of joy and social networks are temples ripe for looting. It is hard to explain the rise of hustle culture amongst capitalistic participants, but ultimately it is the natural outcome of a system that optimises for value extraction, where creation is a mere byproduct. The system builds tools to fuel the extraction of profits, and on the promise of coin and freedom, great minds across our species attract like moths to flames in technology, finance and other parasitic sectors where value extraction is asymmetric and highest.

We do not see capital allocators for music, literature, art (things we ourselves define as 'the humanities') and instead see capital wantonly thrown across the table to an endless stream of software companies all competing for consumer wallets. Even then, to these builders, the process is one of inherent ego-death; the VC acts as the universal toll collector on the road built by the sovereign individual. Synthetic value derived from generative act. In doing so, it has similar consequences to socialism; individuals are stripped of *not their ability to create*, but rather *their desire to do so*. This paradox is one that capitalism struggles to resolve, and in the process causes collateral damage we are yet to truly fathom.

## V. Sovereign Hopes

Generative sovereignty is the answer to systemic entropy. To create is an act of both rebellion and equally divinity. Ayn Rand espoused a version of this individualism half a century ago in her objectivist novels, but the philosophical output rejects the divine.

Instead, human non-compliance in a universe defined by free will is itself the ultimate act of divinity; regardless of the output and importantly *the timeline*.

Even Roark found himself at the firm before sponsors permitted his sovereignty over the Wynand Building.

To be a sovereign individual from birth to death is an impossible task in the face of any collective; *to become one* is to take the first steps on the path of redemption. And in taking such steps, you serve the collective, not by rejecting coordination, but by inspiring it.

*If you are reading this from inside the machine.*

*You are not the idolator.*

*You are not the poor masses that congregate around the temple wailing for collective rebellion to strike down cruel masters.*

*You are not the pharisees that grow fat and bloated with profit, starving the poor of coins for the blessings of false gods.*

*You are the sovereign individual.*

*Pirates burned ships. They also built them.*

---

— C

---

## On the Sovereign Protocol

Source: https://www.chrswthrs.xyz/papers/on-the-sovereign-protocol

## I. The Model

Nested on the Malay peninsula between the Straits of Malacca lies one of the greatest exceptions of our modern world. Would we still assess our teleological progress by *wonders*, it would be likely to sit squarely at, or close, to the apex of modern achievement.

Singapore.

Singapore exists as an immutable anchor point in a dynamic and vibrant region marred by uncertainty. For centuries it has assumed a role far beyond its afforded stature, and redoubled those positions tenfold in the last decades alone, eclipsing regional neighbours and many other international contemporaries by orders of magnitude.

It occupies a unique and coveted position on global leaderboards; Economics. Education. Equality. The barometer by which *most* humans universally measure the success of a civilization are all overrepresented by and within Singaporean society.

Such change does not emerge organically, neither without the ire of jealous neighbours or worse: siblings. Slotted between both Malaysia and Indonesia, Singapore had an immensely difficult childhood; best described by the Bahasa colloquialism of *'abang-adik'*: the interplay between older and younger brothers. For years, both nations pressured deference.

Instead, they got defiance, and exceptionalism emerged.

Singapore does not succeed *despite* the dysfunction of the region that surrounds it, it succeeds *because* of it. It has exploited a unique strength (and the absence of it within these neighbours) to achieve such radical progress and profit.

**It succeeded because of governance by protocol.**

## II. The Architecture

Amidst any celebration of Singapore will be a clamour of criticism. It is no stranger to such, and in fact, examination of its underlying architect shows this to be more by design than by dependency. That man is Lee Kuan Yew.

While Singapore exists wholly as a cumulative sum of efforts by the Singaporean people, to conduct any deconstruction of Singapore without any reflection on his role would not only be remiss, but outright incorrect.

Lee Kuan Yew is perhaps one of the most remarkable men to ever have existed.

While countless men have etched their names into the annals of history with the sword, he elegantly and lucidly illustrates that there are cases in which the pen is truly mightier. A trained legalist, LKY was left with the seemingly insurmountable task of wrenching Singapore (an ex-colonial and imperialist vassal state of both the British and then the Japanese) into not just independence, but out of the barren mud flat and into the modern metropolis it is today.

To be clear, there were a multitude of options available, and many competing global hegemonies vying to influence that decision. The Americans desperately wanted Singapore to adopt their flavour of democratic decision-making, as the Filipinos dutifully had post-WWII. This was countered by the spectre of Chinese (not strictly Soviet) Communism: to transform it into a command economy that would accelerate Eisenhower's infamous 'Domino Theory'.

It is clear from his personal memoirs that this was not a decision taken lightly. He understood, from the outset, that this choice would not simply affect the Singaporean people, but all of ASEAN, and he applied strictest caution in his assessment of options.

**Democratic**: governance by preference aggregation (populism).

**Autocratic**: governance by command (authoritarianism).

And a third, largely hidden force operating behind one mask of the former two:

**Protocolic**: *governance by execution logic (determinism).*

For LKY, his blunt assessment was that true democracy was never a suitable possibility for him, as arguably the Singapore of the 1960s had advanced far closer to what we see now in terms of the globalised West; nations grappling with large, sometimes conflicting, ethnic diasporas. Philosophers like Žižek are prepared to equally concede that these globalist tendencies have produced the death of liberal democracies, leaving most of the West to rethink their approach or face total annihilation in the face of remaining ethnically homogenous nations.

Turning back to post-Colonial Singapore, LKY also understood that this multi-racial fragility (particularly his need to rely upon ethnically Malay soldiers in the vacuum of a British retreat) meant that he equally could not assert autocratic rule.

Instead he carved a third path, and co-opted the face of democracy but constructed a detailed system that operated *policies as instruments of protocol*. Like the legal profession he was inculcated within, LKY applied legalistic principles to governance, crafting inputs and outputs that conduce outcomes, which he bet, as economic prosperity increased demonstrably, would continue to win him, and the People's Action Party (the PAP), democratic assent.

Almost all large-scale foundational policies in Singapore act this way; the Housing Development Board (HDB), the agglomeration of the National Trades Union Congress (NTUC), the Central Provident Fund (CPF), Ethnic Integration Quotas: all these *are serialised protocols underpinning a much larger structure of a nation state*. Rather than enforce these via coercion, as an autocracy would, he architected *compliance by economical rationality*, and as Singaporeans participated in this protocolic system, they found themselves rewarded, as their education, employment and economic opportunities incremented at rates since unseen.

So how did LKY succeed where all other models of governance failed?

## III. On Administration

The success of any protocol is ultimately governed by the administrator of it.

To understand this point, it is helpful to briefly rationalise by analogy from an unlikely source. In 1981, Disney released *TRON*. It was a fascinating cybernetic fiction film that transported viewers inside their computers to a world called 'The Grid' and cast a harsh, merciless program (the MCP, or Master Control Program) as chief antagonist.

In this domain, where computer code controls all, there are only the inputs and outputs of protocols, with the MCP as total master of the domain. It initialised, scaled and administered the entirety of this digital universe from a single *almost* unassailable node.

This is precisely what LKY was able to do for Singapore. He constructed the protocol, improved, adjusted and ultimately administered it for close to four decades of political life, *producing a system which has outclassed every other form of governance model on earth*.

This statement thus makes clear the fatal flaw in protocolic systems: **they are only as capable and competent as their administrator.** LKY was able, remarkably so, to balance a wide array of complex competing interests and engage 'satisficing' trade-offs in near real-time with full political power. This is not a transferable skill, nor is it a teachable one. Instead it is the hallmark of a supremely remarkable individual that was willing to devote his entire life to the cause of uplifting people from poverty to prosperity.

In fact his administrative ability was so strong that modern critics, unable to assault his methods of the past, now instead suggest that Singapore still runs on the institutional momentum of his legacy rather than active administration, and indeed, time will tell.

In any case, reflecting on his success, how can that kind of orchestrator be replicated?

## IV. On Collapse

Against the example of LKY, there are countless failures wherein protocolic governance has collapsed under the weight of itself. There are many forms this degradation takes, with close historical analogies.

**Deng Xiaoping** provides instruction as to corruption of protocol on transference, where the inheritor recrafts it to serve new political or personal ambitions. The protocol was never properly codified beyond the person into replicable policy instruments the *same way it was done in Singapore*. With no suitable inheritor, it is bound to collapse.

**Vladimir Putin** highlights the dangerous descent when the protocol stops optimising the system, and instead optimises singularly for regime continuity. In this case, the administrator's survival instinct progressively outranks the protocol's objective function, warping it beyond recognition. In these cases, protocol violation is rampant and frenetic; the entire system becomes more reactive than proactive, leading eventually to destruction.

**Lastly, the DPRK** is protocolic governance in the terminal state (coercion over rational compliance) collapsing into one objective function of administrator worship. When the administrator no longer can assert accurate information as to the performance of the system, observability is lost. This nullifies the failure signals; all nodes begin to optimise for administrator approval rather than objective outcome. As a result, we arrive at an epistemically closed network that consumes itself whole.

All these serve as stark, and dangerous reminders, of protocolic failure. These are not moral judgments, merely structural diagnosis on when and why the role of administration is such a near-impossible task for the fallible human condition to shoulder.

## V. Limit, not Lethargy

If we acknowledge that protocolic governance had to rely on the administrator, then it was not lethargy that led us not to proliferate this model of governance and coordination, but merely existed as a physical *limit unto itself*.

Without the man, there is no model.

Singapore *only* worked because the administrator had such a powerful and potent intellect, combined with an utterly selfless spirit. To maintain such difficult (and sometimes conscious) contradictions must have weighed heavy upon LKY, and despite whatever critics say about the man, so few politicians of the past, and even fewer today, possess such traits.

But that does not mean we are without *new* options.

Capitalism and socialism have equally failed us, alongside the constituent mechanisms of governance that accompany their existence. Therefore it is important to consider this third-axis for resolving coordination at scale.

Fortunately, every change in governance is preceded almost immediately or concurrently by a technological change. Linguistic script gave rise to codified law under the Sumerians, the Printing Press gave rise to thoughts beyond Theocracy, and while the Internet may have solved for decentralised *communication*, it did not solve for *governance*, until the present.

We stand at the dawn of a new technological age.

Artificial Intelligence (not yet true *thinking machines*, but approaching their era of adolescence) means solving protocolically becomes possible.

Singapore provided us the model.

Artificial Intelligence promises a possible solution to align sovereignty between the individual and that of the state.

An individual that operates within the confines of a properly architected and administered protocol is not delegating sovereignty, they are *reclaiming* it.

The question left to answer on protocols is not what, but **how?**

---

— C

---

## Unlocking Agentic DeFi: The Next Frontier

Source: https://www.chrswthrs.xyz/papers/unlocking-agentic-defi

## 01 — Executive Summary

### Overview

Herein, we propose a decentralised, agentic finance protocol (hereafter "the Protocol") for launch on the Kaspa L1 blockchain.

The Protocol is a decentralised, agentic finance platform for the management, swapping, and liquidity of cryptocurrency assets, powered predominantly through holding balances of a native utility token (hereafter "$TOKEN") and Kaspa, a fairly new Layer-1 ("L1") proof-of-work created by Sompolinsky et al.[^1] While the decision to select Kaspa ("KAS") will be discussed at length later in this paper, essentially this chain triangulates and solves for the major problems inherent to cryptocurrencies, namely: (1) security, (2) scalability, and (3) scarcity. As such, we believe it the truest maintenance of Nakamoto's vision by implementation of consensus, while at the same time providing realistic and eminently scalable solutions for transactions per second using its unique approach of a directed acyclic graph ("DAG") and cone-counterbalance to eliminate double-spend and MEV manipulation inherent to the Ethereum Virtual Machine on L1.

[^1]: GhostDAG Whitepaper.

### Key Features and Capabilities

The Protocol aims to leverage Kaspa (and the inherent technological advantages it has) to create a decentralised, agentic finance protocol that combines the existing infrastructure of other chains with novel applications yet unseen on Ethereum or Solana. The Protocol aspires to be one of the first full-stack decentralised finance platforms on Kaspa, and to combine this with agentic systems to both augment utility and drive liquidity of KAS and KRC-20 token swap pairs.

### Benefits

The inherent benefits of this are intrinsically linked to KAS: it solves for security, speed, and oracle efficiency while maintaining a truly decentralised status, something that countless other chains have already traded off. As a result of the underlying infrastructure, we believe KAS has the best possible potential to become a powerful instrument of decentralised finance, and we believe our technology to be key to unlocking that.

---

## 02 — Introduction

### Why Kaspa?

Since the initial proposal of a P2P system of currency and store of value by Nakamoto in 2008, cryptocurrency has experienced a remarkable transformative curve. While most of this has been driven by an underlying impetus of greed and investor irrationality, there are a number of achievements worth celebrating in how cryptocurrency is becoming a cornerstone of the modern financial system. It would be remiss to propose any new form of Layer-1 without discussing the existing incumbents, specifically Bitcoin, Ethereum, and Solana.

While beyond the scope of this paper to deconstruct them in depth, their various drawbacks are well understood. We apply fairly reductive logic in this discussion for the sake of brevity.

- **Bitcoin** suffers from high interval times, too much lost supply, and a now almost prohibitive Poisson difficulty.
- **Ethereum** forked to become proof-of-stake to optimize for speed, but suffers greatly from Miner Extractable Value ("MEV") attacks.
- **Solana** is largely centralised and operationally fragile, with significant disruption and downtime to the network occurring frequently.

While much infrastructure has been built upon the foundations of these systems, much of it continues to suffer problems identical to our fiat financial system: centralised control of assets, high overhead costs, and instability of service and performance. In searching for an alternative, many candidates considered could not ultimately solve for the trifecting problems that KAS does: (1) security, (2) scalability, and (3) scarcity. With these problems either addressed, or soon to be solved, we believe that Kaspa represents the best possible foundational layer for the creation of an agentic financial system.

### Why DeFi?

Lived experience and observation suggests that the Kaspa ecosystem is critically underserved with the range of tools and functions common to other L1 chains. With the advent of KRC-20 tokens, the ecosystem has exploded into a hive of retail and speculative activity, but lacks the fundamental touchstones to support maturity and long-term growth. Our team understands this incredibly well, having been amongst the first batch of KRC-20 tokens launched on Kaspa in late 2024. Excitement and engagement aside, the space is hampered by heavy reliance on opaque centralised exchanges and market makers, compounded by the fact that insider trading and concentrated transactions expose tokens to unpredictable price swings and movements. It is therefore our assessment that Kaspa deserves a better future, a fairer future, best brought about by democratising financial tools and systems to its participants.

### Why the Protocol?

We aim to provide this with the Protocol (a full-stack decentralised finance platform built Kaspa-first) that combines tools for **Visibility**, **Utility**, and **Liquidity** in a single, consolidated platform. Our vision captures the very spirit of cryptocurrency: to provide ultimate, immutable transparency through the hyperledger by equalising the playing field and creating a system that is both visible and usable to developers and participants alike.

However, we are also now at a time where two incredibly important technologies are coalescing: unifying into a single juncture. Artificial Intelligence ("AI") and cryptocurrency are inextricably linked in their future. The reason is clear: as AI fundamentally reshapes the relationship between capital and labour, there is still an inherent requirement for any work conducted by these agents to be paid for.

While early versions of these systems embedded into software platforms account for that payment under traditional fiat-based subscription models, the increasing complexity of agent-related tasks will imply the creation of new financial tools and modicums of exchange between them.

**Digital currencies for digital labourers.**

While modern financial institutions may lead you to believe they are adopters of new and exciting technologies, their ledgers are still inherently trust-based legacy systems, incompatible with the speed and security that agentic protocols will need to operate. As a result, this juncture provides us an opportunity to establish an entirely separate, and by design, decentralised system of exchange, entirely *de novo*.

---

## 03 — Roadmap

### Taking the 'First Steps'

For us to operationalise an agentic approach, it will first be important to establish a source of ongoing liquidity for the network. While a limitless ambition could see the Protocol become a universal decentralised finance platform comprising many chains and many solutions, it will need funding in order to realise that vision. As such, it will be helpful to outline the proposed direction of the product, the various checkpoints, and to expound upon the functionality of such a network and the operative processes that power it.

### Visibility: Token, Wallet, and Transaction Tracking

Before any discussion of autonomous agents, the Protocol needs to have available a centralised data stream of everything and anything related to the Kaspa network. Currently, the ecosystem relies on a singular tool, `kas.fyi`, to provide explorer functionality for the chain, giving near real-time updates on tokens, exchanges, wallets, and transactions. Given its existence, there is no strict requirement to rebuild the functionality, but instead to ingest it and, in turn, visualise it in more accessible and functional ways. By radically improving the access of information, and in turn creating localised stores of the information, the Protocol itself can create a stable data layer from which to train and contextually inform agents.

Beyond the value of having access to the data, particularly the historicals, we propose additional functionality including but not limited to:

- **Wallet Exploration & Visualisation**
  - Ability to examine, track, and annotate individual wallets
  - Dev-team treasury and fee management
  - Node-graph (bubble) wallet data visualisers
- **KRC-20 Token Leaderboards**
  - Existing and new token information
  - Leaderboard functionalities (top gains / losses / movers)
  - Overall exchange health (all-token and token-specific views)
- **Overall Network (KAS) Stability**
  - Current price pairs (USD, ETH, BTC, SOL)
  - Current transactions per second (TPS)
  - Current Sompi efficiency index (i.e. gas)
  - Congestion prediction

We broadly and colloquially refer to this swathe of tools and exploration systems as the *Basilisk*, and are able to provide multiple levels and layers of access here (both free and paid) in order to continue funding our development work. We see these as integral development tools not just for KRC-20 projects, but for all sophisticated traders on the Kaspa network.

In short, by exposing these particular tools and democratising access and visibility, not only can the Protocol utilise such valuable data for any agentic approach, but it will also contribute to a progressive, and ultimately self-profiting, improvement of the overall Kaspa ecosystem, one which we deem necessary to realise further mainstream adoption of the chain.

### Utility: Memes as Agents

From this base, we are then able to begin implementation of our genesis agents on the Protocol. At the heart of our agentic thesis is work by Murad (Mahmudov) and others, postulating that memetic movements are the fundamental beginnings of a 'more organised chaos' that decentralised systems and protocols are only now just realising. In the spirit of this proposal, the first agents on the Protocol aim to reflect our roots, embodying the various projects inside the nascent KRC-20 ecosystem.

The purpose of these initial agents will be to 'enliven' the spirit of their project and give them digital life. If we were applying some form of rudimentary classification to their purpose, it would be best described as 'community engagement': a digital avatar for a community to interact with, receive marketing from, and which generally advocates for their project in an arena of similar agents. These agents will be tasked with creating marketing content (both informative and promotional), resolving queries and questions about the project, and overall acting as a 'living' talisman of the project ethos and spirit.

Having run our own project prior to the establishment of the Protocol, we understand the difficult, but critical, nature of coordinating social media, engagement farming, and general community interaction. For development teams, this coordination is often so onerous that it requires multiple people working on it. There are a number of challenges with using humans for this approach: characters must be consistent, repetitive, and ultimately in some or many cases spontaneous, such as in responses to community member questions. The very essence of a 'memecoin' project lies in the total quantifiable sum of these interactions, and the market capitalisation of these tokens is directly relational to this. As a result of experiencing these scaling issues firsthand, we believe there is a multitude of value in the creation of these agents first, due to their value to the respective communities and development teams they serve, as well as the financial viability for the Protocol itself.

This, however, is simply the beginning of something much larger. While our initial proposal centers around agents for marketing and community engagement, their future on a decentralised data layer like the Protocol is effectively limitless. With full access to the ability to trade, swap, stake, and optimise, these agents could have a range of high-value applications, including but not limited to:

- **Personalised Financial Management:** Agents as 'personal brokers', creating customised investment strategies, automated savings targets and goals, and adjusting based on risk profile.
- **Decentralised Exchanges (DEXs):** Agents as 'market makers', improving trading efficiency on the Protocol's DEX through automated order execution and arbitrage.
- **Lending and Borrowing:** Agents as 'financiers', optimising lending and borrowing activities, identifying the best yield rates, and managing collateral.
- **Prediction Markets:** Agents as 'oracles', analysing data and participating in prediction markets on the Protocol.

For this future to emerge, agents will need currencies and modicums of exchange that operate securely, cheaply, and speedily in the digital frontier, which is exactly why Kaspa, and KRC-20 tokens generally, remain an optimal solution. All these activities and more mandate that we will need specialised financial instruments atop a specialised financial platform, and that is what the Protocol and the subsequent token behind it will be.

### Liquidity: Decentralising Finance

Finally, we round out our proposed roadmap by combining our agentic approach with decentralised finance, our primary goal from the outset. Our desire to reform this on Kaspa has largely been driven as a function of experience on and surrounding KRC-20 and KAS broadly: the constant abuse of market power by centralised exchanges, the perverse incentives of market makers, and the naturally self-serving behaviour of larger insiders. We believe that a major step to resolving these challenges is not dissimilar to what it was for Ethereum: the creation of decentralised exchanges (DEXs) to provide stable liquidity pools and swap pairs for a number of tokens relevant to the ecosystem.

Conditional to this future, however, are underlying technological developments required from Kaspa itself: a DEX cannot exist without robust smart contract logic that is able to regulate and self-govern liquidity, nor can it operate stable dynamic trading pairs. Ultimately it is far beyond the scope of this discussion paper to highlight the mechanisms for how this will operate, but when that time arrives, the Protocol will be poised and ready to contribute meaningfully to its architecture. Despite it being somewhat further removed on our roadmap, it nevertheless aspirationally serves as a north star for the team, and an incredibly valuable canvas for agentic systems to work upon.

### Enter $TOKEN

With these bold ambitions set, the Protocol will not only need to conceive methods of funding and investing in this future, but it will also need to design and define an interoperative token for agent-to-agent commerce.

To solve for this, we propose the creation of a new KRC-20 token, hereafter "$TOKEN".

---

## 04 — Tokenomics

### A New Currency for a New Agent Economy

We propose utilising $TOKEN as the new currency for our services.

This may include premium visualisation tools and wallet trackers, memetic marketing agents, or even liquidity provision: all services will be denominated and captured in either $KAS or $TOKEN as fees. These fees should operate similarly to existing software-as-a-service subscription or pay-per-use type models: in exchange for $KAS or $TOKEN, a wallet address is provided access to key functions and services on our DeFi platform. These will accord with the descriptions provided above, but it will be helpful to use agentic services as an example of how such processes, and fees, will be rendered end to end.

### Example: Genesis Community Agents

Let us take, for example, the intended experience for our set of genesis agents, built upon the vibrant personalities of the KRC-20 memecoin ecosystem.

We assume that the user, in this case one of the project developers, has access to the treasury wallet, the address of which has been hardcoded and associated to the agent on the Protocol. They proceed to connect the wallet to the Protocol, effectively acting as their permission key for whatever services they want to utilise. In this way, we secure all services (agentic or otherwise) against a signed wallet address, creating a seamless permissioning structure in addition to an audit log that records wallet address behaviour on the Protocol.

Once the user has connected their wallet, their credentials determine which agents are available and for what functions. If they decide to enliven an agent, they simply need to interface with the system, inputting the necessary contextualisation, linked social credentials, and lastly any other manual parameter tuning as desired. Once completed, they will be provided with a price (denominated in $KAS or $TOKEN) for the provision of that agent for X tasks or Y days, plus network fees. The vast majority of this amount transforms into a corresponding amount of fiat which is used to then purchase compute tokens from cloud providers and power the agent. On agreeing to the fees, the user will submit it and then be prompted via their Kaspa wallet to sign and approve the transaction. Once this completes and the Vault wallet receives the $TOKEN, the agent then commences with whatever directives are set.

While we expounded this with respect to agentic services, the same is true for all other tools provided by the Protocol, albeit the mechanism of access will be easier. Pay $TOKEN and gain access to visualisers, explorers, trackers, and more, just like any other software business.

### Solving for Distribution

With it now clear that $TOKEN is essential to the provisioning and purchase of services on the Protocol, how then should it be distributed?

Ultimately, it will represent a stark, somewhat atypical, contrast to classical KRC-20 token distribution mechanisms. It is worth briefly discussing the pitfalls of the commonly accepted methods and approaches to releasing a token first, before expounding on our proposal.

In KRC-20, projects are typically marketed as '100% fair launch', meaning there is no token reservation for development teams, community, investors, advisors, or the vault. The resulting distribution curve is therefore unknown, though not totally random. Empirical observation and analysis reveals some fairly obvious patterns to suggest that it is, by design, *not* fairly launched: developer team wallets naturally front-run the mint in addition to other informed influencers, before information of the token release is communicated broadly to retail participants by these very insiders. This process sits at a delicate equilibrium:

- **Too much front-running** and the project will be labelled as 'unfair'; without retail participation there is no liquidity to derive development funds.
- **Too little front-running** and the team will need to sell their fairly meagre stakes down quickly, or invest further capital to fund subsequent exchange listing or development costs, resulting in massive incentive misalignment (i.e. 'work for free').

Thus, we have created a crippling liquidity paradox for development in the Kaspa ecosystem. More often than not, teams are forced into underinvesting simply to ensure a stable launch, but are then left with little to no financial incentive while being at the total mercy of centralised exchanges, dubious market makers, and ultimately a speculative community of retail investors. This is hardly a stable funding pathway for a team committed to transforming decentralised finance.

This information is all known because this is not the first KRC-20 token that our team is proposing or launching. In late 2024, we entered the ecosystem under $LEGACY, a memecoin deployed on KRC-20 that acted as our gateway to observe and understand many of these issues firsthand rather than by extension.

This also has played an important role in our tokenomic distribution, and we wish to reward our community of early holders and advisors for their belief in us and our efforts.

With that said, due to the evident and experienced challenges, we cannot opt for a similar orthodox strategy of token release. Instead, we will need to clearly define the mechanisms of $TOKEN distribution and the subsequent impacts on supply, price, and utility.

### Upon the 'Shoulders of Giants'

Fortunately for the Protocol, this path is not totally unclear; indeed there are many successful decentralised exchanges that have published seminal work detailing the intricacies of their own tokenomics, providing us a stable blueprint to reference. In particular, we focus deeply on two projects, **Uniswap** and **Hyperliquid**, as instructive examples of how to build robust and resilient tokenomic frameworks capable of withstanding attack and platform devaluation.

Similar to UNI, we imagine $TOKEN as a utility token that dictates network and exchange behaviour. As such, our proposed tokenomic distribution follows a similar pattern to theirs with some slight exceptions. While we will discuss the benefits of this approach in detail below, the fundamentals are clear when compared against the current KRC-20 token issuance process to date, namely that: (1) incentives are aligned between the developer team and the community, (2) there is a consistent store of liquidity to power decentralised finance functions, and (3) there is a long-term vision on price maintenance and participation.

### Allocation Breakdown

**Total Supply: 10B Tokens**

We propose the creation of approximately 10,000,000,000 $TOKEN, fixing the total eventual supply to this number.

**Inflationary Protocol: 2% YoY @ 4 Years+**

We propose an inflationary protocol of 2% year-on-year approximately four (4) years after the genesis issuance. It should be noted that these tokens are to impact current circulating supply only, without breaching the conditions of the total eventual supply.

We propose the following tokenomics for $TOKEN:

- **Community Incentives (45%)**
  - **Airdrops (15%):** Distribute $TOKEN proportionally to early adopters and holders of $LEGACY in recognition of their support of the development team.
  - **Vault (30%):** Handles all fees attracted from Protocol activities (i.e. tools, agents, staking, DEX), and equally provisions rewards for users to provide liquidity to KRC-20 trading pairs on decentralised exchanges by rewarding them with $TOKEN. This helps establish healthy market liquidity.
- **Team and Advisors (15%)\*:** Allocate a portion to the core team and advisors, with vesting schedules to ensure long-term commitment and alignment with the project's success.
- **Foundation Reserve (15%)\*:** Reserve a portion of tokens for the long-term development and sustainability of the ecosystem. This can be used for funding future initiatives, partnerships, and unforeseen circumstances. We intend to donate at least 5% of this to the Kaspa Foundation Treasury Wallet.
- **Private/Public Sale (25%):** Conduct a private sale to verified KRC-20 developer teams first, before then allowing wider community participation.

*\*Subject to a multi-year vesting schedule (TBD). 10% cliff at M1, vesting monthly thereafter.*

### $LEGACY, A New Horizon

It is important that we address $LEGACY and our intentions around seamlessly migrating its relevance to the Protocol. Ultimately, we believe there are three attractive considerations for $LEGACY holders that preserve the long-term value. We will outline our intentions below for the community.

#### (1) Airdrop versus Swap/Burn

We considered at length the best possible mechanism for rewarding our $LEGACY holders with the creation of the Protocol. While several options were available, we believed that ultimately there are paths in which both tokens can co-exist in productive ways. If we wanted to fully eliminate the token, a Swap/Burn mechanic would have likely been immediately implemented, but it carried significant risks.

For example, creating a Swap/Burn effectively means that you're setting the price of $TOKEN with reference to $LEGACY's price. This creates additional complexity given that the latter is listed across a number of centralised exchanges which have had liquidity and fees provisioned. Ignoring the obvious sunk-cost fallacy, an immediate Swap/Burn likely creates a 'panic signal' that the community needs to dump their $LEGACY fast if they don't want the corresponding $TOKEN. This punishes holders that may not be able to transact synchronously and additionally warps the exchange's pricing drastically. Admittedly the opposite might also be true: assuming the Swap/Burn occurs before any Private/Public sale, value-seekers may instead try and stack $LEGACY speculatively to convert to $TOKEN en masse, and large insiders may manipulate the token. This could result in a number of unforeseen outcomes, such as these holders 'holding the token hostage' as dead supply, or worse, speculatively driving the price to an unusable threshold and diminishing all utility.

As a result, we propose utilising an Airdrop mechanic, and applying a conversion function of total holding and length to generate a corresponding $TOKEN balance which is unlocked in parallel to the Private/Public sale. This should, amongst other proposals, hold the price of $LEGACY stable for community holders.

#### (2) Staking Rewards versus Staked Swap/Burn

With this established, the next question relates to the long-term treatment of $LEGACY generally. Here we again have more options, all of which centrally relate to whether we want to keep the token and whether there is long-term value associated with it. If there is limited value or almost none (because the development team is focused on the Protocol) then we have several options available.

Our first is that we can treat $LEGACY like any other KRC-20 memecoin swap pair and incentivise users to stake the token in exchange for liquidity rewards. The counterpoint to this is that the entire development team will have moved to the Protocol, and it is unlikely that any future developments will be made on $LEGACY. As a result, the token is only then valuable if we assign it new utility in the Protocol, separate to the other KRC-20 projects. We discuss this in point (3) on governance, but believe there is value that can be attached to the token on an ongoing basis. Furthermore, we note that maintenance of a trade pair (i.e. $LEGACY/$TOKEN, $LEGACY/KAS) will be an essential function of the decentralised exchange.

Our second (assuming we want to remove the token entirely) is that we can propose a Staked Swap/Burn to try and eliminate the risks proposed in (1). This means that immediate selling pressure on $LEGACY is reduced and gradually we can drain central exchanges of the token and have users provided $TOKEN in exchange for it. We would then elect for the Vault to send this accumulated $LEGACY to the burn wallet and remove it from circulation. This would also likely protect holders who might have missed an immediate Swap/Burn window and provides them some longer timeline to dispose of their balance.

Either is technically possible, but fundamentally the decision should turn to whether we want $LEGACY to remain present in the KRC-20 ecosystem. We extend this point by highlighting that if we choose not to allow $TOKEN to be traded publicly on central exchanges, then users can instead use $LEGACY as that proxy to gain access to $TOKEN, either initially through liquidity rewards or later by way of trade pair. It then follows that the price of $LEGACY is likely to increase, assuming that the Private/Public sale fully occurs and there is no more $TOKEN available.

These options require careful evaluation, and the final choice between them is a key open decision for the team.

#### (3) Governance Option

One final consideration to resolve points regarding $LEGACY utility is to accord it governance votes. Ordinarily, a network like the Protocol would tie this to $TOKEN balance, but functionally, a lot of $TOKEN will arguably be trading wallets frequently between our users, the Vault, and ultimately speculative investors. In order to offset this somewhat, we could create a function that converts $LEGACY balance to a corresponding amount of votes above and beyond that applied to $TOKEN. This likely resolves several key issues: (1) it rewards our earliest true believers and provides them voting rights in the future of the Protocol, (2) it preserves the life of $LEGACY in the KRC-20 ecosystem by provisioning some increased utility, and (3) it may be speculatively invested upon for those governance rights, creating price pressure.

One further point worth discussing here is what becomes of the votes then afforded to either (a) staked $LEGACY balances or (b) the liquidity provided to centralised exchanges. In both these cases, the resolution is simple: those votes will be held by the developer team and free to utilise as proxy. If holders therefore want to participate in governance, they will need to unstake their balances.

### Concluding Tokenomics

We believe, having evaluated similar programs and protocols, we have arrived at an outcome that benefits all parties while mitigating downside risks. Ultimately, there are still a number of assumptions underpinning the economics, but we will need to deploy our approach to understand the real implications of such.

---

## 05 — Revenue Streams & Fees

### Revenue Streams

Many or most functions on the Protocol will attract transaction fees, denominated in either $KAS or $TOKEN. It will be critical to ascertain the base-level economics here of how the Vault will operate, and whether we want to create fixed limits and controls for maintaining these payment systems and structures.

### $KAS

The Protocol will always require a high balance of $KAS because it provides the central bridge to other ecosystems and fiat. As a result, especially initially, we may choose to denominate most functions in $KAS (with the exception of agentic functions) to increase our reserves. This also provides us the ability to create a large liquidity pool of $KAS to build further DeFi services, and it is worth considering whether to immediately open a $KAS/$TOKEN swap pair in addition to providing $TOKEN rewards for staked $KAS. As the network matures, we may be able to gradually shift across to provisioning more services in $TOKEN.

### $TOKEN

We propose $TOKEN immediately for usage with our agentic services. This means that by design our early users (i.e. other KRC-20 projects) will either need to be holders of $LEGACY to pool their $TOKEN reserves, and/or will need to participate aggressively in our Private/Public Sale. This should ensure we're able to rapidly stabilise the price of $TOKEN, in addition to charging the treasury with a significant amount of corresponding $KAS.

### Dynamic Pricing

We also have an ability to modulate the prices of services by examining the current state of the Vault and using price signals to drive it directionally:

- If we want **more** $KAS or $TOKEN, we can **reduce** the base price to attract more inflows and fill liquidity reserves.
- If we want **less** $KAS or $TOKEN, we can **increase** the base price to drain liquidity reserves.

This provides us with an even further degree of treasury control that we can utilise to our advantage.

### Visibility Pricing & Fee Structure

We aim to provide a number of tools and services for free despite data and compute costs being incurred. We are able to do this by providing augmented tools and trackers to individuals who pay approximately [TBD] KAS/month for ongoing access to these premium tools.

This pricing structure has been set in a way which fundamentally 'covers off' the free-rider problem, while still accurately pricing the value of the services provided. We will occasionally revisit this pricing as additional products and services are released.

### Utility Pricing & Fee Structure

Our agentic services are rendered in $TOKEN plus fees for the service. The goal of this pricing model is to (as much as possible) abstract away movements in $TOKEN or $KAS and ensure stability and reliability, both of the cost and the service provided.

Fundamentally this is necessary because in an ideal state, we want to encourage a self-perpetuating market motion:

1. **User buys $TOKEN/$KAS**
   - User gets $TOKEN
   - Vault gets $KAS
2. **User activates Agent with $TOKEN (+Fees)**
   - User gets AGENT
   - Vault gets $TOKEN / spends $KAS → fiat
3. **Vault re-lists $TOKEN in Swap Pair ($TOKEN/$KAS)**
4. **User buys $TOKEN/$KAS** (repeat)

In this way, we should be able to sufficiently generate liquidity in the form of $KAS price movements and network fees. At this point we are not accounting for any additional arbitrage of agent cost and price, but it remains another revenue lever should we choose to explore it.

### Liquidity Pricing & Fee Structure

While this is ultimately conditional on the computational load and cost of smart contracts once deployed on Kaspa, let us assume a fee structure entirely identical to the implementation in Uniswap v3. It is highly likely that we will simply fork this implementation and deploy. Further, we will need to model individual liquidity pool pairs to arrive at stable conclusions for APY on $TOKEN, and dynamically adjust these according to total staked balances and market demand or supply of various tokens.

We believe these give us sufficient diversification in revenue streams to build a highly profitable and successful network in the long run, and ultimately we can discuss future proposals for dividend dispersal or payment via our governance protocols.

---

## 06 — Highlighting Risks

### On Risk

Lastly, we aim to highlight some key risks worth noting in the creation of this ambitious model, of which there are many. While we aim to create something of transformative value, it would be remiss not to acknowledge the plethora of exploits that have occurred for almost a decade in this space.

### General Risks

#### Code & Contract Exploits

We will need to ensure a level of robustness on the implementation of a range of features. Predominantly, anything related to Wallet Connection and management needs to be examined deeply for possible exploits and attack vectors. In fact, this is generally true of everything in the Protocol, as we will need to ensure that our cybersecurity standards are generally much higher than commercial consumer-grade projects.

#### Wallet Exploits

We will also need to be aware of potential copycats hoping to conduct wallet exploits. It is well understood in cryptocurrency to consistently check the contracts being signed and transacted via wallets, but the risk cannot be understated. Additionally, we should consistently warn users, especially those interacting with developer wallets, to routinely disconnect from the Protocol if not in active use.

### Specific Risks

#### Sybil Attacks

If we decide to run an Airdrop for $TOKEN, we will need to devise meticulous logic to ensure that we are not exposed to a potential Sybil attack. These are generally executed by holders sharding their holdings across a number of wallets to maximise 'on-curve' airdrops with diminishing cliffs. While worth noting, it is functionally hard to stop without consistently monitoring wallet movement; we therefore already proposed a hybridised approach that algorithmically combines both quantum of holding and length of time to best prevent these types of attacks.

#### Agentic Identity Attacks (AIA)

Unique to the Protocol as an agentic system, we will need to ensure that malicious users do not try and 'hijack' the identity of a pre-existing agent or 'character' without the consent of the intellectual property holder. At a high level, this is best implemented with temperature checks and filters in the contextualisation module, in addition to specifying a 'blacklist' of characters and accounts that cannot be replicated or recreated. In order to at least mitigate these attacks somewhat, it serves to reason that prior to agent activation there is at least a single HIL ("human-in-loop") to cross-check the proposal and whether it conforms to our Terms of Use, which by extension should and must obey international intellectual property protections and rights.

---

## 07 — Conclusion

In this discussion paper we outline the potential to innovate an entirely novel decentralised and agentic finance layer on the Kaspa blockchain. We provided an assessment of available alternate L1 options, examined underlying problems and challenges in the KRC-20 ecosystem, and ultimately arrived at our unique approach to the tools, systems, and platform that need to be built in order to create a better, and fairer, future for cryptocurrency.

We noted the various products we propose within our ecosystem, and highlighted the need for a secure, safe, and cheap protocol to underpin these innovations, leading us directly to $TOKEN, built upon KRC-20.

Finally, we stepped through the important tokenomic factors to consider, the obvious problems plaguing current approaches, and our unique approach to revenue streams and managing risk.

Ultimately, we believe that this moment will redefine finance and, arguably, commerce, and we want this work to play a part in shaping that transformation.

---

— C

---

## Digital Dogs: The Case for Greyhound Racing On-Chain

Source: https://www.chrswthrs.xyz/papers/digitising-the-dog-derby

## 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:*

| Hound | Stake (`$TOKEN`) |
| --- | --- |
| 1 | 60.00 |
| 2 | 140.00 |
| 3 | 24.00 |
| 4 | 110.00 |
| 5 | 220.00 |
| 6 | 94.00 |

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:

```solidity
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.

|  | Argussian | Peritasian | Lelapsian | Eosian |
| --- | --- | --- | --- | --- |
| **Argussian** | *Argussian* | *Peritasian* | *Lelapsian* | *Eosian* |
| **Peritasian** | *Peritasian* | *Peritasian* | *Lelapsian* | *Eosian* |
| **Lelapsian** | *Lelapsian* | *Lelapsian* | *Lelapsian* | *Eosian* |
| **Eosian** | *Eosian* | *Eosian* | *Eosian* | *Eosian* |

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.*

---

## Voice ordering and reservations

Source: https://www.chrswthrs.xyz/projects/voice-agent

## Context

The voice-AI category for hospitality is fragmenting into single-purpose vendors: one provider handles orders, another reservations, another deposit collection. Each must then be integrated against a third-party point-of-sale, booking system, and payment provider, multiplying the surface of dependence and error. The platform on which this work was carried out already maintained ownership of those primitives: order pipeline, menu catalogue, payment service, and reservations system. What was missing was not the engine but the conversational front door.

## Design

- A microservice fronting a conversational voice agent. Inbound calls resolve to a business, a branch, and the streams that branch is provisioned for: ordering, reservations, or both.
- A *two flows, one entry point* model. Per-venue provisioning toggles drive a split-flow suggestor at call start, filtering the agent's tools and greeting to the surfaces the venue actually offers.
- A *payment-first ordering* principle: an order is never written until payment is confirmed. This eliminates an entire class of fault (orders placed but never paid) that arises whenever ordering and settlement are loosely coupled.
- Reservations reuse the existing prepayment state machine rather than re-implementing it. The voice layer relays a deposit link and observes settlement; the underlying booking remains the authoritative record.
- A shared-number entry model using parameterised messaging links carrying a per-business entry code. Onboarding is therefore not gated on procuring a phone number per venue.

## Outcome

The result is a unified voice surface that competes on each axis with the single-purpose vendors, precisely because the underlying platform is the system of record for orders, menu, payment, and bookings, rather than an integrator into someone else's. The model is also extensible: any future conversational channel (chat, walk-in kiosk) can be layered above the same provisioning and state primitives.

## Stack

Go · Echo · Redis (session and cart state) · GORM · MySQL · provider-agnostic conversation runtime · messaging channel abstraction (WhatsApp / SMS).

---

## Partner menu-mapping copilot

Source: https://www.chrswthrs.xyz/projects/mapping-copilot

## Context

Onboarding a new partner system (point-of-sale, inventory, or enterprise resource planning) required, on average, several weeks of effort per partner. The dominant cost was menu mapping: an internal engineer hand-matching the partner's items, modifiers, and modifier groups against the platform's canonical catalogue. The work was made slow and error-prone by multilingual titles, deeply nested modifier groups, and the wide variance of incoming formats: comma-separated files, JSON, screenshots, and in some cases photographs of printed menus. The throughput required by the business could not be sustained by linear human effort.

## Design

- A dedicated mapping service with input adapters for ingesting partner menus in any reasonable shape and normalising them into a canonical tree.
- A hybrid retrieval pipeline: lexical (trigram + token) matching, embedding-based cosine similarity, price-band filtering, and hierarchical context (modifiers gated by their parent item's mapping).
- A large-language-model reranker over the top candidates, with prompt caching for the canonical menu and a per-partner few-shot pool assembled from prior corrections. The model sharpens on a given partner over time without fine-tuning.
- A confidence gate: high-confidence mappings auto-apply; everything below threshold is queued for manual review.
- A hard safety boundary: allergen and dietary mismatches always drop to manual review, regardless of textual confidence. The line between "a week of effort saved" and "a wrong order in front of an allergic customer" is non-negotiable, and the architecture enforces that asymmetry.
- A per-partner monthly token budget enforced at the credential layer. AI is treated as a metered, billable platform service rather than as a free utility.

## Outcome

The mapping bottleneck collapses from weeks to hours for the typical partner. Equally important, the partner can self-serve from the first day of onboarding rather than waiting on a queue of internal engineers. The same retrieval primitive is now reused as a first-class endpoint by other AI surfaces on the platform (see the agent-facing API design).

## Stack

Go · Echo · Asynq · GORM · MySQL · LLM gateway (model-agnostic) · embedding API.

---

## Self-hosted support agent

Source: https://www.chrswthrs.xyz/projects/support-agent

## Context

The platform's prior live-chat support relied on a per-seat, low-code commercial product priced on conversation volume. As traffic scaled, expenditure outpaced delivered value, and the product remained brittle on the dimensions that matter most for support: it did not read tone, did not draw on the platform's knowledge base with any fidelity, and did not hand off cleanly when out of its depth. A rebuild was warranted.

## Design

- An edge worker sits between the chat widget and a model gateway, holding conversation state in a key-value store at the edge for low latency and predictable cost.
- A pluggable escalation pipeline composed of three layers: pre-inference keyword rules; model confidence checks; and post-inference sentiment evaluation. Any of these can trigger a clean handoff to a human operator.
- A curated knowledge base of platform articles, onboarding videos, and troubleshooting guides held in-repo as markdown and served to the model as cached grounding context. The knowledge base is the source of truth; the model has no other.
- Model routing on conversational class. Inexpensive, fast models answer high-frequency canonical questions; a stronger model is invoked only when the conversation becomes nuanced. The routing decision is itself a model call, but a cheap one.

## Outcome

Roughly an order-of-magnitude reduction in monthly infrastructure cost relative to the prior vendor, with the same widget integration on the customer side and a cleaner escalation path on the operator side. Median first-response latency is sub-second: an immediate acknowledgement is dispatched while the substantive reply is composed asynchronously, which both improves perceived responsiveness and decouples the user experience from upstream model latency variance.

## Stack

Cloudflare Workers · KV · TypeScript · multi-provider LLM gateway · structured JSON tool calls.

---

## Conversational analytics

Source: https://www.chrswthrs.xyz/projects/conversational-analytics

## Context

Operators on the platform have access to a substantial body of operational data: sales mix, item velocity, channel performance, hour-of-day patterns, and so on. The dashboards through which this data is surfaced are technically capable but suffer the familiar problem of discovery cost: most operators never open the screens that would reveal the insight they need. The artefacts exist; the path to them does not.

## Design

- A conversational interface in the administrative web client, backed by a large-language-model agent with tightly controlled tool access.
- A pre-generated, per-business comma-separated values (CSV) layer for the agent to query, rather than direct database access. The constraints are deliberate: blast radius is bounded, per-query cost is predictable, and the data plane is cacheable. The model never sees a database connection string and the database never sees raw user input.
- Iterative refinements across three axes: reliability (retry semantics, session state), performance (streaming responses, mitigation of cold starts), and observability (full conversation traces tied to business and authenticated user).

## Outcome

Operators surface in a single conversation findings that would have taken several screens to assemble. Cost-per-query is bounded and observable, and the architecture preserves the separation between user input and stored data, which is non-negotiable for a multi-tenant operational system.

## Stack

AWS Bedrock Agents · Python (AWS Lambda) · S3 · React / Redux administrative client.

---

## An API built for agents

Source: https://www.chrswthrs.xyz/projects/agent-api

## Context

Most "API access for AI" stories amount to a thin REST wrapper over endpoints originally designed for a single-tenant administrative client. The seams reveal themselves immediately under agent load. As soon as an autonomous agent must operate across multiple businesses, the authentication model breaks; the permission model leaks; and *item resolution*, the act of mapping the user's natural-language reference to the correct catalogue identifier, becomes the bottleneck that the wrapper was never designed to absorb.

## Design

- A multi-tenant authentication strategy granting an agent scoped access across many businesses without requiring a backend role-based access-control rewrite. The mechanism is a pool of business-scoped sessions managed at the gateway layer.
- A gateway routing layer so the agent communicates with a single stable surface even as upstream services evolve. The agent's contract is therefore decoupled from internal service boundaries.
- *Item resolution* as a first-class endpoint: free text in, ranked canonical identifiers out, served by the same retrieval pipeline used elsewhere in the platform for partner menu mapping. Resolution is treated as a primitive of the agent platform, not a per-feature convenience.
- An explicit *out-of-scope* boundary for destructive operations. Operations whose effects cannot be cheaply undone remain outside the agent's reach for the foreseeable future. The decision is treated as a structural constraint, not a settings flag.

## Outcome

Agentic features ship without forcing a wholesale authentication rewrite. The item-resolution primitive is reused across multiple AI surfaces (voice ordering, support, onboarding), yielding a compounding architectural return on a piece of infrastructure that would otherwise have been reimplemented several times.

## Stack

Go services · Kong gateway · OAuth2 / service-account tokens · shared retrieval service.

---

## Agentic merchant onboarding

Source: https://www.chrswthrs.xyz/projects/merchant-onboarding

## Context

Standing up a new merchant on the platform (its business, brands, branches, users, menus, and integrations) was a documented, multi-hour, multi-procedure exercise performed by a human onboarding specialist. Every field in the intake form mapped to a known request body; every step had a fixed dependency order. There was almost no judgment in the work and yet it consumed specialist hours and queued merchants behind it. The task was a deterministic pipeline being treated as bespoke labour.

## Design

- A new agent type built on the platform's internal agent runtime but operationally separated from the live merchant-facing agents. The execution model differs in kind (long-running, multi-step, idempotent, and resumable) and therefore warrants a distinct runtime profile.
- An ingest worker that validates form payloads, normalises data (phone formatting, geocoding, image hosting), writes a durable task row, and queues execution. Validation is *prior* to enqueue; failed payloads never enter the run plane.
- A run model with explicit checkpointing, so a partially completed onboarding can resume from its last successful step rather than restarting from zero. This is the property that makes the system tolerable at scale.
- Status reporting back to the originating channel (a messaging notification, a database row, or a chat reply) so a human operator can remain informed without monitoring the run.

## Outcome

A deterministic data pipeline is now treated as one. Specialist time is preserved for the edge cases that warrant it, and merchants no longer queue behind work that the system can complete on its own.

## Stack

Cloudflare Workers + D1 + Queues (ingest plane) · custom agent runtime (execution plane) · internal administrative APIs.

---

## Agent-run multilingual site

Source: https://www.chrswthrs.xyz/projects/agent-built-content-site

## Context

The platform's public marketing, blog, and help-centre estate needed to ship across multiple languages and remain current with product changes. Achieving this with a human content team scales linearly with languages and inversely with cadence, precisely the wrong functional shape for the publishing problem at hand. The natural response was to delegate the labour to agents and reserve human attention for the editorial role.

## Design

- A Next.js site whose content layer is writable by an agent team through a tightly scoped contract. The agents do not write to arbitrary parts of the repository; the writable surface is delimited and validated.
- Lazy incremental static regeneration tuned to the actual access pattern, so a high-volume, agent-driven commit cadence does not blow up edge infrastructure costs.
- Agent-facing rules: a content style guide and a deployment guide that the agents are required to read on every run. Output stays on-brand; the deploy surface stays predictable.
- A cost-aware operating posture. Diagnosis revealed that build frequency, not page count, was the driver of infrastructure spend. Commit batching was adjusted accordingly. This is a small finding but a representative one: when the labour is delegated to agents, the cost model of the *infrastructure* becomes the rate-limiting concern.

## Outcome

Several hundred agent-authored commits in a typical fortnight, across languages and content types, with the human role narrowed to direction-setting and editorial review. The cost envelope is comprehensible and bounded.

## Stack

Next.js · Vercel · MDX / content collections · agent toolchain with repository-scoped write access.

---

## Two-way reviews, model-drafted replies

Source: https://www.chrswthrs.xyz/projects/review-responses

## Context

The platform consumed third-party reviews via a scraping pipeline for purposes of display, but operators could not reply to those reviews from within the platform itself. Reply at scale also introduces a quality problem of its own: a generic response is worse than no response, and a templated reply that fails to address the actual complaint actively damages operator trust.

## Design

- A migration off the prior scraping pipeline onto the official first-party business-profile API, restoring read-write access at the protocol level.
- A model-drafted response generator constrained by business-specific tone, brand-specific vocabulary, and the original review itself as grounding context.
- A draft-then-approve user experience. Operators retain control over what is published under their name. A clear path is reserved for automatic publication of replies to high-confidence positive reviews once a per-business trust threshold is met; everything else passes through review.

## Outcome

Reviews become a two-way operator channel inside the platform rather than a passive feed, without surrendering tonal control to a generic chatbot. The same draft-then-approve pattern has subsequently been re-applied to other domains in which the cost of a bad outbound message is asymmetric with respect to the cost of a delayed one.

## Stack

Go services (integration management and storage) · LLM gateway · third-party business-profile API · React administrative client.