全链原生资产流转：Burn-and-Mint 如何重塑跨链供应量安全

问题不在“能不能跨链”，而在供应量是否可审计

跨链资产最危险的错觉，是把“目标链收到一个同名 Token”理解成“原资产已经安全移动”。从账本模型看，资产并不会穿过链之间的物理边界；系统只能在源链减少某种可花费权利，并在目标链增加另一种可花费权利。Wrapped Token、Lock-and-Unlock、Burn-and-Mint 的差异，本质上是这两个动作由谁执行、资产负债表放在哪里、失败时谁承担缺口。

对跨链交换而言，这不是抽象的桥设计偏好。用户在 [AllSwap 跨链交换](/exchange-swap) 中关心的是目标链最终到账资产是否具备可赎回性、报价是否包含真实桥接成本、异常路径是否能退款，以及路由器是否把 wrapped 风险误报成 native 资产。本文用一个供应量不变量模型拆解三类资产原语：Wrapped Token 把风险集中到托管池，Lock-and-Unlock 把风险压到锁仓合约和释放权限，Burn-and-Mint 则把风险转移到发行方、跨链消息证明和铸币权限管理。没有一种模型无条件更安全，只有哪一种失败模式更可观察、更可限流、更容易归因。

系统边界和威胁模型

本文讨论的是可替代资产在多链之间流转，不讨论 NFT 唯一性、订单簿撮合或 CEX 内部账本。系统包含五类角色：资产发行方 `Issuer`，源链合约 `S_i`，目标链合约 `S_j`，跨链消息验证层 `M`，以及执行路由器或 Solver。攻击者可以观察源链事件、延迟或抢跑消息、诱导用户选择错误资产、攻击桥验证层、利用小数精度差异套利，或在某条链重组后尝试重复释放资产。这里不假设攻击者能破解底层签名算法，但假设合约权限、消息验证、运维密钥和链上最终性都可能出错。

核心资产状态可以抽象为四个量：

- `C_i`：第 `i` 条链上可自由流通的 Token 数量； - `L_i`：第 `i` 条链上被锁仓但未释放的 Token 数量； - `B_i`：第 `i` 条链上已销毁、等待目标链铸造的数量； - `P_i`：第 `i` 条链上待处理的跨链消息净额。

如果资产要保持全局一致，至少要满足：

`sum(C_i) + sum(L_i) + pending_liability = canonical_supply`

其中 `pending_liability` 代表已经从源链扣除、但目标链尚未完成 credit 的在途负债。真正的安全问题不是公式本身，而是每个系统是否能在链上或可验证日志中证明这些变量的变化。Wrapped Token 往往只能证明锁仓池余额和 wrapped 发行量的局部关系；Burn-and-Mint 可以把供应量不变量压进发行方授权逻辑；OFT、NTT、CCIP Token Pool 这类框架则试图把 debit/credit 流程标准化，减少每个项目手写桥合约时的错误空间。

还需要区分“会计供应量”和“可兑换供应量”。某条链上合约的 `totalSupply()` 只能说明该合约铸出了多少单位，并不说明这些单位能否回到发行方认可的原生资产。对 wrapped 资产，真实约束是 `wrappedSupply <= reserveBalance - disputedClaims`；对 burn/mint 资产，真实约束是 `mintedByBridge <= burnedOnRemote + approvedPendingAllowance`。如果路由系统只读取目标链 Token 余额，而不理解背后的储备或授权模型，就会把可交易性误认为可赎回性。

三种资产原语的状态机

Wrapped Token 的典型状态机是 `lock -> attest -> mint wrapped -> burn wrapped -> release`。源链资产进入桥托管池，目标链发行一个表示债权的 wrapped 资产。优点是无需原 Token 支持跨链铸毁，缺点是托管池成为高价值攻击面。只要锁仓证明、验证者集、升级权限或释放逻辑被破坏，wrapped 资产就可能超发，或原资产被盗后失去兑付基础。2022 年桥攻击集中爆发的根因之一，就是桥合约和验证层同时承载了大量锁仓资产与复杂跨链逻辑。

Lock-and-Unlock 看起来更克制：源链锁定，目标链释放已有库存；反向时目标链锁定，源链释放。它适合已有 Token 无法授权外部合约铸造和销毁的场景。LayerZero OFT Adapter 和部分 CCIP Token Pool 都支持这种路径。但 Lock-and-Unlock 有库存管理问题：目标链必须有可释放余额，且锁仓池和释放池之间必须有容量规划。LayerZero 文档明确强调不能随意组合 debit lock 与 credit unlock，因为锁在 OFT 合约内部的资产并不能天然保证另一端有足够释放库存。

