nftchance / mev

A "process-parallel" MEV bot engine designed specifically for individuals that need high data stream throughput paired with the ability to craft new strategies in as few lines of code possible.

🥵 MEV

A Typescript-based "process-parallel" MEV bot that has been evolved throughout the years. What this means, is that instead of creating new scripts and collectors for each of your strategies you can simply reuse the streams of data that already exist. Instead of needing a new block collector for every single strategy you run within the EVM ecosystem you can simply reuse a constant feed from one RPC endpoint. By doing this your RPC interactions remain far more managable and you are less limited by scale and throughput.

Inspired by Artemis, the key pieces of this engine can be broken down into:

• Collectors: Streams of data that consume and forward onchain and offchain events/triggers.
• Executors: Actions taken when an event is received.
• Strategies: Organization of Collectors and Executors to form a single-lane outcome.

Getting Started

Note

When using the bot you will want to create a playground that contains all the individual pieces of your strategies, this repository contains the core engine that is needed to get you up and running. There are no default strategies included at this time. However, you can see an example of implementation at src/core/strategies/block.log.ts.

To get started, we will use pnpm to install the dependencies and run the bot.

First, install the dependencies:

pnpm install

If you are starting a new bot or do not have a configuration to import, you can run the following command to generate a new configuration file:

pnpm mev init

As your strategies become more complex you will need local interfaces to the contracts that you interact with. To do so, simply run:

pnpm mev references

By running mev init a configuration with a base example has been generated at mev.config.ts folder of your project root. Just like that, you are up and running. Of course, if there was no configuration to run a money-making bot that would be awesome, wouldn't it? That is not the case here.

With a passing test suite, you are cleared to enable the bot and let it run. With all the effort leading up to here, just run:

pnpm mev start

mev's Issues

feat: l2/l3 & blockscout support

fix: convert yaml usage to config declaration

chore: multi-platform test cases for base commands

Opened to note the needed resolve and robust coverage for core functionality before sharing with others. Don't want to release it and have everyone experience issues I haven't yet covered.

Hey I was trying out your mev package and not sure if it applies to linux and mac but on windows mev references errors out when running the abi-to-sol command. removed the single quotes from ${abi} fixes the issue. I couldn't create a new branch and submit a pull request since I don't have any permission

• @snagsdev

chore: package publishing

Right now there is an issue with the changesets setup that is resulting in automated publishing be broken. Was a hectic week and didn't have time to figure it out. Critical to take care of so that active versions can be safely and verifiably used before releasing.

Incorrect script command for `premev` in `package.json`

Description

The premev script in the package.json currently uses npx build, which causes an error because npx cannot find a command named build.

The correct script should use pnpm run build to execute the build script defined in the package.json.

Steps to Reproduce

1. Clone the repository.
2. Run pnpm mev init in the terminal.
3. Observe the error: npm ERR! could not determine executable to run.

Suggested Fix

Update the premev script in package.json to:

"premev": "pnpm run build"

feat: strategy retries on crash

feat: support native multichain with multiple engines in the same process

feat: reference generation in cli

feat:telegram excuter

I suggest adding a Telegram excuter

fix: config item initialization

Imagine, you are running a strategy on Uniswap. You generate references for any piece of the protocol that is consumed by your Strategy. Then, at compile time it will error out due to missing imports rather than having properly been built pre-access at runtime.

To implement support for this, strategies should be declared, but not initialized in the config. The engine will initialize them based on the args provided.

feat: generate typescript interfaces for reference contract children

Right now when including a reference we only generate a Typescript interface for the top-level contract even though in certain cases we will most definitely want all the children as well.

Right now, for each reference a index.ts is generated however instead we should generate a ${name}.ts for each Solidity file found. This way all Solidity files can be interfaced with ease. Additionally, this means one can reuse the onchain interfaces already provided by a protocol.

For example, UniswapV3Factory returns a IERC20Minimal.sol however we do not have a Typescript interface for it, even though that would make things much simpler due to the assumption that something within the contract needs it and therefore our Strategy would benefit from access to that without manual declaration.

chore: references retention & intelligent retries

Each time you run mev references existing references are dumped. This is done because sometimes you will hit the throttle of Etherscan. Need to add a check to determine if you've been throttled/source retrieval failed. Additionally, should go ahead and make sure that when a reference is already up to date and properly built we do not need to worry about rebuilding it as this just leads to a compounding issue when you reach the point of having ~30 contracts consumed by your strategies. Aim should be to do N contracts without any disturbance and gracefully handle failures with N retries before giving up.

This issue highlights the realistic need for a small refactor with the way Etherscan is being interacted with in general, though. Right now it is scoped to be single-chain supporting which is less than ideal. This will lead into finally publishing the forked branch that holds the general multi-chain enabling functionality, though that will be a later update as it requires thorough edge-case support due to the nuances of each chain and the way that implies shifts in logic within Collectors.