added docs
This commit is contained in:
giteadmin
parent
b8dc42201a
commit
548fd006c1
11 changed files with 646 additions and 6 deletions
3
.gitignore
vendored
3
.gitignore
vendored
|
|
@ -7,9 +7,6 @@ out/
|
||||||
/broadcast/*/31337/
|
/broadcast/*/31337/
|
||||||
/broadcast/**/dry-run/
|
/broadcast/**/dry-run/
|
||||||
|
|
||||||
# Docs
|
|
||||||
docs/
|
|
||||||
|
|
||||||
# Dotenv file
|
# Dotenv file
|
||||||
.env
|
.env
|
||||||
.secret
|
.secret
|
||||||
|
|
|
||||||
3
web/.vscode/extensions.json
vendored
3
web/.vscode/extensions.json
vendored
|
|
@ -1,3 +0,0 @@
|
||||||
{
|
|
||||||
"recommendations": ["Vue.volar"]
|
|
||||||
}
|
|
||||||
38
web/src/views/docs/FAQ.vue
Normal file
38
web/src/views/docs/FAQ.vue
Normal file
|
|
@ -0,0 +1,38 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1 id="first">FAQ</h1>
|
||||||
|
<h3>Where to buy $KRK?</h3>
|
||||||
|
<p>Once launched you can buy $KRK on Uniswap on Base Layer 2.</p>
|
||||||
|
<h3>What is the utility of $KRK?</h3>
|
||||||
|
<p>$KRK serves as training data for the AI agent and will eventually generate returns through cross-pool liquidity management.</p>
|
||||||
|
<h3>Why is the liquidity unruggable?</h3>
|
||||||
|
<p>Liquidity is permanently locked in Uniswap and managed by immutable contracts, with 75-95% ETH reserved in the Floor position to prevent full withdrawals even through a bank run event.</p>
|
||||||
|
<h3>How often does supply expand?</h3>
|
||||||
|
<p>The AI liquidity manager mints new $KRK based on market conditions - typically during sustained buying pressure or liquidity needs.</p>
|
||||||
|
<h3>What happens to the supply during price drops?</h3>
|
||||||
|
<p>The protocol automatically burns surplus $KRK from the liquidity pool to stabilize prices during sell pressure.</p>
|
||||||
|
<h3>Is the AI Agent owned by anyone?</h3>
|
||||||
|
<p>The AI Agent is fully sovereign. No owner or admin can intervene or change the behaviour of the agent. It operates in a closed environment on-chain.</p>
|
||||||
|
<h3>How does the AI agent respond to volatile markets?</h3>
|
||||||
|
<p>The agent adjusts the Anchor width, Discovery depth of the liquidity positions, and capital allocation based on volatility ratios and staking signals in real time.</p>
|
||||||
|
<h3>Is my $KRK at risk if the AI fails?</h3>
|
||||||
|
<p>Yes – Per the disclaimer, failed AI decisions could negatively impact $KRK's value. The Floor position mitigates but doesn't eliminate this risk.</p>
|
||||||
|
<h3>Are there any fees when using the protocol?</h3>
|
||||||
|
<p>There are no fees and there is no fee switch. Kraiken is an immutable protocol that has been fair launched and will continue so.</p>
|
||||||
|
<h3>How can I stake my $KRK?</h3>
|
||||||
|
<p>You can get access to staking by contacting the team.</p>
|
||||||
|
<h3>Can the protocol code be changed later?</h3>
|
||||||
|
<p>No – All contracts are permanently immutable after deployment. Liquidity Manager and AI agent operate autonomously with no upgrade path or admin controls.</p>
|
||||||
|
<h3>Are there team allocations or unlocks?</h3>
|
||||||
|
<p>No – Kraiken is a fair-launch protocol with zero allocations for teams or investors. All tokens enter circulation via the liquidity pool.</p>
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
22
web/src/views/docs/Harberger Tax.vue
Normal file
22
web/src/views/docs/Harberger Tax.vue
Normal file
|
|
@ -0,0 +1,22 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1 id="first">Fair Market Mechanism</h1>
|
||||||
|
<p>The Harberger Tax, developed by economist Arnold Harberger and popularized in the book Radical Markets and the RadicalxChange movement’s “Partial Common Ownership” concept, is a system where property owners pay a tax based on their own assessed value of their property. However, they must be willing to sell the property at that value to anyone who wants to buy it. This approach encourages owners to be honest about the value of their assets and helps allocate resources to those who value them the most.</p>
|
||||||
|
<h2 id="second">Implementation in the Crypto Context</h2>
|
||||||
|
<p>In crypto, limited assets or positions are often held by a select few without options for redistributing ownership—examples include early investors, protocol teams, fee distributions, multisig holders, NFT owners etc. The HARBERG protocol aims to challenge the current model of protocol ownership and test an alternative approach.</p>
|
||||||
|
<h2 id="third">Key Differences</h2>
|
||||||
|
<p>In the traditional model, the value of the asset is constantly changeable to reflect the current market value and dynamics. In the HARBERG protocol, the tax rate is constantly changeable, and owners must evaluate it regularly to retain their ownership positions.
|
||||||
|
</p>
|
||||||
|
<h3>Read More:</h3>
|
||||||
|
<p> See <a href="website.org">Harberger Tax Blog Post</a> or <a href="website.org">Owner Tax</a> </p>
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
24
web/src/views/docs/Holders.vue
Normal file
24
web/src/views/docs/Holders.vue
Normal file
|
|
@ -0,0 +1,24 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1 id="first">Generate Passive Income</h1>
|
||||||
|
<p>In traditional protocol designs, holders benefit from a protocol’s success only indirectly through an increase in token price. HARBERG changes this by allowing holders to earn directly through a passive income stream funded by protocol owners, who pay for the privilege of staying in their positions of power. </p>
|
||||||
|
<br>
|
||||||
|
<p>Token holders are essential for decentralisation, governance and decision-making in crypto. Their role is key to a project’s long-term success. It’s only fair that token holders should have the right to become owners of the very protocol they support.</p>
|
||||||
|
<h2 id="second">Buy $HARB</h2>
|
||||||
|
<p> $HARB tokens and the Harberg Protocol are deployed on Base an $ETHeum Layer 2. $HARB can be bought on <a href="uniswap.org">Uniswap</a> there. </p>
|
||||||
|
<h2 id="third">Passive Income</h2>
|
||||||
|
<p>By holding $HARB, holders can claim a passive income funded by the owner’s tax. The more owners are competing for limited owner slots the higher the tax for the token holders.</p>
|
||||||
|
<p>The longer the token is held, the more tax holders can claim. No protocol fee is taken. </p>
|
||||||
|
<h2 id="fourth">Sell $HARB</h2>
|
||||||
|
<p>$HARB can be sold anytime on <a href="uniswap.org">Uniswap</a> </p>
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
52
web/src/views/docs/Introduction.vue
Normal file
52
web/src/views/docs/Introduction.vue
Normal file
|
|
@ -0,0 +1,52 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1 id="first">Introduction</h1>
|
||||||
|
<p>Welcome to KrAIken, a decentralized finance (DeFi) protocol that integrates artificial intelligence (AI) to optimize liquidity management. KrAIken operates autonomously, ensuring on-chain execution of adaptive liquidity strategies.</p>
|
||||||
|
<p>At the core of KrAIken is the $KRK token and its liquidity pool, which acts as a testing ground and learning environment for the AI agent. The agent dynamically adjusts liquidity positions based on real-time market data, aiming to maintain stability and efficiency within the pool. Disclaimer: If the agent fails in its tasks, it may negatively impact the value of $KRK.</p>
|
||||||
|
<p>This initiative not only tests the resilience of the protocol but also offers the community an opportunity to interact with and evaluate its performance. Through continuous iteration, KrAIken’s AI will eventually expand to other Uniswap liquidity pools, generating profits through liquidity fees and creating real utility for the protocol and the $KRK token.</p>
|
||||||
|
<p>KrAIken is not just another centralized, hosted large language model (LLM). It is fully sovereign. Developed by <a href="https://sovraigns.network">SovrAIgns.network</a>, KrAIken represents an evolution in DeFi, combining decentralized finance principles with adaptive AI to create a truly innovative financial platform.</p>
|
||||||
|
<p>In the chapters ahead, we will delve into KrAIken’s liquidity management strategies, the architecture of its AI agent, the tokenomics of $KRK, and staking mechanisms available to our community members.</p>
|
||||||
|
<br>
|
||||||
|
<pre>
|
||||||
|
..-.
|
||||||
|
-+:.:==-=++=-
|
||||||
|
-=++++=++==+++++:
|
||||||
|
.=+++===:=++++==+++= :---:::
|
||||||
|
=-++=--. -+++**+: .-=======::
|
||||||
|
=-+*+:. :*****+ :--========-=:
|
||||||
|
+=**+. :+***+ .++===-==+++=+==: :::
|
||||||
|
=+**+-:--==-: *****: +**+===+=+++++++=: .--=--:: .::.
|
||||||
|
-=+*+=::- :--: *****- =***++┬┐*+ +┬┐+- : ======-:-=--: --
|
||||||
|
:--=++:.::+.:- -****=. :-++++**└┴=**+└┴+++=: =+=++++==+=----: --
|
||||||
|
*:*+++= :*+==+=..=++-. -****++ -+**********+*+*++: =- =+++++++++++=+=--==: :=-
|
||||||
|
:*:+*******+*=-+=-:.+-++-: =++***++ -=**********+││*****+=+ =+***++++== .==++===== -==
|
||||||
|
*:*:*:*:****+*++++-- :***= :++*****+=.=*******++***││****+=+*- .++****++-+ +=-+=++==-: ===
|
||||||
|
***:: *+*+++++- :+**= *****************++*+*****+++*+**********+*+: =+++++++.- .===
|
||||||
|
*: ++*++++=. =+***+- *********::****+=+=****+-=+********::**+= +++++++= . --=
|
||||||
|
+===++++. :+******= +******:::****+=:=+****-:=+****:::::**** .:++==-= ::--
|
||||||
|
:-+*+++++= :-=*+****:: ::::**:*****=::::*****=:.+*****::***=..:----. ::-++++=== -:
|
||||||
|
+.:=+++++*+:.:=+*+*****:*:::******+-::::-****++:::-********+-+++++++++=- .:+++++=++--. -==-
|
||||||
|
+:** +***+-=++++++=::.==+******+********+:::::=******+=::::******++**+++++++++=-. ++++++++++:.: --:
|
||||||
|
**::*+****+++++==:+=++*= :--=******=******+=::::::*******++:::::+***=***+++:::=-----:: =+==++++==:----:
|
||||||
|
***=== =++++=-+=*++++::-::++**+=+***+==::::::********+++::::+***+=++++:: ----:.==+++++++=--::
|
||||||
|
+=*++=+++:--.+++++-++++=:::::=+**********++=:::::++==+++ ::::..=++++*++-----:
|
||||||
|
-+-+++*+++=.:--===:==+===-=+===+****++++*++++:::::-=.=== ..:-----=++++++::+:
|
||||||
|
++++**++++-:-..--=. :--- ---==========- . +=+-:::::.--=-+======-.=++++++++::
|
||||||
|
:+++++++++-::..:-::=: . .:-.: . . :-.:--.::--:=---:.:::- -++++:+:
|
||||||
|
:--:-+++==-:- -: .- :---=-=--=-: . =++++*+=
|
||||||
|
: .:.=-:.--:.... : : :.::---=-. .:-===+++=
|
||||||
|
:: .. .... :. . - ::: . . .. .====+++******:.:
|
||||||
|
:-..-==: . : : :====++++++++++*****++++=-++**************=+
|
||||||
|
***-:::::::= ++++- -+=- .--:::--=-= ++++++=++=++++==+ *++********** ******
|
||||||
|
</pre>
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
87
web/src/views/docs/Liquidity-Management.vue
Normal file
87
web/src/views/docs/Liquidity-Management.vue
Normal file
|
|
@ -0,0 +1,87 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1>Liquidity Management</h1>
|
||||||
|
|
||||||
|
<p>The liquidity of $KRK tokens is fully managed by an immutable Liquidity Manager (LM) contract. This contract governs the minting, burning, and allocation of liquidity to ensure market stability, efficient trading, and adaptive responses to market dynamics. The LM operates through three distinct liquidity positions: Floor, Anchor, and Discovery (inspired by <a href="https://docs.baseline.markets/btokenomics/dynamic_liquidity#protocol-owned-liquidity-positions">Baseline</a>). Each serves a specific role in maintaining a balanced and resilient ecosystem.</p>
|
||||||
|
|
||||||
|
<p>The Liquidity Manager operates exclusively on a Uniswap V3 pool on the Base network with a tick spacing of 200, equivalent to 1% fee tier. Other liquidity pools on different networks will only receive liquidity indirectly through arbitrage.</p>
|
||||||
|
|
||||||
|
<br>
|
||||||
|
<pre>
|
||||||
|
▲ ┌─────────────┐
|
||||||
|
│ │ ┌─┐ │
|
||||||
|
│ Floor │ │%│ $ETH │
|
||||||
|
│ ┌─┐ │ └─┘ │
|
||||||
|
│ │%│ │ ┌─┐ │
|
||||||
|
│ │%│ │ │+│ $KRK │
|
||||||
|
│ │%│ │ └─┘ │
|
||||||
|
│ │%│ └─────────────┘
|
||||||
|
│ │%│
|
||||||
|
│ │%│
|
||||||
|
│ │%│
|
||||||
|
L │ │%│
|
||||||
|
i │ │%│
|
||||||
|
q │ │%│ Discovery
|
||||||
|
u │ │%│
|
||||||
|
i │ │%│ ┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐
|
||||||
|
d │ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
i │ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
t │ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
y │ │%│ Anchor │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%│┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐│+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ └─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘
|
||||||
|
─┼─────────────────────────────────────────────────────────────────►
|
||||||
|
▲ Price
|
||||||
|
current Price
|
||||||
|
</pre>
|
||||||
|
<h2>Floor Position</h2>
|
||||||
|
|
||||||
|
<p>The Floor is a highly concentrated liquidity position within a narrow price range. Its primary function is to provide a guaranteed minimum buyback price for $KRK tokens. This reserve stabilizes the protocol by ensuring that token holders always have a predictable exit value. As the protocol grows, the LM allocates more $ETH to the Floor, increasing its depth and reliability. Between 75% and 95% of all $ETH managed by the protocol is typically held in the Floor position.</p>
|
||||||
|
|
||||||
|
<p>A critical aspect of the Floor position is its use of Volume Weighted Average Price (VWAP) to determine its pricing strategy. VWAP represents the average sale price of $KRK tokens weighted by trading volume, providing a kind of approximate and compressed memory over historic sales of tokens from its liquidity. The LM calculates the VWAP using cumulative trade data, ensuring that on average tokens are bought back for cheaper than they were sold for. By anchoring the protocol’s liquidity to a VWAP-adjusted price, the system retains a sober approach to Floor positioning while allowing for market-responsive adjustments of Anchor and Discovery.</p>
|
||||||
|
|
||||||
|
<h2>Anchor Position</h2>
|
||||||
|
|
||||||
|
<p>The Anchor position offers less liquidity depth than the Floor but spans a broader price range. It is always positioned at the current market price, ensuring its relevance to active trading. The size of the Anchor position dynamically adjusts based on the "sentiment" input, a value generated by an on-chain AI agent analyzing staking signals and trading data. Sentiment determines the allocation of 5% to 25% of the total $ETH supply to the Anchor, influencing its liquidity depth and responsiveness. This adaptive sizing strategy puts more capital at risk during market uptrends while adopting a defensive posture when sentiment turns negative. The exact adjustment strategy depends on the training embedded in the on-chain AI agent, which targets developing the token price and maximizing trading fees for the protocol. For more on staking signals, visit the "For Owners" chapter, and for details about the AI agent, see the "AI-Agent" chapter.</p>
|
||||||
|
|
||||||
|
<h2>Discovery Position</h2>
|
||||||
|
|
||||||
|
<p>The Discovery position provides the broadest price coverage and greater liquidity depth compared to the Anchor. It is designed for price exploration beyond the current range, supporting efficient trading during periods of high demand or significant market growth. Discovery covers a price range up to three times the current price, and holds liquidity at a depth twice as concentrated as the Anchor position. This ensures robust liquidity for price exploration while incentivizing trading activity in less active price ranges. $ETH accumulated in the Discovery position is periodically redistributed to the Floor and Anchor positions.</p>
|
||||||
|
|
||||||
|
<h2>Rebalancing Mechanism</h2>
|
||||||
|
|
||||||
|
<p>The Liquidity Manager rebalances the Floor, Anchor, and Discovery positions based on market price movements. This process is triggered through an open contract call that anyone can execute at any time. Before rebalancing occurs, the function ensures a key condition is met: the price must have moved significantly, surpassing a minimum amplitude threshold of twice the tick spacing (2%).</p>
|
||||||
|
|
||||||
|
<p>When the token price moves:</p>
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li><strong>Upwards:</strong> The Liquidity Manager reallocates more $ETH to the Floor position to enhance its stability and increases the size of the Discovery position for further price exploration. New $KRK tokens are minted to support this growth.</li>
|
||||||
|
<li><strong>Downwards:</strong> The Liquidity Manager reduces the Anchor and Discovery positions proportionally and burns excess tokens, maintaining equilibrium and reducing supply pressure.</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<p>This dynamic system ensures that the protocol responds effectively to market conditions while safeguarding token holders and traders. The contract is immutable, guaranteeing that neither the team nor any other entity can access or control the liquidity. Users are encouraged to review the code to understand the mechanics before participating.</p>
|
||||||
|
|
||||||
|
<h2>Risk Profile</h2>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
While the Liquidity Manager offers a "guaranteed minimum buyback" through the Floor position, the price is dynamic because some $ETH is always allocated to the Anchor position for active trading. This ensures efficient price discovery and liquidity optimization but also introduces variability in the Floor’s backing. Compared to systems like Baseline, which use similar Floor, Anchor, and Discovery positions, Kraiken operates with a more dynamic and risk-tolerant approach. This allows for potentially higher rewards but comes with increased exposure to market fluctuations.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
120
web/src/views/docs/Staking.vue
Normal file
120
web/src/views/docs/Staking.vue
Normal file
|
|
@ -0,0 +1,120 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1>Staking</h1>
|
||||||
|
<p>Staking has two important benefits:</p>
|
||||||
|
<p>1. It helps the AI Agent with market sentiment analysis.</p>
|
||||||
|
<p>2. It transparently rewards users that promote the $KRK token and the KrAIken protocol without the need of backdoor deals or insider allocation.</p>
|
||||||
|
<h2>1. Staking Slots</h2>
|
||||||
|
<p>As a token holder you can stake your $KRK tokens to claim staking slots and become a Staker of the KrAIken Protocol. Stakers earn a share of newly minted tokens when the token supply expands (see Tokenomics).</p>
|
||||||
|
<p>In exchange for that benefit stakers have to pay a self-assessed tax. At any time, another token holder who agrees to pay a higher tax can buyout lower-tax staking slots. This creates a fair and dynamic market for staking slots.</p>
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li><strong>Owner Slots:</strong> How many slots you can claim depends on the percentage of tokens you own compared to the total supply. Staking 0.001% of $KRK total supply gives 1 owner slot.</li>
|
||||||
|
<li><strong>Dynamic Value:</strong> As new tokens are minted (see supply expansion in Tokenomics), your claim automatically applies to the new total supply</li>
|
||||||
|
<li><strong>Limited Capacity:</strong> There are only 20,000 staking slots that represent 20% of all $KRK at any time.</li>
|
||||||
|
</ul>
|
||||||
|
<p class="warning">Example: Alice stakes 10,000 $KRK. The current total supply sits at 1M. As she holds 1% of the current total supply she gets 1,000 owner slots. When the supply increases to 2M, the 1% (1,000 slots) are worth now 20,000 $KRK after expansion.</p>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<br>
|
||||||
|
<pre>
|
||||||
|
*** ### ### ***
|
||||||
|
*## ++ ##*
|
||||||
|
*## ++ ##*
|
||||||
|
*## ++ ##*
|
||||||
|
*# ++ ##*
|
||||||
|
*## ++ 20% ##*
|
||||||
|
*## ++ Staking +++ ##*
|
||||||
|
*## ++ +++ ##*
|
||||||
|
*## ++ ++ ##*
|
||||||
|
*## ++ ++++ ##*
|
||||||
|
*## ++ ++++ ##*
|
||||||
|
*## ++ ++++ ##*
|
||||||
|
*## +++++ ##*
|
||||||
|
*## ##*
|
||||||
|
*## ##*
|
||||||
|
*## 80% Open Market ##*
|
||||||
|
*## ##*
|
||||||
|
*## ##*
|
||||||
|
*## ##*
|
||||||
|
*## ##*
|
||||||
|
*## ##*
|
||||||
|
*# ##*
|
||||||
|
*## ##*
|
||||||
|
*## ##*
|
||||||
|
*** ### ### ***
|
||||||
|
</pre>
|
||||||
|
<div class="concept-block">
|
||||||
|
<h2>2. Harberger Tax Mechanism</h2>
|
||||||
|
<p>To keep things fair and transparent, stakers need to pay a sel-assessed tax on their position. Inspired by the <a href="https://en.wikipedia.org/wiki/Harberger_tax" target="_blank">Harberger tax concept</a> but adapted for crypto:</p>
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li><strong>Traditional Model:</strong> Owners self-assess property value and pay tax accordingly</li>
|
||||||
|
<li><strong>KrAIken Adaptation:</strong> Stakers choose tax <em>rates</em> instead of values, creating a competitive market for positions</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<p>This system achieves three key goals:</p>
|
||||||
|
<ol>
|
||||||
|
<li><strong>Market Efficiency:</strong> Positions flow to those willing to pay highest maintenance costs (tax)</li>
|
||||||
|
<li><strong>Anti-Squating:</strong> Staking positions can get replaced anytime someone is willing to pay a higher tax, preventing permanent control</li>
|
||||||
|
<li><strong>Protocol Funding:</strong> Collected taxes finance ongoing development</li>
|
||||||
|
</ol>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="concept-block">
|
||||||
|
<h2>3. Earning Potential</h2>
|
||||||
|
<p>Staking provides leveraged exposure to $KRK's growth through two channels:</p>
|
||||||
|
|
||||||
|
<h3>A. Supply Expansion</h3>
|
||||||
|
<p>The protocol's AI liquidity manager regularly mints new tokens to:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Maintain exchange liquidity</li>
|
||||||
|
<li>Respond to market demand</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<p>Your staked percentage automatically applies to the new larger supply. Regular holders only benefit from price changes - stakers gain from both price <em>and</em> supply growth.</p>
|
||||||
|
|
||||||
|
<h3>B. Position Protection</h3>
|
||||||
|
<p>By choosing optimal tax rates, you can:</p>
|
||||||
|
<ul>
|
||||||
|
<li>Maintain your percentage through market cycles</li>
|
||||||
|
<li>Compound earnings through repeated staking</li>
|
||||||
|
<li>Outpace simple token holding returns</li>
|
||||||
|
</ul>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="concept-block">
|
||||||
|
<h2>4. Position Security</h2>
|
||||||
|
<p>While others can buyout your position at any time, crucial protections exist:</p>
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li><strong>Full Principal Return:</strong> If replaced, you receive all untaxed $KRK and potential profit immediately</li>
|
||||||
|
<li><strong>Three-Day Grace Period:</strong> New positions must pay minimum 3 days' tax upfront</li>
|
||||||
|
<li><strong>Rate Transparency:</strong> All positions display current tax rates for informed decisions</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<p class="warning">Key Insight: Losing a postion due to a buyout means lossing the benefit of <em>future</em> earnings from that stake, not existing tokens or profit.</p>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="concept-block">
|
||||||
|
<h2>5. Strategic Considerations</h2>
|
||||||
|
<p>Successful staking requires balancing:</p>
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li><strong>Tax Rate Selection:</strong> Higher rates protect positions but reduce net returns</li>
|
||||||
|
<li><strong>Market Monitoring:</strong> Track competing stakers' tax rates</li>
|
||||||
|
<li><strong>Supply Forecasts:</strong> Anticipate minting events through protocol announcements</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<p>Example Strategy: Use medium tax rates (5-15% daily) during high-growth periods to balance protection and returns</p>
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
145
web/src/views/docs/Tokenomics.vue
Normal file
145
web/src/views/docs/Tokenomics.vue
Normal file
|
|
@ -0,0 +1,145 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1>Tokenomics</h1>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
This section describes the design and distribution of the protocol's native digital token, Kraiken ($KRK). The token is issued exclusively through its Uniswap V3 liquidity pool, and its supply adjusts dynamically with network growth and demand.</p>
|
||||||
|
<p>Kraiken is a fair-launch protocol, meaning there are no allocations or unlocks for teams or investors. This ensures equal opportunities for all participants from the very beginning.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h2>Dynamic Supply</h2>
|
||||||
|
<p>There is no fixed supply for $KRK. The minting and burning of $KRK tokens are fully managed by an immutable Liquidity Manager (LM) contract, which oversees the token's supply and liquidity.</p>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<h3>Supply Expansion</h3>
|
||||||
|
<p>When buys exceed sells (rising demand), new $KRK tokens are minted to "refill" the liquidity pool (e.g., after tokens are purchased from Uniswap). This expands the total supply, which, assuming price stability, increases the protocol’s market capitalization.</p>
|
||||||
|
<pre>
|
||||||
|
▲ ┬─────────┬ = ▲
|
||||||
|
┌─────┐ [ ] ┌─────┐ ^-----^
|
||||||
|
A $ETH │ │ ▼ [ 00110 1 ] │ │ ^ ^
|
||||||
|
/ \ ───────> │ │ ┌─────┐ [ 1100 11 ] │ │ ^-----^
|
||||||
|
\/'-'\/ │ │ │ │ ─────> [ 0100 10 ] +$KRK │ │ │ + │
|
||||||
|
\_;_/ $KRK │ + │ │ - │ ─────> [ 0011110 ] ──────> │ ETH │ │ KRK │
|
||||||
|
/ \ <─────── │ ETH │ │ KRK │ [ ] │ │ │ │
|
||||||
|
│ │ │ │ ┴─────────┴ │ │ │ │
|
||||||
|
|
||||||
|
Alice buys $KRK from Uniswap Pool LM Contract mints $KRK and fills up Uniswap Pool
|
||||||
|
</pre>
|
||||||
|
<br>
|
||||||
|
<br>
|
||||||
|
|
||||||
|
<h3>Token Burn</h3>
|
||||||
|
<p>When sells outpace buys, surplus $KRK tokens from the liquidity pool are automatically burned to maintain its balance (further stabilizing the price).</p>
|
||||||
|
<pre>
|
||||||
|
▲ ┬─────────┬ ▼
|
||||||
|
┌─────┐ [ ] v-----v
|
||||||
|
A $KRK ▼ │ │ [ 00110 1 ] = v v
|
||||||
|
/ \ ───────> ┌─────┐ │ │ [ 1100 11 ] ┌─────┐ v-----v
|
||||||
|
\/'-'\/ │ │ │ │ ─────> [ 0100 10 ] -$KRK │ │ │ │
|
||||||
|
\_;_/ $ETH │ - │ │ + │ ─────> [ 0011110 ] <───── │ │ │ - │
|
||||||
|
/ \ <─────── │ ETH │ │ KRK │ [ ] │ ETH │ │ KRK │
|
||||||
|
│ │ │ │ ┴─────────┴ │ │ │ │
|
||||||
|
|
||||||
|
Alice sells $KRK to Uniswap Pool LM Contract burns $KRK and balances Uniswap Pool
|
||||||
|
|
||||||
|
</pre>
|
||||||
|
<br>
|
||||||
|
|
||||||
|
<p>These dynamic supply changes make tokenomics fair and transparent for everyone. Read further for more details.</p>
|
||||||
|
|
||||||
|
<h2>Primer to Liquidity Management</h2>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The LM maintains three key liquidity positions:
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h3>1. Floor</h3>
|
||||||
|
<p>
|
||||||
|
The Floor is a liquidity position of narrow price range with highly concentrated liquidity. The Floor position is a reserve designed to provide a guaranteed minimum buyback price for $KRK. As the protocol grows, the LM allocates more ETH to the Floor position, increasing its stability and appeal to holders. At any time between 75% and 95% of all ETH managed by the protocol are located in the Floor position.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h3>2. Anchor</h3>
|
||||||
|
<p>
|
||||||
|
The Anchor position with lower liquidity depth compared to the Floor, but covers a broader price span. It is dynamically balanced to support trading around the current price. It ensures smooth trading experiences by reducing slippage and maintaining efficient liquidity deployment.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h3>3. Discovery</h3>
|
||||||
|
<p>
|
||||||
|
The Discovery position has more dept and range than the Anchor. It allows for price exploration beyond the current range, enabling efficient trading during periods of high demand or market growth. This position grows with network activity and serves to attract more liquidity. $ETH that is accumulated in this position is regularly moved to Floor and Anchor.
|
||||||
|
</p>
|
||||||
|
<br>
|
||||||
|
<pre>
|
||||||
|
▲ ┌─────────────┐
|
||||||
|
│ │ ┌─┐ │
|
||||||
|
│ Floor │ │%│ $ETH │
|
||||||
|
│ ┌─┐ │ └─┘ │
|
||||||
|
│ │%│ │ ┌─┐ │
|
||||||
|
│ │%│ │ │+│ $KRK │
|
||||||
|
│ │%│ │ └─┘ │
|
||||||
|
│ │%│ └─────────────┘
|
||||||
|
│ │%│
|
||||||
|
│ │%│
|
||||||
|
│ │%│
|
||||||
|
L │ │%│
|
||||||
|
i │ │%│
|
||||||
|
q │ │%│ Discovery
|
||||||
|
u │ │%│
|
||||||
|
i │ │%│ ┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐
|
||||||
|
d │ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
i │ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
t │ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
y │ │%│ Anchor │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%│ │+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%│┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐│+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ │%││%││%││%││%││+││+││+││+││+││+││+││+││+││+││+││+││+││+││+│
|
||||||
|
│ └─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘
|
||||||
|
─┼─────────────────────────────────────────────────────────────────►
|
||||||
|
▲ Price
|
||||||
|
current Price
|
||||||
|
</pre>
|
||||||
|
<br>
|
||||||
|
<p>
|
||||||
|
When the price moves up, the LM rebalances by allocating more ETH to the Floor position and expanding Discovery. To support this growth, new $KRK tokens are minted. Conversely, when the price moves down, the LM shrinks the Floor and Discovery positions proportionally and burns excess tokens. For more details, see the <a href="#/docs/Liquidity-Management">Liquidity Management</a> section.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h2>Protocol Initialization</h2>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The Kraiken Protocol is initialized with a single transaction. The team deposits 1 $ETH into the Liquidity Manager, which sets the initial pool price at 1 cent per token. The Liquidity Manager bootstraps the Uniswap V3 liquidity pool and begins adjusting positions dynamically.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
From the start, the LM rebalances positions whenever the price moves more than 2% up or down, ensuring liquidity is always optimized for current market conditions.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h2>Utility</h2>
|
||||||
|
<p>
|
||||||
|
The $KRK token and its liquidity pool generates sufficient training data to continuously improve the AI agent’s performance. It kickstarts AI-driven liquidity management systems across the crypto ecosystem.
|
||||||
|
The end goal: Enable the AI to autonomously manage liquidity positions across multiple token pools on Uniswap and other DEXs. This will result in fee revenue flowing back to $KRK holders.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h2>Objective of Token Design</h2>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The Kraiken Protocol is designed to provide a fair and adaptive token ecosystem. By launching with minimal initial liquidity and no team or investor allocations, the protocol ensures equal opportunities for all participants. Minting and burning respond dynamically to market conditions, supporting growth during expansion and reducing supply (and sell pressure) during contraction.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
The Liquidity Manager provides deep liquidity and stabilizes the price. This design allows casual holders to "hold and forget," benefiting from well-managed, stable token ecosystem without needing to actively participate in liquidity management or market decisions.
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
158
web/src/views/docs/ai-agent.vue
Normal file
158
web/src/views/docs/ai-agent.vue
Normal file
|
|
@ -0,0 +1,158 @@
|
||||||
|
<template>
|
||||||
|
<div>
|
||||||
|
<h1>AI Agent</h1>
|
||||||
|
<p>KrAIken is not just another LLM that suggests on-chain actions requiring admin or owner approval. Instead, KrAIken operates independently within its own on-chain execution environment, making decisions based on open data and a self-improving algorithm. No admin or owner can veto or interfere with its actions.</p>
|
||||||
|
<p>
|
||||||
|
In the chapter <strong>Liquidity Management</strong>, we described the static behavior of the contract, outlining how the liquidity manager maintains predefined parameters for market interactions. While effective in stable conditions, this static behavior lacks adaptability to dynamic market changes. Passive liquidity providers, acting as buyers of last resort, are inherently exposed to impermanent loss, as they bear the risk of price fluctuations during their provision of liquidity. By introducing an AI agent into the system, the previously static contract is now enabled to dynamically adjust to market conditions, optimizing its liquidity management strategy in real-time.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The AI agent not only relies on its training to optimize the pool but also incorporates real-time data directly sourced from stakers. Parameters such as the percentage staked and average tax rate provide valuable sentiment indicators that would otherwise only be available through off-chain analysis, enriching the agent’s decision-making capabilities with actionable insights from on-chain activity.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h2>Inputs to the AI Agent</h2>
|
||||||
|
<p>
|
||||||
|
The AI agent interacts with its environment by consuming key input parameters that capture the state of the market, user behavior, and the system itself. These inputs are normalized and structured to enable efficient decision-making by the agent.
|
||||||
|
</p>
|
||||||
|
<ol>
|
||||||
|
<li>
|
||||||
|
<strong>Price Position Relative to Range:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><em>Description:</em> The normalized position of the current token price within a predefined range (e.g., VWAP ± volatility bounds).</li>
|
||||||
|
<li><em>Range:</em> 0 (lower bound) to 1e18 (upper bound).</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Volatility Ratio:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><em>Description:</em> The ratio of current price volatility to a baseline, such as weekly historical volatility.</li>
|
||||||
|
<li><em>Range:</em> 0 (low volatility) to 1e18 (high volatility relative to baseline).</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Volume-to-Liquidity Ratio:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><em>Description:</em> The ratio of trading volume to liquidity in the relevant range, indicating potential profitability.</li>
|
||||||
|
<li><em>Range:</em> 0 (low volume relative to liquidity) to 1e18 (high volume relative to liquidity).</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Time Since Last Call:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><em>Description:</em> The elapsed time since the last AI agent update, expressed as a fraction of a predefined target interval.</li>
|
||||||
|
<li><em>Range:</em> 0 (just called) to 1e18 (maximum target interval elapsed).</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Percentage Staked:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><em>Description:</em> The proportion of available staking slots currently utilized by users.</li>
|
||||||
|
<li><em>Range:</em> 0 (no stake) to 1e18 (maximum stake capacity utilized).</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Average Tax Rate:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><em>Description:</em> The average tax rate applied to transactions, representing the system’s cost structure.</li>
|
||||||
|
<li><em>Range:</em> 0 (0% tax) to 1e18 (4700% tax, maximum rate).</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
|
||||||
|
<h2>Outputs from the AI Agent</h2>
|
||||||
|
<p>The AI agent optimizes specific liquidity management parameters based on its input data, dynamically adjusting them to improve market responsiveness and profitability. These outputs are sent to the liquidity manager contract for execution.</p>
|
||||||
|
<ol>
|
||||||
|
<li><strong>Capital Inefficiency:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><strong>Description:</strong> Measures the deviation from optimal capital allocation, indicating potential areas for improvement in resource utilization.</li>
|
||||||
|
<li><strong>Type:</strong> <code>uint256</code></li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li><strong>Anchor Share:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><strong>Description:</strong> Represents the proportion of resources allocated to the anchor position, reflecting the agent's confidence in the current market stability.</li>
|
||||||
|
<li><strong>Type:</strong> <code>uint256</code></li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li><strong>Anchor Width:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><strong>Description:</strong> Defines the range or bandwidth of the anchor position, determining the scope of market conditions under consideration.</li>
|
||||||
|
<li><strong>Type:</strong> <code>uint24</code></li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li><strong>Discovery Depth:</strong>
|
||||||
|
<ul>
|
||||||
|
<li><strong>Description:</strong> Indicates the extent to which the agent explores new strategies or market opportunities beyond the established anchor parameters.</li>
|
||||||
|
<li><strong>Type:</strong> <code>uint256</code></li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
|
||||||
|
<h2>Agent Contract</h2>
|
||||||
|
<p>
|
||||||
|
The Agent Contract serves as the execution layer for the AI agent, interfacing directly with the liquidity manager contract. It is invoked periodically by the liquidity manager to collect input data, run the genetic algorithm, and return actionable outputs for liquidity adjustments. The Agent Contract performs the following key functions:
|
||||||
|
</p>
|
||||||
|
<ol>
|
||||||
|
<li>
|
||||||
|
<strong>Input Collection and Preprocessing:</strong>
|
||||||
|
<ul>
|
||||||
|
<li>The contract gathers all necessary data points, such as price position, volatility ratio, volume-to-liquidity ratio, percentage staked, and average tax rate.</li>
|
||||||
|
<li>These inputs are normalized and placed onto the stack of the Push3 Virtual Machine (VM) for efficient computation.</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Algorithm Loading:</strong>
|
||||||
|
<ul>
|
||||||
|
<li>The genetic algorithm, stored within the contract’s state, is loaded and also placed onto the stack of the Push3 VM.</li>
|
||||||
|
<li>This setup initializes the VM for execution.</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Execution and Output Retrieval:</strong>
|
||||||
|
<ul>
|
||||||
|
<li>The Push3 VM executes the genetic algorithm using the input parameters on the stack.</li>
|
||||||
|
<li>The execution results in a set of outputs, which may include adjustments to liquidity parameters or a non-action signal indicating no immediate changes are necessary.</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>Forwarding Outputs to Liquidity Manager:</strong>
|
||||||
|
<ul>
|
||||||
|
<li>The outputs are forwarded to the liquidity manager contract, which applies the recommended changes to reposition liquidity if necessary.</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
By introducing the Agent Contract, the previously static liquidity manager becomes capable of real-time optimization, driven by on-chain evolutionary computation. If you want to know how genetic algorithms work, or why the system is considered an agent, read this <a href="https://github.com/Sovraigns/SoLUSH-3/blob/main/vision.md">vision document</a>.
|
||||||
|
</p>
|
||||||
|
|
||||||
|
<h2>Dynamic Adaptation Through AI</h2>
|
||||||
|
<p>
|
||||||
|
The AI agent’s ability to dynamically adapt parameters allows the liquidity manager to respond to market volatility, trading volume, and user behavior in real-time. For example:
|
||||||
|
</p>
|
||||||
|
<ul>
|
||||||
|
<li>
|
||||||
|
<strong>Volatile Markets:</strong> The agent can widen Anchor and Discovery spacing to reduce exposure and maintain stability.
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>High Volume:</strong> The agent can increase liquidity in Discovery to capture more trading fees.
|
||||||
|
</li>
|
||||||
|
<li>
|
||||||
|
<strong>User Engagement:</strong> High staking utilization might lead the agent to prioritize profitability over conservatism.
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
By replacing static configurations with adaptive intelligence, the liquidity manager evolves into a dynamic system capable of optimizing for diverse and changing conditions. This integration enables a more resilient and efficient approach to decentralized liquidity management, where the AI agent collaborates with stakers to form a cybernetic system. Staking signals, such as the percentage staked and the average tax rate, provide critical real-time sentiment data that the agent uses to refine its decisions and adapt dynamically to market behaviors.
|
||||||
|
</p>
|
||||||
|
</div>
|
||||||
|
</template>
|
||||||
|
|
||||||
|
<script setup lang="ts">
|
||||||
|
import { onMounted } from 'vue';
|
||||||
|
|
||||||
|
const emit = defineEmits(["onmounted"])
|
||||||
|
onMounted(() => {
|
||||||
|
emit("onmounted")
|
||||||
|
})
|
||||||
|
</script>
|
||||||
Loading…
Add table
Add a link
Reference in a new issue