Try   HackMD

Builder->Proposer Payment Transfer Unbundle

⚠️ TLDR; A blocknative proposer payment for slot X (mev-boost) was found in slot X + 84 (non-mev-boost) and detected in the public mempool. The validator for both slots belong to the same pool according to beaconcha.in.

working backwards

Fact finding lead to the following observations:

  • blocknative relay won slot 6260353
  • slot 6260353 was missed on beacon chain
  • the transfer amount of 160376265645027208 wei in the future block at slot 6260437 correlates to the bid value from blocknative builder at prior missed slot 6260353
  • the validators in both slots above map to a shared validator pool "wangdong.eth" on beaconcha.in
    - our mempool archive detected the builder's payment tx hash 0xbae.. as pending at block 17084002 which is the canonical tip at time of missed slot:
[{"slot":"6260353",... , "value":"160376265645027208",
"block_number":"17084002",
"num_tx":"103"}]

slot 6260353 relay timing info

Below times are UTC, above is UTC-4

  • getHeader request : 2023-04-19T23:50:59.501719962Z
  • getPayload request : 2023-04-19T23:51:00.306691172Z
  • beacon publish: 2023-04-19T23:51:01.027018992Z
  • getPayload response: 2023-04-19T23:51:02.027155397Z
    Image Not Showing Possible Reasons
    • The image was uploaded to a note which you don't have access to
    • The note which the image was originally uploaded to has been deleted
    Learn More →
  • residual publishing time for proposer: 23:51:02 - 23:50:59 = 2.02s for the proposer to prop + assume ~300ms for relay -> proposer transport gives ~1.75s for proposer to prop

questions

  • How did this tx get into the mempool?

possible mitigations

  • using a smart contract for payment which accepts a blockNumber and timestamp range
    • adds gas overhead but worth it even if it protects once