Burn-and-Mint 的状态机是 `burn -> attest -> mint`。源链资产被销毁或永久退出流通，目标链在验证消息后铸造等量资产。Circle CCTP 对 USDC 的核心路径就是这种 burn-and-mint：源链 burn，Circle Iris 签署消息，目标链 `receiveMessage` 后 mint。ERC-7802 也把跨链 Token 的最小接口收敛到 `crosschainMint` 和 `crosschainBurn`。它的优势是没有一个长期堆积的托管池，供应量更容易用发行方权限和消息 nonce 约束；代价是铸币权限本身变成最高敏感面，发行方或授权桥必须正确处理最终性、重放、限流和权限撤销。

可以把三种模型的工程取舍写成一句话：Wrapped Token 把风险放在“储备是否还在”，Lock-and-Unlock 把风险放在“库存是否匹配”，Burn-and-Mint 把风险放在“铸毁权限是否被正确约束”。跨链路由系统不能只比较手续费和速度，还必须把这三类风险作为报价质量的一部分。

这个判断会直接影响路径选择。例如同样是把 USDC 从以太坊送到某条 L2，路径 A 可能通过 CCTP 生成目标链原生 USDC，路径 B 可能通过某桥 wrapped USDC 再在目标链 DEX 里兑换，路径 C 可能依赖目标链流动性提供者先行垫付再异步再平衡。三条路径在用户界面上都能显示“收到 USDC”，但它们的失败面完全不同：A 的关键是 attestation 与 mint 权限，B 的关键是桥储备和 DEX 深度，C 的关键是 Solver 信用和补库存能力。

供应量不变量如何在工程中落地

一个跨链 Token 系统至少要维护三类不变量。

第一，守恒不变量。若一次转账金额为 `a`，源链必须先完成 `debit(a)`，目标链才能执行 `credit(a')`。在相同小数精度下应有 `a' = a`；在不同精度下必须有明确的舍入规则。Chainlink CCIP Token Pool 文档特别指出，不同链小数位不一致会造成精度损失，旧版本还存在不同 decimals 支持限制。这个细节听起来小，但在大额、频繁、自动化路由里会变成真实损失。如果路由器没有把 `a - a'` 作为成本暴露给用户，报价就是不完整的。

第二，唯一性不变量。每条跨链消息只能执行一次。工程上通常依赖 `(sourceDomain, destinationDomain, nonce, sender, recipient, amount)` 的哈希作为消息 ID，并在目标链记录已消费状态。Wormhole NTT 的 on-chain state 包含消息 attestations、peer registrations、rate limiting 和 transceiver registry，其目的就是防止未经授权的 peer 或重复消息触发 mint/unlock。CCTP 的 MessageTransmitter 也围绕消息发送、证明签署和目标链接收构建，避免同一 burn 被多次兑换成目标链铸币。

第三，权限不变量。能 mint 的主体必须是最小集合，并且每个主体都应有链、Token、额度和时间窗口边界。Burn-and-Mint 不应该被实现成“桥拥有无限铸币权”。更合理的模型是：每条链配置远端 peer，跨链消息带有 domain 约束，Token Pool 或 minter 维护速率限制，异常时能暂停单条路径而不是冻结全网资产。Wormhole NTT 的 rate limit 和可定制 transceiver、CCIP 的标准 Token Pool、CCTP 的 attestation 服务，都是围绕这个问题做工程约束。

第四，观测不变量。系统必须能回答三类运维问题：哪些 burn 已经最终确认但还没有 mint，哪些 lock 已经进入目标链队列但还没有 release，哪些消息因为限流、小数转换、gas 不足或 peer 配置失败而挂起。缺少这些索引，用户看到的只是“处理中”；协议团队看到的也只是跨链消息池里的一堆事件。成熟的跨链资产系统应把 `pending`, `credited`, `refunded`, `expired`, `challenged` 作为一等状态，而不是依赖离线客服解释。

一个可执行级 debit/credit 模型

跨链资产转移可以压缩成以下状态机：

1. `quote(route, amount)`：路由器读取目标链资产类型、桥接模式、费用、最终性窗口和精度损失。 2. `debit(source, amount)`：源链执行 lock 或 burn，并生成事件 `E`。 3. `finalize(E)`：等待源链达到协议要求的确认或最终性。 4. `attest(E)`：消息验证层对事件、nonce、链 ID、金额、接收者和 Token 进行签名或证明。 5. `credit(destination, proof)`：目标链验证证明，检查未消费 nonce，执行 mint 或 unlock。 6. `settle_or_refund()`：若超过超时窗口未 credit，则进入退款、重试或人工复核路径。

