9.5 KiB
9.5 KiB
📁 MEV Bot File Reorganization Plan
Current Problem: Chaotic File Structure
The current arbitrum package has scattered functionality with confusing prefixes:
enhanced_parser.go,enhanced_example.go,enhanced_types.gooptimized_*.gofiles with duplicated functionality- Broken files moved to
.brokenextensions - Type conflicts between packages
- Missing interfaces and poor separation of concerns
🎯 PROPOSED NEW STRUCTURE
Phase 1: Core Package Reorganization
pkg/arbitrum/
├── core/
│ ├── types.go # Core types (Protocol, PoolInfo, etc.)
│ ├── interfaces.go # All interfaces in one place
│ └── constants.go # Protocol constants and addresses
├── parsing/
│ ├── parser.go # Main parser interface
│ ├── dex_parser.go # DEX-specific parsing logic
│ ├── event_parser.go # Event parsing (merge enhanced_parser)
│ └── transaction_parser.go # Transaction parsing
├── discovery/
│ ├── market_discovery.go # Market discovery (existing)
│ ├── pool_discovery.go # Pool discovery logic
│ └── factory_discovery.go # Factory contract discovery
├── monitoring/
│ ├── event_monitor.go # Event monitoring (existing)
│ ├── sequencer_monitor.go # Sequencer-specific monitoring
│ └── metrics.go # Monitoring metrics
├── pipeline/
│ ├── swap_pipeline.go # Swap processing pipeline (existing)
│ ├── mev_pipeline.go # MEV opportunity pipeline
│ └── arbitrage_pipeline.go # Arbitrage detection pipeline
├── cache/
│ ├── pool_cache.go # Pool caching (existing)
│ ├── token_cache.go # Token metadata caching
│ └── price_cache.go # Price data caching
└── integration/
├── examples.go # Integration examples (merge enhanced_example)
├── guides.go # Integration guides
└── testing.go # Integration testing helpers
Phase 2: Merge Enhanced/Optimized Functionality
2.1 Enhanced Parser → parsing/event_parser.go
- Merge
enhanced_parser.gofunctionality intoparsing/event_parser.go - Keep advanced features: comprehensive DEX support, price enrichment
- Maintain backwards compatibility with existing parser interface
2.2 Protocol Parsers → parsing/dex_parser.go
- Consolidate
protocol_parsers.gointoparsing/dex_parser.go - Factory pattern for different DEX protocols
- Clean interface for adding new protocols
2.3 Type Definitions → core/types.go
- Single source of truth for all types
- Remove duplicate definitions from
enhanced_types.go - Proper package organization for types
2.4 Integration Examples → integration/examples.go
- Merge
enhanced_example.goandintegration_guide.go - Comprehensive examples for different use cases
- Clear documentation and best practices
Phase 3: Interface Standardization
3.1 Create core/interfaces.go
package core
// ParserInterface - unified parser interface
type ParserInterface interface {
ParseTransaction(tx *types.Transaction) (*ParseResult, error)
ParseEvent(log types.Log) (*EventResult, error)
GetSupportedProtocols() []Protocol
}
// DiscoveryInterface - market discovery interface
type DiscoveryInterface interface {
DiscoverPools(tokenA, tokenB common.Address) ([]*PoolInfo, error)
GetPoolInfo(address common.Address) (*PoolInfo, error)
UpdatePoolState(update *PoolStateUpdate) error
}
// CacheInterface - caching interface
type CacheInterface interface {
Get(key string) (interface{}, bool)
Set(key string, value interface{}, ttl time.Duration)
Invalidate(key string)
}
3.2 Backwards Compatibility
- Keep existing public APIs working
- Add deprecation warnings for old interfaces
- Gradual migration path for consumers
Phase 4: File Naming Convention
4.1 Clear Naming Rules
✅ GOOD:
- parser.go (main functionality)
- event_monitor.go (specific purpose)
- pool_cache.go (clear responsibility)
❌ BAD:
- enhanced_parser.go (ambiguous prefix)
- optimized_scanner.go (unclear what's optimized)
- new_types.go (temporary-sounding name)
4.2 Package-Level Organization
- Each directory has a clear, single responsibility
- Interfaces defined at package level
- Implementation details internal to package
🔧 IMPLEMENTATION STRATEGY
Step 1: Create New Structure (Non-Breaking)
# Create new directory structure
mkdir -p pkg/arbitrum/{core,parsing,discovery,monitoring,pipeline,cache,integration}
# Move and rename files systematically
mv pkg/arbitrum/event_monitor.go pkg/arbitrum/monitoring/
mv pkg/arbitrum/pool_cache.go pkg/arbitrum/cache/
mv pkg/arbitrum/swap_pipeline.go pkg/arbitrum/pipeline/
Step 2: Merge Enhanced Functionality
# Merge enhanced files into appropriate locations
# enhanced_parser.go → parsing/event_parser.go
# enhanced_example.go → integration/examples.go
# enhanced_types.go → core/types.go (merge with existing)
Step 3: Fix Imports and Dependencies
# Update all import statements
# Fix interface implementations
# Resolve type conflicts
Step 4: Update Consumers
# Update pkg/monitor/ to use new structure
# Update pkg/market/ to use new interfaces
# Fix any external dependencies
📋 SPECIFIC MERGE OPERATIONS
Enhanced Parser Merge
// FROM: enhanced_parser.go (broken)
// TO: parsing/event_parser.go
type EventParser struct {
// Merge: EnhancedDEXParser functionality
client *rpc.Client
logger *logger.Logger
oracle *oracle.PriceOracle
protocolParsers map[core.Protocol]ParserInterface
// Keep: Enhanced features
enrichmentService *EventEnrichmentService
tokenMetadata *TokenMetadataService
metrics *core.ParserMetrics
}
Protocol Parsers Merge
// FROM: protocol_parsers.go
// TO: parsing/dex_parser.go
type DEXParserFactory struct {
client *rpc.Client
logger *logger.Logger
}
func (f *DEXParserFactory) CreateParser(protocol core.Protocol) core.ParserInterface {
// Factory method for all supported DEX protocols
}
Types Consolidation
// FROM: enhanced_types.go, existing types
// TO: core/types.go
package core
// Single source of truth for all types
type Protocol string
type PoolInfo struct { /* unified definition */ }
type ParseResult struct { /* unified definition */ }
// etc.
🎯 BENEFITS OF REORGANIZATION
1. Developer Experience
- Clear file discovery: Find functionality by logical grouping
- Reduced confusion: No more
enhanced_vsoptimized_guessing - Better IDE support: Proper package structure for navigation
2. Maintainability
- Single responsibility: Each file has one clear purpose
- Easier testing: Package-level testing strategies
- Simpler debugging: Clear call paths through organized structure
3. Backwards Compatibility
- Gradual migration: Old imports still work during transition
- Deprecation warnings: Clear upgrade path for consumers
- Version compatibility: Maintain API contracts
4. Performance
- Reduced import cycles: Clear dependency hierarchy
- Better compilation: Smaller packages compile faster
- Optimized loading: Import only what you need
🚀 IMPLEMENTATION TIMELINE
Phase 1: Structure Setup (1-2 hours)
- Create new directory structure
- Move existing files to appropriate locations
- Basic import fixes
Phase 2: Enhanced Merging (2-3 hours)
- Merge enhanced_parser.go into parsing/event_parser.go
- Consolidate types into core/types.go
- Merge examples into integration/examples.go
Phase 3: Interface Cleanup (1-2 hours)
- Create unified interfaces in core/interfaces.go
- Fix all import statements
- Resolve remaining type conflicts
Phase 4: Testing & Validation (1 hour)
- Ensure all packages compile
- Run existing tests
- Validate functionality preservation
⚠️ CRITICAL SUCCESS FACTORS
1. Preserve Functionality
- All existing features must continue working
- No performance regressions
- Maintain API compatibility
2. Fix Build Issues First
- Complete current build error fixes
- Establish baseline working state
- Then reorganize incrementally
3. Documentation Updates
- Update CLAUDE.md with new structure
- Create migration guide for developers
- Update import examples
🎯 FINAL STRUCTURE PREVIEW
pkg/arbitrum/
├── arbitrum.go # Main package interface (backwards compat)
├── core/ # Core types and interfaces
├── parsing/ # All parsing functionality
├── discovery/ # Market and pool discovery
├── monitoring/ # Event and sequencer monitoring
├── pipeline/ # Processing pipelines
├── cache/ # Caching implementations
└── integration/ # Examples and guides
This organization provides:
- ✅ Clear separation of concerns
- ✅ Backwards compatibility
- ✅ Easy feature discovery
- ✅ Better testing structure
- ✅ Reduced type conflicts
- ✅ Simplified maintenance
Ready to implement? This reorganization will transform the chaotic file structure into a clean, maintainable architecture while preserving all functionality and fixing the current build issues.