Burns

A burn is coloured value that a validator could not place in any eligible output. It is recorded as destroyed. The Bitcoin transaction that caused it is valid, mined, and confirmed.

There is no recovery

Burned units do not go anywhere. There is no address that holds them and no procedure that returns them. Prevention is the only control.

How coloured value is destroyed. A coloured input of 1200 satoshis is spent. Output zero is 700 satoshis and receives 700 units. The next eligible output is 546 satoshis, which is larger than the 500 units still to place, so it receives nothing and those 500 units are recorded as burned. The Bitcoin transaction is valid and confirms. Making output one 500 satoshis instead would have placed all the value cleanly.

How coloured value is destroyed

A coloured input of 1200 satoshis is spent. Output zero is 700 satoshis and receives 700 units. The next eligible output is 546 satoshis, which is larger than the 500 units still to place, so it receives nothing and those 500 units are recorded as burned. The Bitcoin transaction is valid and confirms. Making output one 500 satoshis instead would have placed all the value cleanly.

The four shapes that cause a burn

1. The next output is too large

The most common. You have 500 units left to place and the next output is 546 satoshis. It does not fit, so the 500 units are destroyed.

Prevention. Size the change output to exactly the remainder you intend to keep.

2. There are not enough outputs

Every output was covered and value is still left. Nothing remains to place it in.

Prevention. Always include a coloured change output when the inputs exceed what you are sending.

3. The first output is larger than the whole lot

Nothing can be placed at all, so the entire lot burns.

Prevention. Never send a small coloured lot into a transaction whose first output is a large cardinal payment.

4. The fallback rearranged a multi token transaction

One token could not be placed cleanly, so the builder restarted every token from output zero and a different token lost its slot.

Prevention. Move one token per transaction unless you have modelled the multi token case.

Executed cases

Executed ARC-20 allocation vectors from conformance/vectors/arc20-allocation.json

Case	Coloured inputs	Result per output	Burned	Clean
Oversized next output burns the remainder oversized-next-output	1200 units at input 0	out 0: 700 sats to 700 units; out 1: 546 sats to 0 units	500 units of TOKENA	no
Outputs run out before the value does too-few-outputs	1200 units at input 0	out 0: 700 sats to 700 units	500 units of TOKENA	no
First output larger than the whole lot first-output-too-large	500 units at input 0	out 0: 20000 sats to 0 units	500 units of TOKENA	no
A change output larger than the remainder burns it change-output-too-large	1200 units at input 0	out 0: 1000 sats to 1000 units; out 1: 546 sats to 0 units	200 units of TOKENA	no
A non-clean slot triggers the output zero fallback two-tokens-non-clean-fallback	700 units at input 0, 400 units at input 1	out 0: 700 sats to 700 units; out 1: 546 sats to 0 units	400 units of TOKENB	no

The checks that prevent all four

1. Compute the expected assignment before signing, not after.
2. Confirm the burn figure is zero.
3. Size every coloured output deliberately, in satoshis.
4. Keep fee inputs cardinal and separate.
5. Move one token per transaction unless you have a reason not to.
6. Re-check after any change to the output set, including a wallet adding change.

Use the allocation visualizer to do steps one and two.

Detecting a burn after the fact

A validator records burns per transaction. Read the transaction through a source that reports them, and compare the coloured input total against the sum of coloured output totals. Any difference is a burn.

The Universe ARC-20 activity feed publishes burn records among its confirmed activity. See ARC-20 API.