伪代码可以更直接：

`if consumed[msgId] == true: revert`

`if amountAfterDecimals == 0: revert`

`if !trustedPeer[sourceDomain][sender]: revert`

`if rateLimitExceeded(token, sourceDomain, amount): queue_or_revert`

`consumed[msgId] = true`

`credit(recipient, amountAfterDecimals)`

这个模型的关键不是代码语法，而是操作顺序。`consumed[msgId]` 必须在外部可重入路径前设置；小数转换必须在 mint/unlock 前完成；rate limit 应该覆盖入站和出站；peer 校验必须绑定源链 domain 和远端合约地址。否则，系统可能在单元测试中通过，却在跨链重试、链重组、目标链失败回调或不同 VM 地址格式中暴露漏洞。

退款状态机同样需要显式建模。对 lock/unlock，退款可以是源链 unlock，因为资产仍在托管池中；对 burn/mint，源链资产已经销毁，退款通常不能简单回滚，需要目标链 mint 失败证明、发行方补偿铸造，或在同一发行体系内重新发起反向 mint。换句话说，burn/mint 降低了长期储备池风险，却提高了 pending liability 的处理要求。路由器在展示预计到账时间时，应同时展示超时后的处理路径，而不只是给出一个乐观 ETA。

Wrapped、Lock/Unlock、Burn/Mint 的失败模式

Wrapped Token 的第一类失败是储备失真。锁仓池被盗、管理员误释放、验证者集被接管，都会让目标链 wrapped 资产变成无抵押债权。第二类失败是资产碎片化：同一个原生资产可能存在多个桥发行的 wrapped 版本，流动性分散，路由器必须识别 `USDC.e`、`USDC`、`axlUSDC`、`wormhole USDC` 之间的真实兑换关系。第三类失败是赎回路径中断：目标链 wrapped 资产仍能交易，但回到原链的 release 可能已暂停。

Lock-and-Unlock 的主要失败是库存错配。某条链的释放池被耗尽时，用户的跨链请求可能进入排队，报价中的“可用流动性”就不等于链上可释放余额。第二类失败是锁仓死角：源链 lock 成功，目标链由于 gas、peer 配置、rate limit 或消息验证失败没有 release，系统必须能证明用户仍有可退款权利。第三类失败是组合路径过度复杂：多跳 lock/unlock 会把每个中间池的库存风险叠加，而不是抵消。

Burn-and-Mint 的失败更集中在权限和最终性。若源链 burn 事件在未最终确认时被目标链采纳，源链重组可能让 burn 消失，而目标链已经 mint。若 minter 权限被错误授予，攻击者不需要偷锁仓资产，直接 mint 就能破坏总供应量。若 decimals 转换、fee-on-transfer 或 rebasing 逻辑没有用 shares 而是用 nominal amount，目标链铸造数量也可能偏离真实经济价值。CCIP 文档对 rebasing、fee-on-transfer 和 decimals 的定制池提醒，正是因为通用 ERC-20 假设并不覆盖这些资产。

动态限流不是 UX 妥协，而是供应量防火墙

很多跨链产品把限流视为影响体验的保守设置。但从资产不变量角度看，rate limit 是防止错误快速扩散的断路器。假设某条路径的验证层出现错误，若没有限流，攻击者可以在短时间内把错误证明兑换成大量目标链资产；若每个 `(token, sourceDomain, destinationDomain)` 都有容量和 refill rate，损失上界就从“全局供应量”下降到“窗口额度”。

更细的工程实现应同时限制三件事：单笔最大额度、时间窗口总额度、未完成在途净额。对无托管跨链交换而言，路由器也应该把限流状态纳入报价。如果某条 Burn-and-Mint 路径处于排队状态，而另一路径虽然费用更高但有即时可用库存，最优路由不再是静态手续费最小，而是用户目标函数下的风险调整最优。这也是 [AllSwap 费用](/fees) 和路由说明需要表达清楚的地方：用户支付的不只是 gas，还包括目标链执行、消息验证、库存可用性和失败恢复的成本。

监控层可以用几个简单但有效的指标约束风险：每条路径的 `pending_notional`，单个 domain 的 `mint_velocity`，锁仓池的 `reserve_coverage_ratio`，目标链失败执行率，以及超过最终性窗口仍未 credit 的消息数量。这些指标不需要暴露复杂内部实现，但可以进入路由权重。对大额交易，系统甚至可以主动避开 pending_notional 过高的路径，因为同一时间窗口内的在途负债越高，任何验证层故障造成的损失半径越大。

