destiner / mev-inspect-js Goto Github PK

View Code? Open in Web Editor NEW

128.0 6.0 15.0 1.27 MB

A JS port of "mev-inspect-py" optimised for ease of use.

License: MIT License

TypeScript 100.00%

mev-inspect-js's Introduction

MEV Inspect

A JS port of mev-inspect-py optimised for ease of use.

Motivation

While mev-inspect-py is great, I believe that there are a few changes can be made to make historical MEV data more accessible. Here are some defining decisions for this port:

Written in Typescript: easier to run in browser/node, while keeping the code type-safe
Infra layer decoupling: message query, caching, and persistence layers can be added independenty when/if needed
Pricing data decoupling: to calculate profit and cost in USD, a pricing provider of your choice can be used
Single transaction inspection: while missing some types of MEV, this is helpful for quick transaction review
Using logs instead of call traces: any historical node would work

Other, less fundamental, changes include:

Fork support (e.g. Sushiswap)
Multichain support
Abilitiy to "bring your own transaction receipts" (e.g. via Alchemy)

API

Inspector
- constructor(chainId, provider)
- tx(hash): processes a single transaction given hash
- block(number): processes a single block given number
- receipts(receipts): processes an arbitrary amount of transaction receipts
getBlock(mev): get MEV block number
getTransaction(mev): get MEV transaction hash
getArbitrages(mevList): filter out non-arbitrage MEV
getLiquidations(mevList): filter out non-liquidation MEV
getSandwiches(mevList): filter out non-sandwich MEV
getJitSandwiches(mevList): filter out non-JIT liquidity sandwich MEV
getNftArbitrages(mevList): filter out non-NFT arbitrage MEV

A common data flow is to first fetch all the MEV using any of the Inspector method, then filter it by type using getArbitrages, etc, and finally process each type of MEV separately

Usage

This package requires ethers V6. If you use ethers V5, you need to use mev-inspect V3.

This package uses BigInt. If you use a bundler, you may want to set the build target to es2020.

This package is a pure ESM package. Follow this guide for more info.

npm i mev-inspect

// Ethers V6
import { AlchemyProvider } from 'ethers';
import { Inspector } from 'mev-inspect';

const arbitrageTx =
  '0x06387618ee3752bed447f192802895921a7d45a60875927adfedc93a68bcbe05';
const key = process.env.PROVIDER_KEY;
const provider = new AlchemyProvider(1, key);
const inspector = new Inspector(1, provider);
const txMev = await inspector.tx(arbitrageTx);
console.log(txMev);

For more examlples, see examples.

Support

MEV type

Arbitrage
Liquidations
Sandwiches
JIT liquidity sandwiches
NFT arbitrage

Chains

Ethereum
Polygon
Arbitrum
Optimism
Avalanche

Protocols

Swaps: Uniswap V2/V3 (+ forks), Balancer V1/V2, Curve V1/V2, 0x V3/V4, Bancor V2/V3
Lending: Compound V2 (+ forks), Aave V1/V2/V3
NFT swaps: Opensea (Seaport), LooksRare, Sudoswap, X2Y2

How it works

It starts by fetching all event logs for a given transaction or block. Then, it "sorts" logs based on their source and type. From those logs, it extracts swap data. It then analyzes the swaps to find arbitrage.

mev-inspect-js's People

Contributors

Stargazers

Watchers

Forkers

kootszhin xjjda22 tomjrtsmith planet-2020 cyb3rn8 pamarthisai twpony tsubasakong huhaoqian wenhsh louis-xer neronjust2017 aloebera symonsay sam-goldman

mev-inspect-js's Issues

Use transfer events to detect "from" of Uniswap V2/V3 swaps

Tx: 0xd53808dc31c908b7acad610d5efa726afe67e7c9739083be9c1b4cb6d2cdaeac.

In the swap with the log index 10, sender set to 0x58418d6c83efab01ed78b0ac42e55af01ee77dba, while the actual erc20 token sender 0x5aa3393e361c2eb342408559309b3e873cd876d6 (as seen in transfer with the log index 7). This breaks arbitrage detection heuristics.

Uni V3 might also be subject to this.

Compare against known MEV searcher transactions

While #11 is helpful, its information is limited: as I realised, Flashbots misses quite a handful of easy-to-detect MEV. Another strategy might be first to identify a few active MEV bots, and then analyse their transactions. Since we know they are bots, any transaction involving them in which we can't find MEV would be suspicious, and might hint at missing some arbitrage.

ETH -> token, token -> ETH Balancer V2 trades are not detected

Example txs:

0xc785c5713ef1d2e527559746004276f15aaedf62503b670bdf16e156b82aa39b
0xa87d22940d3b93b491683de99d48cab79c171fe1535586862e0c0ace381928f0

Arbitrage not detected when swap.from and swap.to are different

In most cases, both from and to addresses are the same. Sometimes though, they are different, which breaks the algorithm.

Example txs:

0x49fb0fb07827b3e6fa425fbb7ef1f1fbe3dfedbf656519bfe6d4bf9391aea1d2.
0xcce82565d597057f6d0391fecb139e773cd9cac9a5f9d9ee5a21f7aa2b912bd3

Fetch logs more efficiently across blocks

Since we rely on event logs instead of call traces, and we know what logs to look for in advance, it would likely be more efficient to fetch them via eth_getFilterLogs. This is especially useful when looking for MEV across hundreds of blocks.

Test against transactions with large amount of actions

Now that I'm relatively confident that the package works well for a simple swaps and arbs, it would be cool to test it against transactions with large number of swaps and token transfers coming from several protocols.

Error [ERR_REQUIRE_ESM]: require() of ES Module

When executing:
const inspector = new Inspector(1, provider);

I got error:

Error [ERR_REQUIRE_ESM]: require() of ES Module /home/myhome/Documents/ethereum/solidity/searcher/node_modules/mev-inspect/lib/index.js from /home/myhome/Documents/ethereum/solidity/searcher/index.ts not supported.
Instead change the require of index.js in /home/myhome/Documents/ethereum/solidity/searcher/index.ts to a dynamic import() which is available in all CommonJS modules.

However if I add
"type": "module",

in my package.json, I got error:

ReferenceError: exports is not defined in ES module scope

I am using nvm version 0.38.0