No description
d581b8394b
PROBLEM: Recenter operations were burning ~137,866 KRK tokens instead of minting them, causing severe deflation when inflation should occur. This was due to the liquidity manager burning ALL collected tokens from old positions and then minting tokens for new positions separately, causing asymmetric supply adjustments to the staking pool. ROOT CAUSE: During recenter(): 1. _scrapePositions() collected tokens from old positions and immediately burned them ALL (+ proportional staking pool adjustment) 2. _setPositions() minted tokens for new positions (+ proportional staking pool adjustment) 3. The burn and mint operations used DIFFERENT totalSupply values in their proportion calculations, causing imbalanced adjustments 4. When old positions had more tokens than new positions needed, the net result was deflation WHY THIS HAPPENED: When KRK price increases (users buying), the same liquidity depth requires fewer KRK tokens. The old code would: - Burn 120k KRK from old positions (+ 30k from staking pool) - Mint 10k KRK for new positions (+ 2.5k to staking pool) - Net: -137.5k KRK total supply (WRONG!) FIX: 1. Modified uniswapV3MintCallback() to use existing KRK balance first before minting new tokens 2. Removed burn() from _scrapePositions() - keep collected tokens 3. Removed burn() from end of recenter() - don't burn "excess" 4. Tokens held by LiquidityManager are already excluded from outstandingSupply(), so they don't affect staking calculations RESULT: Now during recenter, only the NET difference is minted or used: - Collect old positions into LiquidityManager balance - Use that balance for new positions - Only mint additional tokens if more are needed - Keep any unused balance for future recenters - No more asymmetric burn/mint causing supply corruption VERIFICATION: - All 107 existing tests pass - Added 2 new regression tests in test/SupplyCorruption.t.sol - testRecenterDoesNotCorruptSupply: verifies single recenter preserves supply - testMultipleRecentersPreserveSupply: verifies no accumulation over time Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> |
||
|---|---|---|
| .husky | ||
| .woodpecker | ||
| containers | ||
| docker | ||
| docs | ||
| kraiken-lib | ||
| landing | ||
| onchain | ||
| scripts | ||
| services | ||
| tests | ||
| web-app | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| docker-compose.yml | ||
| HARBERG.md | ||
| package-lock.json | ||
| package.json | ||
| playwright.config.ts | ||
| README.md | ||
| TECHNICAL_APPENDIX.md | ||
| VERSION_VALIDATION.md | ||
$HRB is a gig to become successful in DeFi. It is a protocol that implements the fairest ponzi in the world.
This repository structures our approach and manages our collaboration to achieve this goal.
Project Milestones
The fairest ponzi in the world will be launched in 3 stages, each representing a more advanced version of the previous one.
- Harberg - a staking market and an speculative laverage platform.
- KrAIken - Harberg, but token issuance is governed by an automated liquidity manager.
- SoverAIgns - KrAIKen, but the liquidity manager is augmented by AI and deliveres outlandish performance
Project Values and Organization
- the core value and mantra of the project is: ship, ship, 🚢
- delivery is valued highest and goes over quality or communication
- if you see work, do it. most likely every-one but you will lose interest in the project, and you will deliver it by yourself. work this way, take responsibility for everything. document everything methodically in this repository, use .md files, commits, issues(feature request, support issue), and pull requests. if other people still follow this repository collaboration will emerge, and duplication of work will be avoided automatically.
- no structured communication outside of this repository is relevant for the success, nor will it be rewarded.
open questions
- multisig? keyholders?
- payout, shares?
Revenue Sources
- the tax paid by the stakers will be forwarded to the multisig
- the liquidity manager contract will collect all liquidity fees and forward them to the multisig
- at launch of each stage of the project the keyholders will invest a share of the multisig holdings and coordinate to sell at a favorable time. all profits from all sales are the multisigs profits.
Timeline
it would be great if we can launch stage 1 or even 2 for DevCon.
Kick-off Call Harberg
Agenda