# mev-template-rs and the plumbing behind a Rust MEV bot > mev-template-rs is a Rust boilerplate for MEV strategies that supplies the plumbing rather than the strategy: websocket connections, mempool monitoring, ABI binding, a Uniswap aware template contract and a Discord alert path. It is a starting point for developers who already know what they want to do on chain, and it deliberately stops short of the profitable part. **degatchi/mev-template-rs** — Bootstrap your MEV bot strategies with a simple boilerplate to build on top of. - Repository: https://github.com/degatchi/mev-template-rs - Stars: 726 · Forks: 126 - Language: Rust - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/degatchi-mev-template-rs ## The template supplies plumbing, and deliberately not a strategy mev-template-rs describes itself as a way to bootstrap MEV bot strategies with a simple boilerplate to build on top of. The author is explicit about what that means in the README, and the framing is worth taking at face value rather than as marketing. The author states that a fair number of foundational features have been built out so they can be customised, that the repo lays out the basics so you do not have to copy and paste your bots for new strategies, and that the point is to help people who are struggling to get into MEV. He also explains the reason the project stops where it does: most of these features could be expanded into something far more comprehensive, but it is not wise to open source that, since competition would either use it or learn how advanced the system is. So the shape is deliberate. You get connections, decoding, bindings and alerts. The part that finds money is yours. The README also points to a companion article, How To Build A MEV Bot, which explains the overall architecture to think about, from getting a strategy and fetching data through to general design tips. That article carries the reasoning that the code does not. ## One git dependency does most of the work The dependency list in `Cargo.toml` is short, and one entry dominates it: ```toml [dependencies] # Interact w/ EVM blockchains. ethers = { git = "https://github.com/gakonst/ethers-rs", features = ["ws", "rustls", "abigen"] } # Loading .env variables. dotenv = "0.15.0" # Running async threads. tokio = { version = "1.5", features = ["macros", "rt-multi-thread"] } # For quick and easy discord alerts. reqwest = "0.11.10" ``` The `ws` feature is what makes websocket subscriptions possible, which is the transport a mempool listener needs. `rustls` is the TLS implementation, so no system OpenSSL is required. `abigen` is the code generator that turns a contract ABI into Rust bindings, which is the `Contract ABI binding` entry in the feature list. One detail deserves attention rather than glossing over. The `ethers` dependency is not taken from a registry. It points at a git repository, a fork of ethers-rs, with no version or tag constraint. That means your build fetches whatever that branch contains at build time, which is a supply chain decision you inherit rather than make. It is a normal pattern for a template that wants an unreleased feature, and a legitimate thing to change before this code handles a private key. The remaining dependencies are conventional: `dotenv` for environment loading, `tokio` for the async runtime, and `reqwest` for posting Discord messages. ## The .env file is the entire configuration surface There are four configuration values, and the example file names all four: ```yaml PRIVATE_KEY= NETWORK_RPC= NETWORK_WSS= DISCORD_WEBHOOK= ``` Two of those carry the whole system. `NETWORK_RPC` is used for reads, calling the blockchain, and `NETWORK_WSS` is what you need for subscriptions, and the example marks it optional because a strategy that only reacts to mined blocks does not need it. The mempool monitoring feature does need it, so a bot that watches the pending transaction pool has to supply it. `PRIVATE_KEY` is the externally owned account the bot signs with, and the README is blunt that this is the key the bot uses to execute transactions. It is a signing key for real funds, kept in a plain environment file. The repository ships `.env.example` and a `.gitignore`, and the sane setup is to copy the example to `.env`, fill it in and rely on the ignore rule to keep it out of version control. `DISCORD_WEBHOOK` is where alerts go. A Discord channel webhook is a bearer token for that channel, so the same care applies to it as to the private key. ## Mempool monitoring decodes the calldata it can recognise The monitoring example in the README shows the shape of a pending transaction as the bot sees it, including the hash, nonce, sender, recipient, value, gas price, gas limit, input bytes and the signature fields. Several of those are `None` for a pending transaction, which is what you would expect: a transaction in the mempool has no block hash, no block number and no transaction index yet. What the example adds is the decoded router call. The raw input is recognised and printed as a typed `SwapExactETHForTokens` call with its `amount_out_min`, the `path` of two pool addresses, the recipient and the deadline. That decode is the useful part and also the boundary. The feature list calls it simple tx decoding, and the template knows about Uniswap's router interface, which is why the `amountIn` and `amountOut` functions and the ABI binding exist in the first place. A transaction calling a contract the template has no binding for stays an opaque byte string, and the README does not describe a fallback path or a generic decoder you can plug in. The other structural feature here is the historic block function caller, which lets a strategy ask what a contract would have returned at an earlier block rather than only at the head. ## The template contract is a Uniswap aware contract with withdraw functions The repository includes a template contract, and the README's feature list breaks it down into Uniswap getters plus withdraw functions for ERC20 and ETH. That is a specific and reasonable shape for a MEV bot: a contract that can hold and move the funds a strategy captures, with a way to get them back out. The Uniswap getters are the other half. A strategy that wants to know the output for a given input, or to price a route, calls `amountIn` and `amountOut` against the router, and the contract provides them so a bot does not have to reimplement the quoting logic itself. The combination of a template contract, ABI binding, historic block calls and a decoded router call is what makes this a template rather than a library. Each piece alone is small. Together they are the plumbing that a strategy author would otherwise write before writing any strategy. What the repository does not include is worth noting too. There is no test suite described in the README, no simulation harness, and no profit accounting. The Python side covers data inspection, and the Rust side covers execution; the economics are entirely up to you. ## cargo run for testing, cargo run --release for production The quick start has five steps. Get a node from QuickNode, which the README recommends because it has a free websocket option, or run your own node. Import the EOA private key the bot will use to execute transactions. Add the Discord webhook to send alerts to. Then run `cargo run` for testing and `cargo run --release` for production. The split between debug and release is the only performance guidance in the README, and for a bot that has to react to mempool events, build profile is not a detail. The Python part is separate and is about inspecting on-chain data rather than executing trades. The README's setup is to install python3 with `pip install`, install the modules with `pip install web3`, and run `python3 block_history.py`. The script sits at the repository root, and `block_history.py` is the file to look at when you want to understand what history the bot can query. The README frames the on-chain data test around five components to consider: the `provider`, which chain is being used, the `abi`, the contract interface to interact with, the `block`, which mined block you are calling from and which can be a past block, the `contract address`, and the `function call` to make against that address. Those five are the parameters of a call, and they are also the parameters your strategy will need to decide what to look for. ## A template with no releases, and a licence you can read On project state, the repository is not archived, the last push was on 2026-04-14, and there are no GitHub releases. The `Cargo.toml` identifies the package as `mev-template` at version 0.1.0 with edition 2021, so the version number in the manifest is a starting value rather than a track record. The licence is MIT, with the text in the LICENSE file at the root, which is the permissive end of the spectrum and imposes no share-alike obligation if you fork and modify the template. The repository itself is small: `.env.example`, `.gitignore`, a `.vscode/` directory, `Cargo.toml`, `LICENSE`, `README.md`, `block_history.py` and `src/`. That shape says what it is, a starting skeleton rather than a framework with its own release discipline. The alternative to using this template is simply to depend on `ethers` directly and write the same plumbing yourself: the websocket subscription, the ABI generation, the alert call. The template saves that work and carries its extra cost, which is a git-sourced dependency, a private key in an environment file, and code you did not write. For a strategy where the edge is in the logic and not in the connection handling, that is a good trade. For a strategy where latency and execution are the edge, reading what this template does before you trust it with funds is the sensible order. ## Conclusion mev-template-rs is a reasonable starting point for a developer who knows the strategy they want to implement and wants the connection handling, ABI binding, mempool decoding and alert plumbing already in place. It is the wrong choice for a team that wants a working bot, and for anyone who cannot source a websocket RPC endpoint and a funded signing key. Verify first that the `ethers` dependency, which is pinned to a git fork of ethers-rs rather than a registry release, builds against the version of the library you intend to use, and that your `.env` file supplies `NETWORK_WSS` if you intend to subscribe to the mempool at all. ## FAQ ### What does mev-template-rs include out of the box? The README lists a Discord message system, a historic block function caller, Uniswap `amountIn` and `amountOut` functions, contract ABI binding, a template contract with Uniswap getters and ERC20 and ETH withdraw functions, and mempool monitoring with simple transaction decoding. The strategy logic itself is not included. ### How do I run the mev-template-rs bot? The README's quick start has you obtain a node with a websocket option, set the EOA private key and a Discord webhook, then run `cargo run` for testing or `cargo run --release` for production. The on-chain data script is separate and is run with `python3 block_history.py` after installing `web3`. ### Which environment variables does mev-template-rs need? The `.env.example` file names four: `PRIVATE_KEY` for signing transactions, `NETWORK_RPC` for calling the blockchain, `NETWORK_WSS` for subscribing to event streams, and `DISCORD_WEBHOOK` for sending alerts. The websocket variable is marked optional. ### Why does mev-template-rs depend on a git fork of ethers? The `Cargo.toml` lists `ethers` as a git dependency on a fork of ethers-rs with the `ws`, `rustls` and `abigen` features, rather than pinning a registry release. The README does not explain the reason, so the reason to change it to a pinned release is that your build otherwise depends on the contents of that branch at build time. ### What licence does mev-template-rs use? The repository is released under the MIT licence, declared in `Cargo.toml` and with the text in the LICENSE file at the root of the repository. ## Sources - [degatchi/mev-template-rs on GitHub](https://github.com/degatchi/mev-template-rs) - [Issues](https://github.com/degatchi/mev-template-rs/issues) - [License: MIT](https://github.com/degatchi/mev-template-rs/blob/main/LICENSE) - [README](https://github.com/degatchi/mev-template-rs/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/degatchi-mev-template-rs