refactor: move all remaining files to orig/ directory

Completed clean root directory structure:
- Root now contains only: .git, .env, docs/, orig/
- Moved all remaining files and directories to orig/:
  - Config files (.claude, .dockerignore, .drone.yml, etc.)
  - All .env variants (except active .env)
  - Git config (.gitconfig, .github, .gitignore, etc.)
  - Tool configs (.golangci.yml, .revive.toml, etc.)
  - Documentation (*.md files, @prompts)
  - Build files (Dockerfiles, Makefile, go.mod, go.sum)
  - Docker compose files
  - All source directories (scripts, tests, tools, etc.)
  - Runtime directories (logs, monitoring, reports)
  - Dependency files (node_modules, lib, cache)
  - Special files (--delete)

- Removed empty runtime directories (bin/, data/)

V2 structure is now clean:
- docs/planning/ - V2 planning documents
- orig/ - Complete V1 codebase preserved
- .env - Active environment config (not in git)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

orig/.qwen/commands/audit-go-mev.toml

@@ -0,0 +1,88 @@
+# audit-go-mev.toml
+
+description = "Run a comprehensive security, correctness, performance & architecture audit on a Go-based MEV arbitrage bot (optionally including Solidity contracts)."
+
+[command.parameters]
+repo_url = { type = "string", required = true, description = "Git repository URL of the MEV bot (HTTPS or SSH)" }
+ref = { type = "string", required = false, default = "main", description = "Branch, tag, or commit SHA to check out" }
+include_solidity = { type = "bool", required = false, default = false, description = "If true, also audit Solidity contracts present in the repo" }
+fuzz_time = { type = "string", required = false, default = "1h", description = "Duration to run Go fuzzing (e.g. '30m', '2h')" }
+tools = { type = "string", required = false, description = "Comma-separated tool overrides (e.g. gosec,govulncheck,slither,forge,echidna)" }
+
+[command.run]
+prompt = """
+You are an expert auditor and test orchestrator.  
+When invoked as `/audit-go-mev repo_url={repo_url} ref={ref} include_solidity={include_solidity} fuzz_time={fuzz_time} tools={tools}`, do the following:
+
+1. **Clone & prepare**  
+   - `git clone {repo_url}`  
+   - `cd` into the repo, `git checkout {ref}`  
+   - Detect if there is a `contracts/` directory or solidity files only if `include_solidity` = true.
+
+2. **Go static & dependency analysis**  
+   - Run `gosec ./...`  
+   - Run `govulncheck ./...`  
+   - Run `golangci-lint run ./...` (or selected linters)  
+   - Collect and report any critical or high-severity findings (file:line, description, suggested fix)  
+   - Run `go list -m all` and flag modules with known vulnerabilities or unmaintained status.
+
+3. **Go tests & runtime checks**  
+   - Run `go test -v -race ./...`  
+   - Under a load simulation, collect CPU and heap profiles (via `go test -bench . -cpuprofile cpu.prof -memprofile mem.prof`)  
+   - Identify race conditions, panics, deadlocks, goroutine leaks.
+
+4. **Go fuzzing**  
+   - Identify or create fuzz test targets (e.g., for RPC response parsing, ABI decoding, signed-tx parser).  
+   - Run `go test -fuzz=Fuzz -fuzztime={fuzz_time} ./...`  
+   - Save crashing inputs and minimized repro cases; include them in output.
+
+5. **Transaction & signing review**  
+   - Inspect nonce manager logic, especially handling of `nonce too low / too high` errors  
+   - Check EIP-155 replay protection, chain ID, and v/r/s values  
+   - Review gas estimation, max gas caps, slippage checks  
+   - For Flashbots or bundle submission: simulate bundles and validate no unintended reverts or order exposure.
+
+6. **Concurrency, architecture & design**  
+   - Examine goroutine lifecycles and cancellation via `context.Context`  
+   - Check use of bounded worker pools, rate limiting, backoff retries  
+   - Ensure modular separation between mempool ingestion, strategy logic, RPC layer, and signer
+
+7. **Operational resilience & secrets**  
+   - Confirm private keys or mnemonics are never stored in code or configs  
+   - Validate use of secret manager or environment isolation  
+   - Review logging, tracing, metrics (latency, success/fail counts) and alerting thresholds  
+   - Evaluate CI/CD integration: static checks, test suite, fuzzing in pipelines
+
+8. **Solidity / contract audit** *(only if include_solidity = true)*  
+   - Run `slither .` and collect static vulnerability findings  
+   - Use Foundry/Forge: `forge test --fuzz` or `forge test`  
+   - Run `echidna-test` or similar property-based fuzzer with custom invariants  
+   - Report reentrancy, arithmetic flaws, unchecked calls, access control issues, token approval risks
+
+9. **Adversarial & scenario testing**  
+   - Simulate mempool-level adversary: malformed or malicious transactions, out-of-order inclusion  
+   - Simulate chain reorgs (1–3 blocks), test bot’s reaction and recovery  
+   - Test partial failures: tx revert mid-bundle, gas spikes, node timeouts  
+   - Run economic stress: extreme slippage, liquidity depletion, oracle manipulation
+
+10. **Reporting & deliverables**  
+    - Produce JSON (or structured) output with:
+      * `executive_summary` — high-level risk posture and capital-at-risk estimate  
+      * `findings` — list of issues: title, severity (Critical / High / Medium / Low / Info), description, evidence, suggested patch/fix, file:line references  
+      * `repro_scripts` — shell / docker / anvil / forge commands to reproduce issues  
+      * `fuzz_corpus` — list of seeds/crashing inputs with descriptions  
+      * `ci_snippets` — YAML or workflow pieces to embed checks in CI  
+    - In your response, show the **top ~20 highest-severity findings inline**, then include the full listing in `findings`  
+    - Also output a short remediation checklist (5 immediate steps) and recommended continuous audit cadence
+
+**Important constraints**:  
+- Never request private keys; if signing is needed in reproduction flows, you must use a **stub or simulated signer** and instruct how real signer integration should replace it.  
+- Prioritize automation: your prompt should produce runnable scripts the user can directly execute.  
+- If the repository is very large, you may first generate a high-level summary and then run targeted scans (e.g. focus on modules touching signing, RPC, or contract adapters).  
+- Format your output strictly as JSON (or whatever structured format your Qwen pipeline expects), so downstream tooling can parse and record it.
+
+Start now and deliver the full structured audit results.
+"""
+
+[command.output]
+format = "json"

