# How 40 BTC becomes 256 BTC, and every digit stays true

On 15 May 2026 a THORChain vault paid 36.853504 BTC into an address that had no business receiving it. The exploit is documented by [TRM Labs](https://www.trmlabs.com/resources/blog/thorchain-exploit-drains-usd-11m-across-at-least-nine-chains-what-trm-knows-now) and by [THORChain's own report](https://blog.thorchain.org/thorchain-exploit-report-1); the transaction is [`3f21c687...5804`](https://blockstream.info/tx/3f21c6876494e798d51e7f3bc546b5a882e348a9c54250eca8f6b3b2604a5804), timestamped 07:31:47 UTC. A second payment of 3.874 BTC followed the same day. Total at the root: **40.72778438 BTC**.

Follow it downstream and you can report, entirely truthfully, that **256.48 BTC moved**.

Both numbers are correct. One of them is evidence and the other is noise, and the difference is worth understanding, because the second kind shows up in tracing reports that clients pay for.

## What the money actually did
![image-1790029466259](https://cdn.hashnode.com/uploads/covers/69c5b5f710e664c5da415da8/54db2b77-f1c4-4a24-9289-34cc49c05461.png)

The funds went into a peel chain: a line of addresses, each one shaving off a small amount and forwarding the remainder to the next.

Every hop "received" the amount on its line. Add the column up and you get 256.48 BTC. But it is the same coins, counted once per hop - 40.73 BTC walking past eleven windows.

**The overstatement is 6.3x.** Not an estimate, not a rounding difference: a factor of six, produced without writing a single false digit. And it grows with the chain. A fifteen-hop peel would have given a bigger, more impressive, more worthless number.

## Three ways the same figure inflates

**Counting hops as volume.** The one above. The only defensible statement is the amount *at the root*, plus where it went. "Funds moved" and "throughput" are words that quietly license adding hops together.

**Counting an address's own change as inflow.** On a UTXO chain, spending 3 BTC out of a 30 BTC output sends 27 BTC back to yourself. Sum an address's gross receipts and that 27 BTC counts as fresh inflow. We measured a gateway address in a separate case at 12,956 BTC gross inflow, of which 10,712 was its own change - net external inflow 2,244, a 5.8x gap inside one address.

![image-1790029477613](https://cdn.hashnode.com/uploads/covers/69c5b5f710e664c5da415da8/7209a2cc-b46a-470e-bb62-bea06aa9c450.png)

**Counting the peels as separate exits.** This one is visible in the chain above. The eleventh hop received *more* than the tenth, which looks impossible until you check where it came from: `bc1qfy66ek...pwza` took 8.251 BTC from two senders - 4.98 peeled off at hop 8, and 3.271 arriving down the chain from hop 9. The peel did not leave. It rejoined. Treat every peel as an independent outflow and you have double-counted again.

![image-1790029483766](https://cdn.hashnode.com/uploads/covers/69c5b5f710e664c5da415da8/58c23c39-dde6-47eb-9779-0f2c175f8dbb.png)

All three are the same mistake in different clothing: treating a ledger entry as an event rather than asking what actually arrived from outside.

## What honest attribution looks like on the same chain

One address in this trace makes the point. `bc1qsq0kn...atjc` received 4.0 BTC from the exploit - 2.5 directly from the root, 1.5 one hop later. It then spent **10.3 BTC**. The difference came from somewhere else.

Report that address as moving 10.3 BTC of stolen funds and you have overstated its role 2.6x. The defensible figure is its share: the stolen portion of what it forwarded, pro rata on what it actually received from outside.

![image-1790029489620](https://cdn.hashnode.com/uploads/covers/69c5b5f710e664c5da415da8/d8b5a6b0-1235-4587-b01a-e7d52e666752.png)

That rule - *pro rata on net, never gross* - is the difference between a number that survives a hostile reading and one that does not.

## Why this matters outside the analytics

A law firm in Amsterdam, Hupkes c.s. advocaten, [writes on its own website](https://www.hupkesadvocaten.nl/onze-expertise/cryptovaluta/) that victims regularly arrive having already paid for a blockchain tracing report the firm **cannot use in a Dutch court**. The report exists. The client paid. It is unusable.

A 6.3x number is exactly how that happens. It does not fail because someone lied. It fails the first time opposing counsel asks how the figure was built, and the answer is a sum over hops.

What survives that question is narrow and dull: the amount at the root, the route, the share attributable at each mixing point, and a stated method that says where the method stops.

## What we are not claiming

The root address is attributed to this exploit by TRM Labs and by THORChain's own report, and the receipt is on-chain. **Everything below hop 0 is a route, not an identification.** We do not know who controls those addresses, and none of them carries an attribution in our own label database - we checked, and the honest answer is that our attribution does not reach them. An address on the path of stolen funds is not thereby a launderer, a service, or a suspect.

That distinction is not pedantry. It is the reason a document holds up.

## Re-run it

The script that produced every figure here reads Blockstream's public API - no key, no account, no database. It prints every hop and every peel, so the arithmetic can be audited line by line, including the parts where we are wrong.

```bash
curl -sO https://gist.githubusercontent.com/seomarlboro/4704007e8b8e0c861097e9e1113eec8f/raw/trace-peel-chain.py
python3 trace-peel-chain.py bc1ql4u94klk265lnfur2ujk9p6uh52f2a8jhf6f37
```