AllSwap 路由应该如何看待“native”和“wrapped”

在用户界面里，“USDC 到 USDC”很容易被误解成同一种资产的空间移动。但协议工程上，路由器必须区分至少四种资产语义：原生发行资产、发行方授权的 burn/mint 资产、单桥 wrapped 资产、多桥竞争 wrapped 资产。只有第一种和第二种通常能给用户较强的赎回确定性；第三种依赖桥储备；第四种还叠加了流动性碎片和价格偏离。

对 AllSwap 这类跨链交换入口，更合理的做法是把资产语义嵌入路由评分，而不是只在详情页解释。评分可以包含：

- 资产是否由发行方原生支持或授权； - 目标链 Token 合约是否为 canonical 合约； - 当前路径是 burn/mint、lock/unlock 还是 wrapped swap； - 目标链可用库存、rate limit 和 pending queue； - 过去失败路径是否有明确退款证明； - 用户实际收到资产能否被主流 DeFi 和钱包识别。

这不会把产品写成桥审计工具，但能避免错误承诺。比如 ERC20 USDT、USDC、TRX 这类常用资产在不同链上的语义并不相同；用户通过 [/swap/usdt-erc20](/swap/usdt-erc20)、[/assets/usdc](/assets/usdc) 或其他链资产页进入时，路由系统应尽量把“同名资产”与“同一风险资产”区分开。

更进一步，路由器可以把输出资产分成“canonical preferred”“issuer-authorized”“bridge-wrapped”“synthetic or routed”几个等级。用户不一定需要阅读所有底层证明，但应该能知道自己为了更低费用或更快速度，是否接受了更弱的资产语义。专业用户会关心这件事，因为他们拿到目标链资产后还要进入借贷、做市或清算系统；如果协议只接受 canonical USDC，而路由输出的是某桥 wrapped USDC，表面到账并不等于任务完成。

开放问题：跨链资产安全还没有收敛

第一，发行方授权和开放互操作之间仍有张力。CCTP 这类发行方路径可以降低 wrapped 托管池风险，但也把信任集中到发行方 attestation 和 minter 权限。完全开放的桥更可组合，但更难统一供应量审计。

第二，跨链标准仍在碎片化。ERC-7802 试图标准化 crosschain mint/burn 接口，LayerZero OFT、Wormhole NTT、CCIP Token Pool 也各自定义了管理器、池和消息验证路径。路由器要同时理解这些语义，否则无法做精确风险评分。

第三，链重组和异构最终性仍然是 burn/mint 的硬边界。以太坊、Solana、Aptos、Sui、Cosmos appchain 的最终性语义不同，统一“等待 N 个确认”不是严谨模型。跨链资产系统需要把最终性窗口作为 Token 风险参数，而不是桥的隐藏配置。

第四，小数精度、rebasing、fee-on-transfer、黑名单和暂停权限会破坏简单守恒公式。真实资产不是理想 ERC-20，供应量不变量必须以 shares、净额或发行方账本为准。

第五，失败退款的用户体验还没有标准化。源链已 burn 的资产无法简单“撤销”；目标链未 mint 时，用户需要的是可验证的 pending claim、重试机制或补偿路径。没有这层设计，burn/mint 只是把风险从托管池换成了在途负债。

References

[1] Circle CCTP Documentation, Circle, 2026, https://developers.circle.com/cctp

[2] CCTP Technical Guide, Circle, 2026, https://developers.circle.com/cctp/references/technical-guide

[3] CCTP Supported Blockchains and Domains, Circle, 2026, https://developers.circle.com/cctp/concepts/supported-chains-and-domains

[4] Omnichain Fungible Token Standard, LayerZero, 2026, https://docs.layerzero.network/v2/concepts/applications/oft-standard

[5] Value Transfer Implementations, LayerZero, 2026, https://docs.layerzero.network/v2/concepts/value-transfer-implementations

[6] Native Token Transfers Architecture, Wormhole, 2026, https://wormhole.com/docs/products/token-transfers/native-token-transfers/concepts/architecture/

[7] Cross-Chain Token Standard Token Pools, Chainlink CCIP, 2026, https://docs.chain.link/ccip/concepts/cross-chain-token/evm/token-pools

[8] ERC-7802 Token With Mint/Burn Access Across Chains, Ethereum Improvement Proposals, 2024, https://eips.ethereum.org/EIPS/eip-7802

[9] Cross-Chain Bridge Hacks Emerge as Top Security Risk, Chainalysis, 2022, https://www.chainalysis.com/blog/cross-chain-bridge-hacks-2022/