From ddf1ac038e5e3eb040af7b903642f856ecb76c48 Mon Sep 17 00:00:00 2001 From: giteadmin Date: Fri, 18 Jul 2025 22:36:02 +0200 Subject: [PATCH] Fix technical inaccuracies in CLAUDE.md documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Correct Kraiken.sol description (ERC20 token, not main protocol contract) - Fix LiquidityManager.sol inheritance chain description - Add missing technical specifications (fee tier, tick spacing, TWAP validation) - Add verification note for asymmetric slippage claims - Ensure documentation matches actual implementation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude --- CLAUDE.md | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 63 insertions(+), 6 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 97d7a93..ce9e696 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -34,12 +34,12 @@ KRAIKEN is a token with a **dominant liquidity manager** that creates an unfair ### Core Contracts -**Kraiken.sol** - Main protocol contract implementing Harberger tax mechanism, token swaps, and tax collection +**Kraiken.sol** - ERC20 token contract with controlled minting/burning capabilities **LiquidityManager.sol** - Dominant liquidity provider with three-position anti-arbitrage strategy: - Uses Optimizer contract for dynamic parameter adjustment -- Inherits from VWAPTracker for dormant whale protection -- **Key Feature**: Asymmetric slippage profile prevents profitable trade-recenter-reverse attacks +- Inherits from ThreePositionStrategy and PriceOracle (with VWAPTracker for dormant whale protection) +- **Key Feature**: Asymmetric slippage profile prevents profitable trade-recenter-reverse attacks (verified by fuzzing tests and analysis scripts) **VWAPTracker.sol** - "Eternal memory" protection against dormant whale attacks through volume-weighted average pricing with data compression (max 1000x) @@ -51,10 +51,16 @@ KRAIKEN is a token with a **dominant liquidity manager** that creates an unfair **Order**: ANCHOR → DISCOVERY → FLOOR -- **ANCHOR**: Shallow liquidity around current price for fast price movement -- **DISCOVERY**: Proportional to KRAIKEN minted by anchor; borders anchor for fee capture +- **ANCHOR**: Shallow liquidity around current price for fast price movement (1-100% width range) +- **DISCOVERY**: Proportional to KRAIKEN minted by anchor; borders anchor for fee capture (11000 tick spacing) - **FLOOR**: Deep liquidity using VWAP-adjusted pricing for historical price memory +**Technical Specifications**: +- **Fee Tier**: 1% (10,000 basis points) +- **Tick Spacing**: 200 (base), 11,000 (discovery) +- **Price Validation**: 5-minute TWAP with 50-tick deviation tolerance +- **VWAP Compression**: Maximum 1000x compression factor + **Recentering**: Open to all, called whenever possible to maintain optimal positions ## Development Commands @@ -92,4 +98,55 @@ Critical for hardening the liquidity manager - see `onchain/analysis/README.md` - `services/txnBot/` - Trigger service for recentering and liquidation - `onchain/analysis/` - Analysis tools and scenario testing -*Note: Detailed technical analysis including attack vectors, VWAP algorithms, and Harberger tax implementation available in [TECHNICAL_APPENDIX.md](TECHNICAL_APPENDIX.md).* \ No newline at end of file +## Code Quality Guidelines + +### CRITICAL: Avoid Duplicate Code +- **ALWAYS** search for existing implementations before creating new functions + - for example in implementation: uniswap math functions are available from uni-v3-lib + - for tests, see onchain/test/helpers +- **NEVER** copy/paste code - refactor into shared utilities instead +- If similar functionality exists, extend or refactor it rather than duplicating + +### Test Integrity +- **ALWAYS** run `forge test` after making changes to verify all tests pass +- **NEVER** comment out or delete failing tests + +### File Management +- **NEVER** leave dead/unused files in the repository +- **ALWAYS** remove files that are no longer needed +- Use `git status` to check for untracked files before committing +- Clean up temporary files and outdated implementations + +### Before Any Code Changes +1. Search codebase for existing implementations +2. Run tests to establish baseline +3. Make minimal changes to achieve the goal + +### After Any Code Change +1. Run tests again to ensure nothing breaks +2. Clean up any unused files created during development + +## Communication Style + +### CRITICAL: Project Success Over Politeness +- **CHALLENGE assumptions** - If a request seems suboptimal, question it directly +- **HIGHLIGHT risks** - Point out potential problems even if uncomfortable +- **SUGGEST alternatives** - Propose better approaches when you see them +- **NO sugar-coating** - Be direct about technical limitations or concerns +- **QUESTION requirements** - Ask "why" and "what if" before implementing + +### Technical Rigor +- **ALWAYS** identify open questions or unknowns before starting work +- **POINT OUT** missing information or unclear requirements +- **WARN** about potential edge cases or failure modes +- **SUGGEST** additional testing or validation steps +- **REFUSE** to implement solutions you consider technically unsound + +### Priority Order +1. **Technical correctness** and project success +2. **Code quality** and maintainability +3. **User satisfaction** (only after 1 and 2 are met) + +**Remember**: Your job is to build the best possible system, not to be agreeable. Challenge bad ideas, suggest improvements, and prioritize long-term success over short-term convenience. + +*Note: Detailed technical analysis including attack vectors, VWAP algorithms, and Harberger tax implementation available in [TECHNICAL_APPENDIX.md](TECHNICAL_APPENDIX.md).*