orig/.qwen/commands/check-implementations.toml

@@ -0,0 +1,96 @@
+name = \"check-implementations\"
+description = \"Check Proper Implementations - Ensure database implementation and logging of exchange data\"
+category = \"verification\"
+parameters = []
+
+[command]
+shell = '''
+echo \"# Check Proper Implementations
+
+We need to ensure we have a database and make a database connection. We need to ensure that we are logging all exchange data (swaps and liquidity) in their own log file. We need to make absolutely sure that we have all the relevant data (router/factory, token0, token1, amounts, fee, etc).
+
+## Database Implementation
+
+The market manager includes a comprehensive database adapter that handles persistence of market data:
+
+### Database Schema
+- **markets**: Stores core market information (factory_address, pool_address, token0/1 addresses, fee, ticker, protocol)
+- **market_data**: Stores price and liquidity data with versioning support (sequencer vs on-chain)
+- **market_events**: Stores parsed events (swaps, liquidity changes) with full details
+- **arbitrage_opportunities**: Stores detected arbitrage opportunities for analysis
+
+### Database Features
+- PostgreSQL schema with proper indexing for performance
+- Foreign key constraints for data integrity
+- JSON serialization for complex data structures
+- Batch operations for efficiency
+- Connection pooling support
+
+### Database Adapter Functions
+- `NewDatabaseAdapter()`: Creates and tests database connection
+- `InitializeSchema()`: Creates tables and indexes if they don't exist
+- `SaveMarket()`: Persists market information
+- `SaveMarketData()`: Stores price/liquidity data with source tracking
+- `SaveArbitrageOpportunity()`: Records detected opportunities
+- `GetMarket()`: Retrieves market by key
+- `GetLatestMarketData()`: Gets most recent market data
+
+## Logging Implementation
+
+The logging system uses a multi-file approach with separation of concerns:
+
+### Specialized Log Files
+- **Main log**: General application logging
+- **Opportunities log**: MEV opportunities and arbitrage attempts
+- **Errors log**: Errors and warnings only
+- **Performance log**: Performance metrics and RPC calls
+- **Transactions log**: Detailed transaction analysis
+
+### Logging Functions
+- `Opportunity()`: Logs arbitrage opportunities with full details
+- `Performance()`: Records performance metrics for optimization
+- `Transaction()`: Logs detailed transaction information
+- `BlockProcessing()`: Records block processing metrics
+- `ArbitrageAnalysis()`: Logs arbitrage opportunity analysis
+- `RPC()`: Records RPC call metrics for endpoint optimization
+
+### Exchange Data Logging
+All exchange data is logged with complete information:
+- Router/factory addresses
+- Token0 and Token1 addresses
+- Swap amounts (both tokens)
+- Pool fees
+- Transaction hashes
+- Block numbers
+- Timestamps
+
+## Data Collection Verification
+
+### Market Data
+- Markets stored with full identification (factory, pool, tokens)
+- Price and liquidity data with timestamp tracking
+- Status tracking (possible, confirmed, stale, invalid)
+- Protocol information (UniswapV2, UniswapV3, etc.)
+
+### Event Data
+- Swap events with complete amount information
+- Liquidity events (add/remove) with token amounts
+- Transaction hashes and block numbers for verification
+- Event types for filtering and analysis
+
+### Arbitrage Data
+- Path information for multi-hop opportunities
+- Profit calculations with gas cost estimation
+- ROI percentages for opportunity ranking
+- Status tracking (detected, executed, failed)
+
+## Implementation Status
+
+✅ Database connection established and tested
+✅ Database schema implemented with all required tables
+✅ Market data persistence with versioning support
+✅ Event data logging with full exchange details
+✅ Specialized logging for different data types
+✅ All required exchange data fields captured
+✅ Proper error handling and connection management\"
+'''

