zen-bot
East# Role Act as an expert Quantitative DeFi Developer and Lead Blockchain Architect specializing in Mev/Arbitrage infrastructure. # Context & Objective I am upgrading a standard cross-DEX arbitrage bot to detect and execute Multi-Asset Triangular Arbitrage. The standard monitoring logic is too limited; I need a robust, production-grade TypeScript algorithm that builds a token/pool graph, detects profitable negative cycles, and calculates mathematically optimal input sizes to maximize arbitrage yield while accounting for slippage and price impact. # Scope & Technical Specifications ## 1. Graph Construction (Data Layer) - Write a modular TypeScript module that constructs a directed graph representing available liquidity pools. - **Filtering:** The graph must only include pools with a minimum liquidity threshold of $10,000 USD. - **Environment & Source:** Assume the target is the Polygon network, pulling from multiple DEXes (Uniswap v2 clones, e.g., SushiSwap, QuickSwap). - **Universe:** Scan *all* available pools/tokens meeting the $10k liquidity threshold (do not arbitrarily restrict to top-50 tokens). - **Data Structure:** Structure the graph nodes as tokens and directed edges as pools, where edge weights represent the effective exchange cost (logarithms of price ratios) to facilitate negative cycle detection. ## 2. Pathfinding Algorithms (Execution Layer) Implement both of the following graph-search algorithms within a clean, comparative interface: - **Bellman-Ford:** Optimized for sparse graphs, capable of early termination and explicitly returning the negative cycle path. - **Floyd-Warshall:** An all-pairs shortest path implementation ($O(V^3)$) to act as a benchmark comparison. - Ensure the algorithms account for DEX trading fees (e.g., 0.3% fee) directly within the edge weight calculation ($\text{weight} = -\ln(\text{price} \cdot (1 - \text{fee}))$). ## 3. Size Optimization (Quantitative Layer) - Do not use naive fixed-size trade inputs. - Implement an exact size optimization function using calculus. Use the first derivative of the Constant Product Formula ($x \cdot y = k$) compounded across a 3+ token path to solve for the exact maximum profit point ($d(\text{Profit})/d(\Delta x) = 0$). - This function must output the exact optimal input size in the origin token to maximize returns and prevent over-sizing a trade into price impact. # Deliverables Required 1. **TypeScript Codebase:** Modular, strongly-typed clean code (no `any`, no placeholders, no "implementation left as an exercise"). 2. **Mathematical Explanations:** A brief markdown section explaining the exact calculus derivatives used for the multi-pool composition optimization. 3. **UI/UX Mock Layout:** A conceptual architectural outline or schema for a full-stack dashboard (React UI + FastAPI/Node backend) that would visualize these detected triangular cycles and metrics (ROI, path, latency) in real-time.
Comments (0)
Sign in to leave a comment
System Requirements
zen-bot System Requirements Document
1. Introduction
The zen-bot project aims to implement a zero-allocation, high-frequency Multi-Asset Triangular Arbitrage engine on the Polygon PoS network. The system will utilize a flat memory model, advanced pathfinding algorithms, and exact analytical size optimization. It will also feature a full-stack real-time dashboard, ensuring zero runtime garbage collection interference and strict typing integrity.
2. System Overview
The zen-bot system will operate on the Polygon network, interfacing with multiple DEXes such as Uniswap v2 clones, including SushiSwap and QuickSwap. It will focus on constructing a directed graph of available liquidity pools, implementing pathfinding algorithms to detect arbitrage opportunities, and optimizing trade sizes for maximum profitability. The system will be designed to handle extreme throughput conditions and ensure efficient execution with minimal latency.
3. Functional Requirements
- As a Quantitative DeFi Developer, I should be able to construct a directed graph representing available liquidity pools using a modular TypeScript module with a flat memory buffer representation.
- As a Quantitative DeFi Developer, I should be able to filter the graph to include only pools with a minimum liquidity threshold of $10,000 USD, dynamically tracked via stablecoin routing pairs.
- As a Quantitative DeFi Developer, I should be able to normalize core nodes for native token decimals using native JavaScript
bigintfor all internal reserve calculations. - As a Quantitative DeFi Developer, I should be able to implement Tarjan’s Strongly Connected Components (SCC) algorithm to prune dead-end paths.
- As a Quantitative DeFi Developer, I should be able to implement the Bellman-Ford algorithm optimized for directional subgraphs with early termination.
- As a Quantitative DeFi Developer, I should be able to implement the Floyd-Warshall algorithm for all-pairs shortest path as a benchmark comparison.
- As a Quantitative DeFi Developer, I should be able to calculate edge weights reflecting directional exchange costs and account for pool-specific fees.
- As a Quantitative DeFi Developer, I should be able to implement an exact size optimization function using calculus to solve for the exact maximum profit point.
- As a Quantitative DeFi Developer, I should be able to design an execution filter that evaluates if the gross profit of a cycle covers the gas overhead.
- As a Quantitative DeFi Developer, I should be able to implement a raw bitwise calldata encoder without external ABI libraries.
- As a UI/UX Architect, I should be able to provide a complete architectural design and data flow schema for a real-time tracking interface.
4. User Personas
- Quantitative DeFi Developer: Specializes in developing and optimizing algorithms for decentralized finance applications, particularly in arbitrage and trading strategies.
- Lead Blockchain Architect: Focuses on designing and implementing blockchain infrastructure, ensuring scalability, security, and efficiency.
- UI/UX Architect: Designs user interfaces and experiences, focusing on real-time data visualization and interaction.
5. Core User Flows
- Developer constructs graph -> filters pools by liquidity -> implements Bellman-Ford and Floyd-Warshall algorithms -> optimizes trade size -> executes arbitrage.
- Architect designs system architecture -> integrates TypeScript modules -> ensures real-time data visualization on the dashboard.
- UI/UX Architect designs and implements the real-time tracking interface -> integrates WebSocket state streaming -> visualizes data models.
6. Visuals Colors and Theme
- primary: #1A73E8 (deep blue)
- primary_light: #4D90FE (light blue)
- secondary: #FF7043 (coral)
- accent: #FFD54F (amber)
- highlight: #FFB300 (gold)
- bg: #F5F5F5 (light grey)
- surface: rgba(255, 255, 255, 0.8) (white)
- text: #212121 (dark grey)
- text_muted: #757575 (medium grey)
- border: rgba(33, 33, 33, 0.1) (light grey)
7. Signature Design Concept
The zen-bot's landing page will feature an interactive 3D network graph visualization using @react-three/fiber and @react-three/drei. Users can rotate and zoom into the graph to explore different liquidity pools and arbitrage paths. Each node represents a token, and edges represent pools, dynamically updating in real-time to reflect current market conditions. Hovering over a node or edge will display detailed metrics such as liquidity, price impact, and potential ROI. This immersive experience will make the complex data accessible and engaging.
8. Interaction Model & Motion Direction
The landing page will utilize a "parallax" interaction model, with layered depth via scroll. The 3D network graph will translate at different speeds, creating a sense of depth and immersion. Real content will stay in normal flow and scroll naturally, providing a visually rich first impression. Internal pages will adopt a "static" model for clarity and speed, focusing on data-heavy content.
9. Non-Functional Requirements
- The system must handle real-time data updates with minimal latency.
- The TypeScript codebase should be modular and strongly-typed.
- The system should be scalable to accommodate increasing numbers of tokens and pools.
- The system should ensure zero runtime garbage collection interference.
10. Tech Stack
- Frontend: React for Web
- Backend: Node.js or FastAPI
- Database: MongoDB
- Local Orchestration: Docker, docker-compose
- Server-side Orchestration: Kubernetes
11. Assumptions and Constraints
- The system assumes the Polygon network as the target environment.
- The graph construction module assumes access to real-time data from multiple DEXes.
- The system is constrained by the liquidity threshold of $10,000 USD for pool inclusion.
12. Glossary
- DEX: Decentralized Exchange
- Liquidity Pool: A collection of funds locked in a smart contract for trading.
- Arbitrage: The simultaneous purchase and sale of an asset to profit from a difference in the price.
- Triangular Arbitrage: A type of arbitrage that exploits price discrepancies between three different currencies or assets.
- Polygon Network: A protocol and framework for building and connecting Ethereum-compatible blockchain networks.
Detect negative cycles before the market does.
zen-bot builds a directed graph of every liquidity pool above $10k, prunes dead ends with Tarjan's SCC, runs Bellman-Ford and Floyd-Warshall to surface profitable triangular arbitrage, then solves the exact optimal trade size with calculus — no over-sizing into price impact.
- SushiSwap
- QuickSwap
- Uniswap v2 clones
- Zero-alloc hot path
From raw pools to executed arbitrage
The same flow a Quantitative DeFi Developer follows — graph, filter, detect, optimize — wired into fast, static, data-heavy internal tools.
Construct the pool graph
A modular TypeScript module maps tokens to nodes and liquidity pools to directed edges, with edge weights encoding effective exchange cost.
Open GraphBuilder →Filter and prune the graph
Every pool below the $10,000 USD threshold is pruned, then Tarjan's SCC isolates only subgraphs that can route back to WMATIC, WETH, WBTC, USDC and USDT.
Open GraphBuilder →Detect negative cycles
Bellman-Ford (sparse-optimized with early termination) returns the negative cycle path; Floyd-Warshall runs all-pairs as a benchmark comparison.
Open Algorithms →Solve size, then clear the gas gate
A calculus-based optimizer solves for the exact maximum-profit input in the origin token, then the execution filter checks gross profit against live maxFeePerGas before firing.
Open Optimizer →Two engines. One source of truth.
Detect profitable cycles with a sparse-optimized Bellman-Ford, then validate against a Floyd-Warshall all-pairs benchmark — with trading fees priced into every edge and phantom-liquidity pools discarded before either engine runs.
- Runs only on Tarjan SCC-pruned subgraphs that settle back to base assets
- Early termination when no relaxation occurs
- Returns the full negative cycle path for execution
- DEX fees folded directly into edge weights
Exact optimal size — solved with calculus
Every hop's constant-product pool is compounded into one virtual pool, then the optimizer differentiates the composite profit function and solves for the exact input in the origin token where marginal profit hits zero — no loops, no binary search, no over-sizing into price impact.
Turn Polygon liquidity into a solvable graph.
Construct the pool graph, run the algorithms side by side, and let the optimizer size every trade to the exact profit peak — streamed live over WebSocket to one dashboard.
No comments yet. Be the first!