krishankshh/nofeeswap

1. This repo is a three-runtime local protocol environment: a React dApp in frontend/, a Hardhat-based local chain in chain/, and a TypeScript mempool/sandwich bot in bot/. The core/ and operator/ directories are not the live app; they are reference protocol implementations with heavy test coverage.

2. The primary user-facing boundary is the frontend. It is a React 19 + TypeScript + Vite app that routes between Dashboard, Swap, Pool, and Liquidity pages. The UI is split into reusable layout, wallet, pool, and transaction components, with stateful behavior concentrated in custom hooks.

3. Frontend chain access is centralized through ethers.js v6 hooks and contract/config files. The app reads ABIs from frontend/src/abis/, contract addresses from src/config/contracts.ts, chain metadata from src/config/chains.ts, and token metadata from src/config/tokens.ts. This keeps UI components separate from Web3 plumbing.

4. Wallet integration is a distinct subsystem. useWallet and the wallet components manage MetaMask connect/disconnect, network detection, and chain switching. That wallet state feeds swap, pool, and liquidity flows, which then use transaction hooks for approve/submit/pending/confirmed/reverted lifecycle handling.

5. The local chain in chain/ is the execution backend for the dApp and bot. It is a Hardhat network deployment with a deployment script that initializes test ERC-20s, deploys a NofeeOperatorLike contract, seeds a default pool, and writes addresses to chain/deployments/localhost.json.

6. NofeeOperatorLike is the on-chain contract boundary the frontend targets. In this assignment it stands in for the real NoFeeSwap operator interface, exposing pool initialization, swap, and liquidity management entry points. The frontend’s swap/liquidity pages are built against that interface, not against the underlying protocol internals.

7. The bot in bot/ is a separate runtime that also targets the same local Hardhat chain. Its architecture is a pipeline: pending-transaction monitoring in index.ts, calldata parsing in decoder.ts, profitability estimation in profitability.ts, then front-run/back-run execution against the operator contract.

8. The bot and frontend share the same chain state but serve different roles. The frontend is an interactive client for a user with MetaMask, while the bot is an autonomous actor watching the mempool and submitting transactions based on decoded swap intent and estimated slippage/profit.

9. The core/ and operator/ directories are the protocol reference layer. They contain Solidity/Python test harnesses, Brownie/Hardhat configs, and Echidna fuzzing setups that validate the real NoFeeSwap logic. Architecturally, they inform the protocol model but are not part of the simplified local app runtime.

10. Data flow is therefore: user action in the React UI → wallet signature in MetaMask → ethers.js call through frontend hooks → Hardhat local contracts → updated on-chain state read back into the UI. In parallel, the bot consumes pending transactions from the same node, decodes them, and reacts before they are mined.

11. The most important diagram boundaries are: browser/UI, wallet provider, local blockchain node, deployed contracts, bot process, and reference protocol/test repos. A separate boundary worth noting is that several UI features, like the kernel editor and liquidity chart, are presentation-oriented and do not write the full NoFeeSwap kernel model on-chain in this simplified setup.