feat: OptimizerV3 with direct 2D staking-to-LP parameter mapping
Core protocol changes for launch readiness: - OptimizerV3: binary bear/bull mapping from (staking%, avgTax) — avoids exploitable AW 30-90 kill zone. Bear: AS=30%, AW=100, CI=0, DD=0.3e18. Bull: AS=100%, AW=20, CI=0, DD=1e18. UUPS upgradeable with __gap[48]. - Directional VWAP: only records prices on ETH inflow (buys), preventing sell-side dilution of price memory - Floor formula: unified max(scarcity, mirror, clamp) — VWAP mirror uses distance from adjusted VWAP as floor distance, no branching - PriceOracle (M-1 fix): correct fallback TWAP divisor (60000s, not 300s) - Access control (M-2 fix): deployer-only guard on one-time setters - Recenter rate limit (M-3 fix): 60-second cooldown for open recenters - Safe fallback params: recenter() optimizer-failure defaults changed from exploitable CI=50%/AW=50 to safe bear-mode CI=0/AW=100 - Recentered event for monitoring and indexing - VERSION bump to 2, kraiken-lib COMPATIBLE_CONTRACT_VERSIONS updated Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
openhands
parent
21857ae8ca
commit
85350caf52
38 changed files with 3793 additions and 205 deletions
|
|
@ -125,78 +125,81 @@
|
|||
</li>
|
||||
</ol>
|
||||
|
||||
<h2>Agent Contract</h2>
|
||||
<h2>Optimizer 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:
|
||||
The Optimizer Contract (OptimizerV3) serves as the decision layer for the AI agent, interfacing directly with the liquidity manager
|
||||
contract. It is queried during every rebalance to determine how liquidity should be positioned. The Optimizer uses a direct 2D mapping
|
||||
from on-chain staking sentiment to binary bear/bull configurations:
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
<strong>Input Collection and Preprocessing:</strong>
|
||||
<strong>Sentiment Signal Collection:</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.
|
||||
The contract reads two key signals directly from the Harberger staking system: the percentage of staking slots currently
|
||||
utilized, and the average tax rate across all active stakers.
|
||||
</li>
|
||||
<li>These inputs are normalized and placed onto the stack of the Push3 Virtual Machine (VM) for efficient computation.</li>
|
||||
<li>These signals together form a real-time sentiment indicator that captures community conviction.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>Algorithm Loading:</strong>
|
||||
<strong>Bear/Bull Classification:</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>
|
||||
<li>When staking utilization is at or below 91%, the optimizer always selects the defensive <strong>bear</strong> configuration. This represents the vast majority (~94%) of the staking state space.</li>
|
||||
<li>Bull mode requires both very high staking (>91%) <em>and</em> low average tax rates — a signal of genuine community euphoria rather than speculative over-bidding.</li>
|
||||
<li>Any decline in staking instantly snaps the system back to bear mode, providing rapid downside protection.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>Execution and Output Retrieval:</strong>
|
||||
<strong>Binary Parameter Output:</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>
|
||||
<li><strong>Bear mode:</strong> Conservative anchor (30% of ETH, wide 100-tick range), minimal discovery. Maximizes floor protection.</li>
|
||||
<li><strong>Bull mode:</strong> Aggressive anchor (100% of ETH, narrow 20-tick range), full discovery depth. Maximizes fee capture during euphoria.</li>
|
||||
<li>The binary step avoids intermediate parameter ranges that were found to be exploitable during extensive fuzzing and adversarial testing.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>Forwarding Outputs to Liquidity Manager:</strong>
|
||||
<strong>Forwarding 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.
|
||||
The outputs are forwarded to the liquidity manager contract, which applies the recommended changes to reposition liquidity
|
||||
during the next rebalance.
|
||||
</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>.
|
||||
The Optimizer is upgradeable via UUPS proxy pattern, allowing the sentiment-to-parameter mapping to evolve as the protocol gathers
|
||||
more real-world data. However, the core Liquidity Manager remains immutable — the Optimizer can only influence <em>how</em>
|
||||
liquidity is positioned, never the fundamental safety guarantees of the protocol.
|
||||
</p>
|
||||
|
||||
<h2>Dynamic Adaptation Through AI</h2>
|
||||
<h2>Dynamic Adaptation Through Sentiment</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:
|
||||
The Optimizer's ability to read staking sentiment and adapt parameters allows the liquidity manager to respond to community conviction
|
||||
in real-time. The system naturally traces a cycle through three phases:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
<strong>Volatile Markets:</strong> The agent can widen Anchor and Discovery spacing to reduce exposure and maintain stability.
|
||||
<strong>Bear Mode (Default):</strong> With staking below 91%, the Optimizer maintains a wide, conservative anchor and minimal
|
||||
discovery. The Floor is maximally protected, and the protocol prioritizes solvency over aggressive fee capture.
|
||||
</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.
|
||||
<strong>Bull Transition:</strong> As staking fills past 91% with low tax rates — a signal of genuine community euphoria
|
||||
— the Optimizer switches to an aggressive configuration. The narrow anchor concentrates liquidity near the current price,
|
||||
maximizing trading fee revenue during periods of high activity.
|
||||
</li>
|
||||
<li>
|
||||
<strong>Snap-Back Protection:</strong> Any decline in staking instantly reverts to bear mode. The cubic sensitivity ensures that
|
||||
even a small 4-6% drop in staking triggers the transition, providing rapid downside protection.
|
||||
</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.
|
||||
By replacing static configurations with sentiment-driven adaptation, the liquidity manager evolves into a dynamic system that responds
|
||||
to community behavior. Staking signals provide critical real-time sentiment data, creating a cybernetic feedback loop: stakers
|
||||
influence liquidity positioning through their commitment, and the resulting market dynamics in turn affect staking incentives.
|
||||
</p>
|
||||
</div>
|
||||
</template>
|
||||
|
|
|
|||
|
|
@ -34,11 +34,12 @@
|
|||
<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>
|
||||
<p>You can stake your $KRK tokens at <a href="https://kraiken.org">kraiken.org</a> by connecting your wallet and selecting a tax rate.</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.
|
||||
The core contracts (Liquidity Manager, Token, Staking) are permanently immutable after deployment with no admin controls. The
|
||||
Optimizer, which determines liquidity positioning parameters based on staking sentiment, is upgradeable via a UUPS proxy to allow the
|
||||
sentiment-to-parameter mapping to evolve as the protocol gathers real-world data.
|
||||
</p>
|
||||
<h3>Are there team allocations or unlocks?</h3>
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -10,16 +10,14 @@
|
|||
<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
|
||||
early investors, protocol teams, fee distributions, multisig holders, NFT owners etc. The KrAIken 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.
|
||||
In the traditional model, the value of the asset is constantly changeable to reflect the current market value and dynamics. In
|
||||
KrAIken, 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>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,28 +2,28 @@
|
|||
<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
|
||||
In traditional protocol designs, holders benefit from a protocol's success only indirectly through an increase in token price. KrAIken
|
||||
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.
|
||||
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>
|
||||
<h2 id="second">Buy $KRK</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.
|
||||
$KRK tokens and the KrAIken Protocol are deployed on Base, an Ethereum Layer 2. $KRK can be bought on
|
||||
<a href="https://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
|
||||
By holding $KRK, 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>
|
||||
<h2 id="fourth">Sell $KRK</h2>
|
||||
<p>$KRK can be sold anytime on <a href="https://uniswap.org">Uniswap</a></p>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
|
|
|
|||
|
|
@ -64,21 +64,28 @@
|
|||
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
|
||||
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>
|
||||
|
||||
<p>
|
||||
The VWAP also serves as a <strong>dormant whale defense</strong>. Because the VWAP only records prices during buying activity (ETH
|
||||
inflow), an attacker who sells heavily cannot dilute the VWAP downward. The Floor uses the VWAP as a mirror — during sell
|
||||
pressure, the growing distance between the current price and the VWAP automatically pushes the Floor further away, making it
|
||||
progressively harder to drain. This "price memory" mechanism provides passive protection against coordinated sell attacks without
|
||||
requiring any external intervention.
|
||||
</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.
|
||||
market price, ensuring its relevance to active trading. The size and width of the Anchor adapt based on the market regime determined by
|
||||
the Optimizer, which reads Harberger staking sentiment to classify conditions as <strong>bear</strong> or <strong>bull</strong>. In
|
||||
bear mode, the Anchor is conservative (30% of ETH, wide range) to minimize exposure. In bull mode, triggered only when staking
|
||||
signals indicate genuine community euphoria, the Anchor becomes aggressive (up to 100% of ETH, narrow range) to maximize fee capture.
|
||||
This adaptive strategy puts more capital at risk during confirmed uptrends while maintaining a defensive posture by default. For more
|
||||
on staking signals, visit the "Staking" chapter, and for details about the Optimizer, see the "AI-Agent" chapter.
|
||||
</p>
|
||||
|
||||
<h2>Discovery Position</h2>
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@
|
|||
<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
|
||||
To keep things fair and transparent, stakers need to pay a self-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>
|
||||
|
||||
|
|
@ -125,7 +125,7 @@
|
|||
</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
|
||||
Key Insight: Losing a position due to a buyout means losing the benefit of <em>future</em> earnings from that stake, not existing
|
||||
tokens or profit.
|
||||
</p>
|
||||
</div>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue