flashbots/mev-blocks

mev-blocks

Run locally

yarn install
yarn gen-docs
yarn run start

Build docker container

docker build -t mev-blocks .

Run docker container

docker rm -f mev-blocks; docker run -d --network=host -e 'POSTGRES_DSN=postgres://mev_blocks@localhost:5432/mev' --init --name mev-blocks --restart=always mev-blocks

mev-blocks's Issues

goerli deployment of blocks api

Wrong units?

The docs total_miner_reward in the Get Blocks API say it is measured in ETH, but the number is way too high, e.g.,

{
  "blocks": [
    {
      "block_number": 12006597,
      ....
          "gas_used": 292129,
          "gas_price": "129000000000",
          "total_miner_reward": "37684641000000000"
        },

I suspect that this should be in wei not ETH.

add timestamp filed in /v1/blocks response

Please add the filed timestamp about the block mined in the blocks's response @jparyani

Add "after" query param

Would be awesome if i could more easily start parsing data X number of elements at the time from the oldest block with an after param.

Right now i can start reading from the oldest block, but i'll end up with a uneven amount of data and overlap if i ask for the next 10.000 range one chunk at the time

should we expose bundle & block timestamps?

Idea: expose three new timestamps in /transactions and /blocks

• block.witnessed_at
• transaction.received_at
• transaction.sent_to_miners_at

@jiangjinyuan already made an issue about block timetamps: #7

Returning the timestamp at which a new block was witnessed by the relay will let you know exactly how much time you have, between then and when the block gets mined, to submit a bundle.

I think this is an easy yes.

Exposing data about other searchers' bundles, however, might be contentious.

Pros:

• allows searchers to compare timestamps of conflicting bundles
• this way you can know whether your opponent is sending bundles before you

Con:

• anyone can see how quickly your bot builds and sends a bundle (thereby leaking info about how fast your strategy's algorithm is)

websockets support for blocks api

Some blocks are missing the bundle_type attribute

Here is what block query should look like (with bundle_type) returned:

$ curl https://blocks.flashbots.net/v1/blocks?block_number=14849437 | jq '.blocks[0].transactions[0]'
{
  "transaction_hash": "0x3c265fa66e96365cd8b0aa974d482b10e392eacb095662b230bb02bf42016239",
  "tx_index": 0,
  "bundle_type": "flashbots",    <-----------------------
  "bundle_index": 0,
  "block_number": 14849437,
  "eoa_address": "0xD2006fcC22DF4a674839b357Ba1525cCb05efe92",
  "to_address": "0x8aFF5cA996F77487a4f04F1ce905Bf3d27455580",
  "gas_used": 131095,
  "gas_price": "30969086989",
  "coinbase_transfer": "4059892458912163",
  "total_miner_reward": "4059892458912163",
  "is_megabundle": true
}

Here's an example that is missing the "bundle_type" attribute, it's always on megabundle (but not all megabundles are missing it):

$ curl https://blocks.flashbots.net/v1/blocks?block_number=14849053 | jq '.blocks[0].transactions[0]'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6486  100  6486    0     0  15602      0 --:--:-- --:--:-- --:--:-- 15742
{
  "transaction_hash": "0xb1a35fde6c36691e2d3185571616335490c5c7e65c7237ff9a151089115bb432",
  "tx_index": 0,
  "bundle_index": 0,
  "block_number": 14849053,
  "eoa_address": "0x881cd15C7c1aBF84416764fFbc6Dad44751122bb",
  "to_address": "0x1111111254fb6c44bAC0beD2854e76F90643097d",
  "gas_used": 180569,
  "gas_price": "7000000000",
  "coinbase_transfer": "0",
  "total_miner_reward": "1263983000000000",
  "is_megabundle": true
}

Historical json dump missing blocks

Hello. The historical json dump ends at block 14986955. Any chance this can be replaced by a more current dump? Thanks!

add `to` filter to /blocks