How the book is rebuilt

Nothing in the app is typed in. A read-only loader replays the chain, a ledger nets the movements into positions, and a set of checks tests the result against the chain again. Each stage reports what it actually found.

The pipeline

One transaction, one event

The unit is what entered and left the wallet in a single transaction. A swap routed through several pools is one exchange, not several — the intermediate legs belong to the router, not to us.

Deriving the ETH side without an explorer

Sell proceeds usually arrive as internal ETH transfers, which ordinary RPC does not expose. When the explorer was unavailable for three days, the proceeds were recovered from the receipts instead.

Measured on real trades, and reproducible:

• a buy sends ETH as the transaction's value;
• a sell through the router receives ETH in data word 1 of the router event 0x8619026a…, the one with the wallet in topic 1;
• a sell straight into a pool receives ETH in data word 1 of the pool event 0x8113d738….

Every one of these is checked against the explorer's internal transfers wherever both exist, and the test suite fails if a single sale differs by one wei.

That check caught a real error. The first version read the pool event for every sale. On a routed sale — token → GME → USDG → ETH — the pool's word 1 is GME, not ETH, and 253 of 1,768 sales were wrong, one of them by 127×. Reading the router's own total fixed all of them, and it also resolved 40 sales that had been parked as "result unknown". The published result moved from +21.31 to ++52.41 ETH.

Both sides therefore come out of the receipt, and the explorer's internal-transaction feed is not needed at all. Pulling every hash found in the transfer logs closed the gap completely, and reached 1.5 days further back than the explorer's own transaction list: transfer logs begin at block 51,264,835, the explorer's list only at 52,606,884.

Checking that the wallets are one desk

The desk has moved wallets twice. You do not have to take that on trust — the chain says it, and here is how to read it yourself.

The launchpad's buy event names two parties: the contract that called it, and the wallet the tokens are for. On almost every buy those two are the same address, because almost everyone buys through the public router. A bot buying through a contract of its own does not, which narrows an hour of blocks from thousands of buyers to a few dozen candidates.

The test that settles it is the bytecode. The sniping contract is the same build on every wallet: take eth_getCode of the contract, blank out the owner address compiled into it, and compare. Across the three wallets it matches to the byte — and of the forty-odd candidates in that hour, nothing else did.

Three more things line up with it: each wallet started trading before the previous one went quiet, all three sell through the same router, and all three take money off the chain the same way. Where those ever disagree, this page will say so.

Capital that left over the bridge

Withdrawals do not move the wallet's tokens, so they are not in the transfer logs either. They are found through the bridge instead: every Across deposit on the chain names its depositor, and filtering on this wallet returns 20 withdrawals, 67.00 ETH in total. They are capital leaving the chain, not a result, and never enter profit and loss.

With them counted, money in minus money out minus gas lands 8.84 ETH away from the balance on chain. The wallet balance does not match the reconstructed flows. Missing flows or fees remain unresolved; the direction of the gap does not verify the trading result.

What is still missing

171,591 transactions appear in the nonce sequence but could not be retrieved from the explorer's list. They moved no tokens — if they had, they would be in the logs — so profit and loss is unaffected. What they do affect is the count of reverted attempts and the gas spent on them, which are therefore a floor, not a total.