fix: extract VWAP logic and fix critical dormant whale vulnerability
- 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 commit is contained in:
parent
ab127336c8
commit
8de3865c6f
5 changed files with 745 additions and 96 deletions
15
CLAUDE.md
15
CLAUDE.md
|
|
@ -102,6 +102,21 @@ node service.js
|
|||
- Handles Uniswap V3 position management
|
||||
- Implements recentering logic for dynamic liquidity
|
||||
- Uses UniswapHelpers for price calculations
|
||||
- **VWAP Integration**: Inherits from VWAPTracker for dormant whale protection
|
||||
|
||||
### VWAPTracker.sol
|
||||
- **Critical Security Component**: Provides "eternal memory" protection against dormant whale attacks
|
||||
- **Dormant Whale Attack Pattern**:
|
||||
1. Whale buys large amounts early at cheap prices
|
||||
2. Waits for extended periods while protocol accumulates volume
|
||||
3. Attempts to sell at inflated prices when market conditions are favorable
|
||||
- **Protection Mechanism**: VWAP maintains historical price memory that persists through data compression
|
||||
- **Compression Algorithm**: Limited to maximum 1000x compression to preserve historical significance
|
||||
- **Double-Overflow Analysis**: Extensive testing shows that double-overflow scenarios requiring >1000x compression would need:
|
||||
- Single transactions >10,000 ETH (unrealistic)
|
||||
- Token prices >$4.3 billion (exceeds global wealth)
|
||||
- Therefore, 1000x compression limit provides adequate protection against realistic scenarios
|
||||
- **Floor Position Calculation**: Uses adjusted VWAP (70% base + capital inefficiency) to set floor support levels
|
||||
|
||||
### Stake.sol
|
||||
- Staking mechanism for HARB tokens
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue