Nothing warns you
A transaction that destroys units is a perfectly valid Bitcoin transaction. No node rejects it, no explorer flags it, no fee estimator notices. Only a DUST-20 reader can tell you afterwards.
DUST-20 documentation
Security considerations
What destroys a balance, and what stops it.
- Protocol
- DUST-20Registry id dust20, alias dust-20
- Chain
- BitcoinNetwork: mainnet
- Ownership model
- UTXOUnits are carried by satoshis in unspent outputs
- Carrier
- Inscription + spendDeploy and mint are inscribed; movement is a spend
- Decimals
- 0Balances are whole units only
- Document version
- 1.1.0Revised 2026-09-01
- Lifecycle
- ExperimentalNot a ratified multi-party standard
- Owning repository
- bitcoinuniverseio/dust-20Documentation source of truth
S.1 Threat model
DUST-20 has one property that shapes every risk: the token amount is physically present in the transaction as bitcoin. Anything that happens to those satoshis happens to the units, and Bitcoin will confirm it without complaint.
Confirmation is the end of it
There is no correction message, no burn reversal and no admin key. A mint that is one satoshi wrong is invalid forever. Units that fall into a fee belong to a miner.
Balances are conclusions, not facts
Bitcoin does not know DUST-20 exists. Every balance is one reader's conclusion from applying the rules to the chain, so two readers that differ on a rule will differ on your balance.
Availability is not ownership
A source that answers "still good, yes or no" proves nothing about identity, amount, owner or freshness. This is the recorded reason DUST-20 marketplace mutations are closed in Bitcoin Universe.
S.2 Controls
Ordered by the cost of getting them wrong. The first three are the ones that lose balances.
| Severity | Control | Detail |
|---|---|---|
| CRITICAL | Never share a recovery phrase or private key | No DUST-20 application needs your seed phrase or private key. An app can prepare an unsigned transaction without them. Leave immediately if a site asks for either. |
| CRITICAL | Review every output role before signing | Before the wallet prompt appears you should be able to see the receiver, the units and satoshis going to them, your colored change, the ordinary bitcoin funding the fee, and the fee itself. A list of addresses is not a review. |
| CRITICAL | Missing colored change is a stop sign | If you are sending part of an allocation and no colored change output is present, the remainder does not stay yours in any predictable way: some whole units land in whatever supported output comes next, and the rest are burned. This is not a formatting detail. Do not approve it. |
| HIGH | Keep fee funding separate from colored inputs | Fund the miner fee from ordinary bitcoin. If the fee is taken out of colored backing, the colored range shifts and units can be destroyed even though the transaction confirms. |
| HIGH | Revalidate outputs immediately before building | A selected output may have been spent since the screen loaded. A marketplace listing is discovery data, not proof that an output is still unspent. Re-check at build time, not at page load. |
| HIGH | Treat source disagreement as a blocking error | If two readers describe the same output differently, do not pick the friendlier answer. Show the conflict, block the irreversible step, and keep redacted evidence for investigation. |
| HIGH | Do not downgrade an ambiguous construction to a warning | Unexplained satoshi differences, mixed-ticker selections and unattributable outputs are failures. Silently filling in a field, rounding a satoshi value, or assuming an unspecified payload is valid converts a caught bug into a burned balance. |
| HIGH | Never settle value on an untyped ownership answer | A boolean "still available" response proves nothing about amount, owner, schema or freshness. This is the recorded reason DUST-20 marketplace mutations are unavailable in Bitcoin Universe, and the same reasoning applies to any integration you build. |
| MEDIUM | Never blindly retry an uncertain broadcast | Keep the transaction id and known status. Disable repeat submission until someone has inspected the transaction. A duplicate broadcast can spend the same colored inputs a second way. |
| MEDIUM | Remember that confirmed is not permanent | A reorganization can remove a confirmation and change which transaction actually spent an output. Track confirmation depth and invalidate derived state when the chain moves under you. |
S.3 Before you sign
A wallet prompt showing a list of addresses is not a review. Before approving a DUST-20 transaction you should be able to see every one of these, and stop if you cannot.
| Check | What good looks like | Stop if |
|---|---|---|
| Ticker and amount | The ticker identity and the exact whole-unit amount going to the receiver. |
The amount is fractional, or the ticker is shown in a different case without being resolved to one identity. |
| Colored change | An explicit output for the units you are keeping, sized at least units x unit_sats. |
You are sending part of an allocation and no colored change output exists. |
| Output values | Every colored output value is an exact multiple of unit_sats and matches the units assigned to it. |
Any colored output value changed after the fee was applied. |
| Fee funding | At least one cardinal input, and a fee that comes entirely from cardinal value. |
The fee is subtracted from a colored output, or there is no cardinal input at all. |
| Output order | The order shown is the order that will be broadcast. |
Anything between the review and the broadcast may reorder or re-size outputs. |
| Outpoint freshness | The selected outputs were revalidated at build time, not at page load. |
The screen has been open long enough that an output could have been spent elsewhere. |
| Source agreement | One reader, or several readers that agree, with a stated coverage label and observation height. |
Two sources describe the same output differently. Do not pick the friendlier answer. |
No DUST-20 application needs your seed phrase
An application can prepare an unsigned transaction without any secret. If a site asks for a recovery phrase or a private key, leave. No page on this documentation site asks for a key, builds a transaction, or sends anything you type anywhere.
S.4 Reporting a vulnerability
If you find a flaw in this documentation, in the decoder, or in the DUST-20 rules as published here, report it privately first.
- How to report
Open a private security advisory at github.com/bitcoinuniverseio/dust-20/security/advisories/new. Do not open a public issue and do not post details publicly before a fix is available.
- In scope
A published rule that contradicts the implementation it claims to describe. A decoder result that accepts an invalid payload or rejects a valid one. A test vector with the wrong expected outcome. A worked example whose arithmetic is wrong. Anything on this site that would lead a reader to build a transaction that destroys units.
- Out of scope
Findings about third-party wallets, marketplaces or indexers. Report those to their maintainers. Also out of scope: the fact that DUST-20 permits constructions that burn units, which is documented behaviour rather than a defect.
- Please include
The exact payload or transaction shape, what you expected, what happened, and which numbered rule you believe is wrong. A failing case in the format of the published vectors is the fastest possible report.