全鏈原生資產流轉：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/