Guide

G.1 The lifecycle

Four things happen to a DUST-20 token, in order. Two of them are messages someone writes. Two of them are just Bitcoin.

1. Deploy

Someone inscribes a deploy. It names a ticker, a maximum supply, and the exact satoshis that back one unit. From that moment the ratio is fixed forever, and the first valid deploy of that ticker identity is the one that counts.

2. Mint

Someone inscribes a mint into an output whose value equals the units they are creating multiplied by the fixed ratio. The units now exist, sitting in that output.

3. Hold

Holding units means controlling the unspent output whose satoshis carry them. There is no balance record anywhere on Bitcoin, only an output you can spend.

4. Spend

Sending units means spending those satoshis. The output layout of the transaction you build decides which whole units survive and which are destroyed.

G.2 Reading a deploy

{
  "p": "dust-20",
  "op": "deploy",
  "tick": "dust",
  "supply": "1000000",
  "unit_sats": "546",
  "max_sats": "546000000",
  "lim_sats": "54600"
}

tick

The ticker as written. Its identity is this text in Unicode NFC form, folded to lower case, so DUST and dust are the same ticker and cannot both be deployed.

supply

One million whole units may ever exist. There are no decimals, so a unit is never divided.

unit_sats

Each unit is backed by 546 satoshis, forever. 546 is a common example because it matches the usual Bitcoin dust threshold for a P2WPKH output. It is not a default, and a deploy that omits the field is rejected.

max_sats

1,000,000 x 546 = 546,000,000 satoshis, about 5.46 BTC. This is a redundancy check: if it does not match the exact product the deploy is rejected rather than corrected.

lim_sats

54,600 satoshis per mint, which is 100 units. Optional. Omitting it, or writing "0", means one mint could take the whole supply.

Note what that max_sats figure means in practice. If this ticker is ever fully minted, 5.46 BTC is immobilised inside DUST-20 outputs for as long as people hold the units. Sizing a deployment is a decision about how much bitcoin every future holder has to lock up.

G.3 Reading a mint

{
  "p": "dust-20",
  "op": "mint",
  "tick": "dust",
  "amt": "100",
  "sats": "54600"
}

The mint says: create 100 units of dust, backed by 54,600 satoshis. Three numbers have to agree before a reader will accept it.

{
  "p": "dust-20",
  "op": "deploy",
  "tick": "dust",
  "supply": "1000000",
  "unit_sats": "546",
  "max_sats": "546000000",
  "lim_sats": "54600"
}

{
  "p": "dust-20",
  "op": "deploy",
  "tick": "grain",
  "supply": "21000",
  "unit_sats": "1000",
  "max_sats": "21000000"
}

{
  "p": "dust-20",
  "op": "mint",
  "tick": "dust",
  "amt": "100",
  "sats": "54600"
}

{
  "p": "dust-20",
  "op": "mint",
  "tick": "dust",
  "amt": "1",
  "sats": "546"
}

G.4 Worked transactions

You hold an allocation of 91 units backed at 546 satoshis each, sitting in one output worth 49,686 satoshis. You want to send 10 units to someone.

The safe construction

All 91 units survive: 10 whole blocks of 546 satoshis land inside out[0], and 81 whole blocks land inside out[1].

The construction that destroys 49 units

Same transaction, same intent, one output missing. There is no colored change output, so the 81 units you meant to keep have nowhere to be placed on purpose. Ordinal flow places them anyway, wherever the satoshis happen to land.

49 of 91 units are destroyed, and 32 more end up somewhere you did not plan. Bitcoin confirms this transaction normally. Your wallet shows a successful send. No node, explorer or fee estimator flags anything. Only a DUST-20 reader knows the balance moved. Run both constructions in the allocation simulator to see exactly where the satoshis land.

G.5 Support matrix

What Bitcoin Universe products actually do with DUST-20 today, taken from the capability registry rather than from intent.

Support outside Bitcoin Universe is not claimed here. If a wallet or marketplace says it supports DUST-20, test it against the published vectors before trusting it with a balance, because most of the transfer and burn behaviour on this site is settled by one implementation rather than by an agreed standard.