# 销毁

ARC-20 价值如何被销毁、导致销毁的四种形态，以及分别预防它们的检查。

Page ID: protocol/arc20/burns
Applicability: protocol-behavior
Authority: executed-source
Networks: mainnet
Verified: 2026-08-31
Locale: zh-cn
URL: https://bitcoinuniverseio.github.io/atomicals-and-arc-20/zh-cn/protocol/arc20/burns/

---
销毁指验证器无法放入任何可用输出的着色价值。它会被记录为已销毁。导致销毁的那笔比特币交易是有效的、
被打包并确认的。

被销毁的单位不会去往任何地方。没有地址持有它们，也没有流程能把它们找回。预防是唯一的手段。

## 导致销毁的四种形态

### 1. 下一个输出太大

最常见的一种。还剩 500 个单位待放置，而下一个输出是 546 聪。放不下，于是这 500 个单位被销毁。

**预防。** 把找零输出的大小设为你想保留的余额的精确值。

### 2. 输出不够

所有输出都已填满，价值仍有剩余，已没有地方可放。

**预防。** 当批次超过你要发送的数量时，务必包含一个着色找零输出。

### 3. 第一个输出比整批还大

什么都放不进去，于是整批被销毁。

**预防。** 绝不要把一个小额着色批次送入第一个输出是大额基数支付的交易。

### 4. 回退重排了多代币交易

某个代币无法被干净地放置，于是构建器把所有代币从第零个输出重新开始，另一个代币因此失去了位置。

**预防。** 除非你已经为多代币情形建模，否则每笔交易只移动一个代币。

## 已执行的用例

## 预防这四种情况的检查

1. 在签署之前而不是之后计算预期分配。
2. 确认销毁数量为零。
3. 有意识地以聪为单位设定每个着色输出的大小。
4. 让手续费输入保持基数且相互独立。
5. 除非有理由，否则每笔交易只移动一个代币。
6. 只要输出集合发生变化，包括钱包自动添加的找零，都要重新检查。

第一步和第二步请使用[分配可视化工具](/tools/allocation-visualizer/)。

## 事后发现销毁

验证器按交易记录销毁。通过会报告销毁的数据源读取该交易，并比较着色输入总额与着色输出总额之和。
任何差额都是销毁。

Universe 的 ARC-20 活动数据流会在已确认活动中发布销毁记录。
参见 [ARC-20 API](/reference/api/arc20/)。