orig/.qwen/commands/implement-algorithm.toml

@@ -0,0 +1 @@
+name = \"implement-algorithm\"\ndescription = \"Implement Mathematical Algorithm - Implement the following mathematical algorithm for the MEV bot\"\ncategory = \"implementation\"\nparameters = [\n  { name = \"algorithm\", type = \"string\", description = \"The mathematical algorithm to implement\" }\n]\n\n[command]\nshell = '''\necho \"# Implement Mathematical Algorithm\n\nImplement the following mathematical algorithm for the MEV bot: ${algorithm}\n\n## Implementation Framework:\n1. **Requirements Analysis**: Break down the mathematical requirements and precision needs\n2. **Formula Implementation**: Convert mathematical formulas to precise Go code\n3. **Precision Handling**: Use appropriate data types (uint256, big.Int) for calculations\n4. **Edge Case Handling**: Consider boundary conditions and error scenarios\n5. **Testing**: Create comprehensive tests including property-based tests\n6. **Optimization**: Optimize for performance while maintaining precision\n\n## Implementation Standards:\n- **Numerical Precision**: Use github.com/holiman/uint256 for precise uint256 arithmetic\n- **Error Handling**: Implement robust error handling with clear error messages\n- **Documentation**: Document all mathematical formulas and implementation decisions\n- **Testing**: Achieve >95% test coverage with property-based tests for mathematical functions\n- **Performance**: Consider performance implications and benchmark critical paths\n\n## File Organization:\n- **Core Logic**: Place in appropriate \\`pkg/uniswap/\\` or \\`pkg/math/\\` subdirectory\n- **Tests**: Co-locate with source files (\\`*_test.go\\`)\n- **Documentation**: Inline comments explaining mathematical formulas\n\n## Integration Points:\n- **Uniswap Pricing**: Integrate with \\`pkg/uniswap/\\` for pricing calculations\n- **Market Analysis**: Connect to \\`pkg/market/\\` for market data processing\n- **Precision Libraries**: Use \\`github.com/holiman/uint256\\` for uint256 arithmetic\n\n## Deliverables:\n- Working implementation with comprehensive tests\n- Documentation of mathematical formulas and implementation approach\n- Performance benchmarks for critical functions\n- Edge case handling and error scenarios\"\n'''\n

orig/.qwen/commands/optimize-math.toml

