Builder->Proposer Payment Transfer Unbundle

working backwards

• Blocknative monitors noticed a non-authorized payment transfer hash 0xbae... from our builder address 0xbaf.. at slot = 6260437
  • account balance delta > excess transfer gas, only triggered when purposefully removing funds
  • blocknative procedure requires multiple approvals and records of intent for such a transfer and none were found in our system
• Blocknative relay data API shows we did not win this block
  • Flashbots relay confirms the same
  • Ultrasound relay confirms the same
  • Agnostic relay confirms the same

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

• slot start: Apr-19-2023 19:50:59 per beaconcha.in

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
  
• 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