Glossary and FAQ

The smallest unit of Bitcoin, one hundred-millionth of a bitcoin. Satoshis are indivisible, which is why every DUST-20 amount is a whole number.

A Bitcoin output so small that nodes will not relay it, because spending it would cost more in fees than it is worth. The usual threshold for a common output type is 546 satoshis, which is why that number appears throughout DUST-20 examples.

An unspent transaction output: a discrete piece of bitcoin with an amount and an owner. Bitcoin has no account balances; a wallet balance is the sum of its UTXOs.

The address of a specific output, written as a transaction id and an output index, such as txid:0. It is how an allocation is identified.

An output whose satoshis an indexer interprets as carrying token units. Bitcoin itself sees an ordinary output; the colour exists only in the interpretation.

An ordinary bitcoin input carrying no token allocation. Cardinal inputs are what you use to pay miner fees without disturbing colored satoshis.

The satoshis that stand behind a quantity of units, equal to units × unit_sats. Backing is not a price, it is the physical space the units occupy in a transaction.

The number of satoshis that back one unit, fixed at deploy time and unchangeable afterwards. Every later calculation depends on it.

The inscription that creates a ticker and fixes its supply and satoshi backing rule.

The inscription that creates units, in an output whose value equals the declared satoshi backing exactly.

The output that receives the units you did not send. Omitting it does not keep those units, it burns them.

An indexer’s record that a specific span of satoshis inside a specific output represents a number of units of a ticker.

Where an allocation begins inside its output, measured in satoshis from the start of that output. Without the offset, the next spend cannot be computed.

The first-in-first-out rule that decides which satoshis in the outputs correspond to which satoshis in the inputs. DUST-20 uses it to follow units through a spend.

The destruction of units, caused by their satoshis being paid as fees, sent somewhere unattributable, or split so that no whole unit fits in an output. There is no burn message.

The waiting area for broadcast but unconfirmed transactions. DUST-20 mempool coverage is partial, so unconfirmed state is not a safe basis for an irreversible decision.

Replace-by-fee: resubmitting a transaction with a higher fee. Because the replacement can have a different output layout, it can burn units the original would have preserved.

A chain reorganization, where confirmed blocks are replaced by a different branch. An indexer must roll allocations back and replay the new branch.

A partially signed Bitcoin transaction: the unsigned transaction your wallet shows you before you approve it. It is your last chance to check every output role.

No. 546 is the most common example because it matches Bitcoin’s usual dust threshold, but unit_sats is whatever the deploy declares. Never assume 546 when a payload omits the field, because omitting it makes the deploy invalid.

Because the satoshis themselves carry the units. Spending them moves the units, so a separate message would be redundant and could disagree with the transaction that actually happened. The current implementation rejects any op: "transfer" inscription.

The units you meant to keep are burned. Bitcoin will confirm the transaction normally and nothing warns you. This is the single most expensive mistake in DUST-20.

No. Satoshis that go to the fee are gone, and any units they carried are burned. Always add a separate ordinary bitcoin input to fund the fee.

No. Balances have zero decimal places, and a unit only survives a spend if its whole block of unit_sats satoshis lands inside one output.

The first valid deployment wins. Tickers are compared after Unicode NFC normalization and lower-case folding, so "DUST" and "dust" are the same ticker.

It is one service’s interpretation of Bitcoin, not consensus. Check its source, coverage and observation height, and treat disagreement between two indexers as a blocking error rather than a choice.

No. It documents the legacy DUST-20 specification and the behaviour of the Bitcoin Universe production indexer, labelling every statement with which of the two supports it. Where they disagree or nothing settles a question, that is stated rather than resolved by guesswork.