803de231ba
Restructured project for V2 refactor: **Structure Changes:** - Moved all V1 code to orig/ folder (preserved with git mv) - Created docs/planning/ directory - Added orig/README_V1.md explaining V1 preservation **Planning Documents:** - 00_V2_MASTER_PLAN.md: Complete architecture overview - Executive summary of critical V1 issues - High-level component architecture diagrams - 5-phase implementation roadmap - Success metrics and risk mitigation - 07_TASK_BREAKDOWN.md: Atomic task breakdown - 99+ hours of detailed tasks - Every task < 2 hours (atomic) - Clear dependencies and success criteria - Organized by implementation phase **V2 Key Improvements:** - Per-exchange parsers (factory pattern) - Multi-layer strict validation - Multi-index pool cache - Background validation pipeline - Comprehensive observability **Critical Issues Addressed:** - Zero address tokens (strict validation + cache enrichment) - Parsing accuracy (protocol-specific parsers) - No audit trail (background validation channel) - Inefficient lookups (multi-index cache) - Stats disconnection (event-driven metrics) Next Steps: 1. Review planning documents 2. Begin Phase 1: Foundation (P1-001 through P1-010) 3. Implement parsers in Phase 2 4. Build cache system in Phase 3 5. Add validation pipeline in Phase 4 6. Migrate and test in Phase 5 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
104 lines
3.0 KiB
Markdown
104 lines
3.0 KiB
Markdown
# MEV Bot V1 - Original Codebase
|
|
|
|
This directory contains the original V1 implementation of the MEV bot that was moved here on 2025-11-10 as part of the V2 refactor planning.
|
|
|
|
## Why Was This Moved?
|
|
|
|
V1 has been preserved here to:
|
|
1. Maintain reference implementation during V2 development
|
|
2. Allow comparison testing between V1 and V2
|
|
3. Preserve git history and working code
|
|
4. Enable easy rollback if needed
|
|
5. Provide basis for migration validation
|
|
|
|
## V1 Architecture Overview
|
|
|
|
V1 uses a monolithic parser approach with the following structure:
|
|
|
|
```
|
|
orig/
|
|
├── cmd/ # Main applications
|
|
│ └── mev-bot/ # MEV bot entry point
|
|
├── pkg/ # Library code
|
|
│ ├── events/ # Event parsing (monolithic)
|
|
│ ├── monitor/ # Arbitrum sequencer monitoring
|
|
│ ├── scanner/ # Arbitrage scanning
|
|
│ ├── arbitrage/ # Arbitrage detection
|
|
│ ├── market/ # Market data management
|
|
│ ├── pools/ # Pool discovery
|
|
│ └── arbitrum/ # Arbitrum-specific code
|
|
├── internal/ # Private code
|
|
└── config/ # Configuration files
|
|
```
|
|
|
|
## Known Issues in V1
|
|
|
|
### Critical Issues
|
|
1. **Zero Address Tokens**: Parser returns zero addresses when transaction data unavailable
|
|
2. **Parsing Accuracy**: Monolithic parser misses protocol-specific edge cases
|
|
3. **No Data Validation**: Events with invalid data reach the scanner
|
|
4. **Stats Disconnection**: Detected opportunities not reflected in stats
|
|
|
|
### Performance Issues
|
|
1. Single-index pool cache (by address only)
|
|
2. Inefficient arbitrage path discovery
|
|
3. No pool liquidity ranking
|
|
|
|
### Observability Issues
|
|
1. No validation audit trail
|
|
2. Limited discrepancy logging
|
|
3. Incomplete metrics coverage
|
|
|
|
## V2 Improvements
|
|
|
|
V2 addresses all these issues with:
|
|
- Per-exchange parsers (UniswapV2, UniswapV3, SushiSwap, Camelot, Curve)
|
|
- Strict multi-layer validation
|
|
- Multi-index pool cache (address, token pair, protocol, liquidity)
|
|
- Background validation pipeline with audit trails
|
|
- Comprehensive metrics and observability
|
|
|
|
See `/docs/planning/` for detailed V2 architecture and implementation plan.
|
|
|
|
## Building and Running V1
|
|
|
|
If you need to run V1 for comparison or testing:
|
|
|
|
```bash
|
|
# From this directory
|
|
cd /docker/mev-beta/orig
|
|
|
|
# Build
|
|
go build -o ../bin/mev-bot-v1 ./cmd/mev-bot/main.go
|
|
|
|
# Run
|
|
../bin/mev-bot-v1 start
|
|
```
|
|
|
|
## Important Notes
|
|
|
|
- **DO NOT** make changes to V1 code unless absolutely necessary
|
|
- V1 is frozen for reference
|
|
- All new development happens in V2 structure
|
|
- V1 will be used for comparison testing during migration
|
|
- After successful V2 migration, V1 can be archived or removed
|
|
|
|
## Last V1 Commit
|
|
|
|
Branch: `master-dev`
|
|
Date: 2025-11-10
|
|
Commit: (see git log)
|
|
|
|
## Migration Status
|
|
|
|
- [x] V1 moved to orig/
|
|
- [ ] V2 planning complete
|
|
- [ ] V2 implementation started
|
|
- [ ] V2 comparison testing
|
|
- [ ] V2 production deployment
|
|
- [ ] V1 decommissioned
|
|
|
|
---
|
|
|
|
For V2 development, see `/docs/planning/00_V2_MASTER_PLAN.md`
|