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>
Replace hardcoded anchorWidth=100 with dynamic calculation that uses staking data as a decentralized oracle.
Changes:
- Add _calculateAnchorWidth() function to Optimizer.sol
- Base width 40% with adjustments based on staking percentage and average tax rate
- Staking adjustment: -20% to +20% (inverse relationship)
- Tax rate adjustment: -10% to +30% (direct relationship)
- Final range clamped to 10-80% for safety
Rationale:
- High staking % = bullish sentiment → narrower anchor (20-35%) for fee optimization
- Low staking % = bearish/uncertain → wider anchor (60-80%) for defensive positioning
- High tax rates = volatility expected → wider anchor to reduce rebalancing
- Low tax rates = stability expected → narrower anchor for fee collection
The Harberger tax mechanism acts as a prediction market where stakers' self-assessed valuations reveal market expectations.
Tests:
- Add comprehensive unit tests in test/Optimizer.t.sol
- Add mock contracts for testing (MockStake.sol, MockKraiken.sol)
- Manual verification confirms all scenarios calculate correctly
Documentation:
- Add detailed analysis of anchorWidth price ranges
- Add staking-based strategy recommendations
- Add verification of calculation logic
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Updated all production code references from 'harb' to 'kraiken'
- Changed 'Harberger tax' references to 'self-assessed tax'
- Updated function names (_getHarbToken -> _getKraikenToken)
- Modified documentation and comments to reflect new branding
- Updated token symbol from HARB to KRAIKEN in tests
- Maintained backward compatibility with test variable names
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
The discovery position was incorrectly calculating ETH amount instead
of KRAIKEN amount when determining how much to subtract from outstanding
supply. This caused the floor position to be placed at extreme ticks
(141k+) instead of bordering the anchor position.
When token0isWeth=true:
- Before: discoveryAmount = getAmount0 (ETH amount)
- After: discoveryAmount = getAmount1 (KRAIKEN amount)
This ensures the outstanding supply calculation properly excludes all
KRAIKEN tokens locked in liquidity positions.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
The VWAP tracker stores price² (squared price) in X96 format, but the floor position
calculation was using it as regular price. This caused two issues:
1. ETH scarcity calculation overestimated required ETH by using price² instead of price
2. ETH abundance floor placement was incorrect due to passing price² to _tickAtPriceRatio
Fixed by taking sqrt(vwapX96) before using it in both ETH scarcity and abundance cases.
Also updated BullMarketOptimizer documentation to be more accurate.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Implement dynamic discovery depth based on anchor position share
- Add configurable discovery_max_multiple (1.5-4x) for flexible adjustment
- Update BullMarketOptimizer with new depth calculation logic
- Fix scenario visualizer floor position visibility
- Add comprehensive tests for discovery depth behavior
The discovery position now dynamically adjusts its depth based on the anchor
position's share of total liquidity, allowing for more effective price discovery
while maintaining protection against manipulation.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Remove two redundant VWAP tests from LiquidityManager.t.sol that provided no unique coverage beyond comprehensive testing in VWAPTracker.t.sol
- Fix testFuzzRobustness fuzzing test failure caused by "SPL" (Square root Price Limit) errors in extreme price conditions
- Improve price limit calculation in UniswapTestBase.sol with better boundary checking and safety margins
- All tests now pass consistently (97/97 tests passing across 11 test suites)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Renamed core contract from Harberg.sol to Kraiken.sol
- Updated token symbol from HARB to KRK
- Renamed TypeScript library from harb-lib to kraiken-lib
- Updated all contract imports and references across smart contracts
- Modified subgraph schema and source files for new naming
- Updated transaction bot dependencies and service references
- Fixed test files to use new contract and token names
- Updated documentation in CLAUDE.md and README.md
- Regenerated subgraph types and ABI files
- Added new deployment script (DeployScript2.sol)
All components compile successfully and tests pass.
Smart contracts: ✅ Compilation and tests pass
TypeScript library: ✅ Package renamed and configured
Subgraph: ✅ Code generation and build successful
Transaction bot: ✅ Dependencies updated
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Extract VWAP tracking logic into reusable VWAPTracker contract
- Fix critical compression bug that erased historical price memory
- Replace dangerous 10^35x compression with limited 1000x max compression
- Add comprehensive dormant whale protection testing
- Preserve "eternal memory" to prevent manipulation by patient whales
- Add double-overflow analysis showing 1000x limit is mathematically safe
- Maintain backwards compatibility with existing LiquidityManager
Security Impact:
- Prevents dormant whale attacks where traders accumulate early then exploit
compressed historical data to extract value at inflated prices
- VWAP now maintains historical significance even after compression
- Floor position calculations remain anchored to true price history
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
this pull request:
- creates a unit test that can take any scenario file (default: `out/scenario.json` and play it back on the deployment
- during the playback a debug trace generated in `timeSeries.csv`
- extracts the sentimenter into a separate upgradeable contract
Co-authored-by: JulesCrown <admin@noip.localhost>
Co-authored-by: giteadmin <gite@admin.com>
Reviewed-on: http://gitea.loseyourip.com:4000/dark-meme-society/harb/pulls/11
