Unlocking Agentic DeFi: The Next Frontier

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

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

Footnotes

1. GhostDAG Whitepaper. ↩