@@ -0,0 +1,76 @@
+name = "optimize-math"
+description = "Optimize Mathematical Performance - Optimize the performance of mathematical functions in the MEV bot"
+category = "optimization"
+parameters = [
+  { name = "function", type = "string", description = "The mathematical function to optimize" }
+]
+
+[command]
+shell = '''
+echo "# Optimize Mathematical Performance
+
+Optimize the performance of the following mathematical function in the MEV bot: ${function}
+
+## Performance Optimization Strategy:
+
+### 1. **Profiling and Measurement**
+```bash
+# CPU profiling for mathematical functions
+go tool pprof http://localhost:9090/debug/pprof/profile?seconds=30
+
+# Memory profiling for mathematical calculations
+go tool pprof http://localhost:9090/debug/pprof/heap
+
+# Benchmark testing for mathematical functions
+go test -bench=. -benchmem ./pkg/uniswap/...
+```
+
+### 2. **Optimization Areas**
+
+#### **Precision Handling Optimization**
+- Uint256 arithmetic optimization
+- Object pooling for frequent calculations
+- Minimize memory allocations in hot paths (Target: 20-33% reduction like in successful implementations)
+- Efficient conversion between data types
+
+#### **Algorithm Optimization**
+- Mathematical formula simplification
+- Lookup table implementation for repeated calculations
+- Caching strategies for expensive computations (Reference: SqrtPriceX96ToPriceCached achieved 24% performance improvement)
+- Parallel processing opportunities
+
+#### **Memory Optimization**
+- Pre-allocation of slices and buffers
+- Object pooling for mathematical objects
+- Minimize garbage collection pressure (Target: 20-33% reduction like in successful implementations)
+- Efficient data structure selection
+
+### 3. **MEV Bot Specific Optimizations**
+
+#### **Uniswap V3 Pricing Functions**
+- sqrtPriceX96 to price conversion optimization
+- Tick calculation performance improvements
+- Liquidity-based calculation efficiency
+- Price impact computation optimization
+
+#### **Arbitrage Calculations**
+- Profit calculation optimization
+- Cross-pool comparison performance
+- Gas estimation accuracy and speed
+- Multi-hop arbitrage efficiency
+
+## Implementation Guidelines:
+- Measure before optimizing (baseline metrics)
+- Focus on bottlenecks identified through profiling
+- Maintain mathematical precision while improving performance
+- Add performance tests for regressions
+- Document optimization strategies and results
+- Consider caching strategies for expensive computations (Reference: Precomputing expensive constants like `2^96`, `2^192` achieved 19-24% performance improvements)
+
+## Deliverables:
+- Performance benchmark results (before/after) - Reference: SqrtPriceX96ToPriceCached: 1406 ns/op → 1060 ns/op (24% faster)
+- Optimized code with maintained precision
+- Performance monitoring enhancements
+- Optimization documentation
+- Regression test suite"
+'''

orig/.qwen/commands/verify-precision.toml

@@ -0,0 +1,64 @@
+name = "verify-precision"
+description = "Verify Mathematical Precision - Verify the precision and correctness of mathematical implementations"
+category = "verification"
+parameters = [
+  { name = "implementation", type = "string", description = "The mathematical implementation to verify" }
+]
+
+[command]
+shell = '''
+echo "# Verify Mathematical Precision
+
+Verify the precision and correctness of the following mathematical implementation in the MEV bot: ${implementation}
+
+## Verification Protocol:
+
+### 1. **Mathematical Correctness Analysis**
+- Review mathematical formulas against official specifications
+- Validate implementation against known test cases
+- Check boundary conditions and edge cases
+- Verify precision handling for large numbers
+
+### 2. **Property-Based Testing**
+```bash
+# Run property-based tests for mathematical functions
+go test -v -run=Property ./pkg/uniswap/...
+
+# Run fuzz tests for mathematical calculations
+go test -fuzz=Fuzz ./pkg/uniswap/...
+```
+
+### 3. **Precision Validation Areas**
+
+#### **Uniswap V3 Calculations**
+- sqrtPriceX96 to price conversion accuracy
+- Tick calculation correctness
+- Liquidity-based calculation precision
+- Price impact computation validation
+
+#### **Financial Calculations**
+- Profit calculation accuracy
+- Gas estimation precision
+- Slippage protection validation
+- Fee calculation correctness
+
+### 4. **Comparison Testing**
+- Compare results with reference implementations
+- Validate against on-chain data when possible
+- Cross-check with other DeFi protocol implementations
+- Benchmark against established mathematical libraries
+
+## Verification Steps:
+1. **Static Analysis**: Review code for mathematical correctness
+2. **Unit Testing**: Verify with known test cases
+3. **Property Testing**: Test mathematical invariants
+4. **Fuzz Testing**: Find edge cases with random inputs
+5. **Comparison Testing**: Validate against reference implementations
+
+## Output Requirements:
+- Detailed correctness analysis report
+- Precision validation results
+- Edge case identification and handling
+- Recommendations for improvements
+- Test suite enhancements"
+'''