Interactive instrument

ARC-20 transfer outcome simulator

Enter the inputs of a hypothetical transaction, their satoshi value and any token color they carry, and its outputs. The simulator applies the same coloring rules the indexer applies and explains, step by step, which outputs end up carrying which token balance and when color burns.

Grounding and privacy. The rule engine, assets/simulator.js version 2.0.0, is a port of the fungible token coloring logic in the Bitcoin Universe Atomicals indexer, a fork of atomicals-electrumx (electrumx/lib/atomicals_blueprint_builder.py), using Bitcoin mainnet activation heights. Everything runs locally in your browser and nothing you enter is logged or transmitted. It models token coloring only, not signatures, fees, or mempool policy, and it is not wallet software: verify any real transaction in a compatible wallet before signing.

Fig. 1: the default scenario. A 10000 unit colored input paid into 3000 and 6800 satoshi outputs leaves 200 units in the miner fee, and those units burn. Change the numbers below and run the rules yourself.

This instrument needs JavaScript. The simulator is a progressive enhancement. Every rule it applies is written out on the specification page as rules C1 to C12, and worked through by hand on the test vectors page.

Loading the simulator. If it does not appear, JavaScript is disabled: the rules are written out on the specification page and worked through on the test vectors page.

Rule set

Era, by Bitcoin mainnet activation height

Operation in the witness payload

Inputs

#	Satoshi value	Token id, blank for none	Token units carried	Actions

Use any label as the token id; a ticker works well. Two inputs sharing an id carry the same token. Under current rules an input's token units may be fewer than its satoshis, which is a partially colored UTXO from an earlier transaction.

Outputs

#	Satoshi value	OP_RETURN	Actions

The difference between total input and total output satoshis is the miner fee. OP_RETURN outputs are unspendable and are skipped by regular assignment.

Step by step

What this instrument models

Regular transfer. Tokens are ordered first in, first out by input index, then each colors outputs left to right. Before height 848484 an output was colored only when the remaining token value covered its full satoshi value; from that height the last output may be partially colored and any excess burns.
The non-clean fallback. If a token cannot be placed, every token restarts from output 0, which can stack several tokens onto the same outputs. Rule C7.
Split (y). Each token can skip a declared amount of output satoshis before its coloring begins, which is how two tokens sharing one input UTXO are separated.
Custom color (z). From height 848484 the payload can direct exact token values at exact outputs. Requests are clamped to the output's satoshis and to the remaining balance, and unassigned value burns.
Burns. Whenever token value fails to land on a spendable output, the indexer records it as burned. It never returns.

The written rules, with numbers you can cite, are on the specification page. Worked examples with expected outcomes, including cases transcribed from the indexer's own tests, are on the test vectors page.