模組化流動性層：虛擬餘額如何壓縮跨 Rollup 結算風險

流動性層解決的不是“跨鏈更快”，而是庫存更少暴露

模組化流動性層（Modular Liquidity Layer）的核心價值，不是讓資產真的以更高頻率在 Rollup 之間移動，而是把大量使用者級跨鏈轉賬壓縮成少量淨額結算。使用者看到的是從 A 鏈到 B 鏈的交換；系統內部更接近一個多邊清算網路：Solver、做市商或流動性節點先在目標鏈墊付資產，清算層記錄每條鏈上的虛擬餘額（Virtual Balance），等風險視窗結束後再進行淨額再平衡。

這類架構對 [AllSwap 跨鏈交換](/exchange-swap) 很關鍵。無託管路由的難點並不只是找到最低報價，而是判斷某條路徑在目標 Rollup 停機、來源鏈重組、Solver 庫存不足或訊息延遲時，能否把失敗狀態變成可驗證退款。虛擬餘額減少了頻繁橋接，但它也引入新的賬本一致性問題：誰欠誰、欠多少、在哪條鏈上結算、何時進入壞賬隔離，都必須有可審計狀態。

本文討論的不是中心化交易所內部賬本，也不是簡單多籤橋。系統邊界是：多條 L1/L2、一個或多個 Solver、一個清算層、若干橋或訊息協議、以及使用者提交的跨鏈 intent。目標不是承諾“即時跨鏈最終性”，而是給出一個工程上可落地的模型：虛擬餘額如何降低跨鏈庫存佔用，又怎樣防止雙花、壞賬和非同步結算失控。

系統模型：真實資產少動，債務狀態多動

設系統接入鏈集合為 `C = {c_1, c_2, ... c_n}`，資產集合為 `A`，每個 Solver `s` 在鏈 `c` 上有真實庫存 `I[s,c,a]`，清算層維護虛擬餘額 `V[s,c,a]`。使用者從 `c_i` 向 `c_j` 交換資產時，路徑通常包含四個步驟：

1. 使用者在來源鏈鎖定、燃燒或轉出資產； 2. Solver 在目標鏈用本地庫存向使用者付款； 3. 清算層記錄 Solver 在來源鏈應收、在目標鏈應付的虛擬餘額變化； 4. 週期性結算時，對多條鏈、多名 Solver 的債權債務做淨額軋差。

最小不變數可以寫成：

`sum_c I[*,c,a] + pendingIn[a] - pendingOut[a] = escrowed[a]`

對單個 Solver 的風險敞口則可寫成：

`exposure[s,a] = max(0, sum_c -V[s,c,a]) + unsettledClaims[s,a]`

其中 `pendingIn` 是已在來源鏈發生但尚未被清算層確認的入賬，`pendingOut` 是已在目標鏈墊付但尚未最終結算的出賬。若只看使用者 UI，跨鏈交換像是一筆交易；若看清算層，它其實是一個帶時間戳、序列號和證明依賴的債務狀態轉移。

這也是虛擬餘額的本質：它不是憑空創造流動性，而是把“每筆跨鏈都搬資產”改成“先用本地庫存履約，再用淨額結算修正庫存分佈”。系統節省的是橋接頻率、Gas、等待時間和資本碎片化；付出的代價是更復雜的風險控制、仲裁和壞賬隔離。

還需要區分“餘額”和“償付能力”。`V[s,c,a]` 為正，只代表 Solver 在某條鏈或某個清算週期內有應收權，並不代表它在目標鏈有足夠庫存繼續填單。相反，某個 Solver 的全域性虛擬餘額可能接近平衡，但它的真實 USDC 全部集中在 Base，Arbitrum 上已經沒有可用庫存。路由器如果只看全域性淨額，會錯誤地認為路徑仍然健康。更合理的模型是同時維護三層賬：真實庫存、虛擬債權債務、可用於下一筆訂單的熱庫存。三者不一致時，應以最保守的那一層約束報價。

Intent、Solver 與清算層的職責不能混在一起

跨鏈 intent 協議通常把使用者目標表達為約束：給定輸入資產、輸出資產、最小到帳、截止時間、接收地址和允許路徑，任何滿足約束的 Solver 都可以執行。ERC-7683 正在把這類跨鏈訂單的基本介面標準化，Across、UniswapX 和同類設計也都圍繞“使用者給目標，執行者競爭填單”展開。

但 intent 層只解決“誰來執行”和“執行條件是什麼”。模組化流動性層還要解決三個更低階的問題。

第一，庫存歸屬。Solver 在目標鏈墊付的是自己的真實資產，不是使用者尚未跨過來的同一枚資產。清算層必須記錄這筆墊付對應的可索賠權。

第二，結算順序。來源鏈事件、目標鏈付款、訊息確認、證明提交和最終淨額清算不是同一時間發生。系統必須知道哪一個狀態已經最終，哪一個只是樂觀可撤回。

第三，風險隔離。當某個 Rollup 宕機或橋暫停時，系統不能讓該鏈上的未結算債務繼續汙染其他鏈的餘額。否則一個接入鏈故障會擴散成全域性流動性危機。

因此，良好的模組化流動性層應把元件拆開：intent 合約驗證使用者約束，Solver 網路負責履約競爭，訊息/橋協議傳遞狀態證明，清算層維護虛擬餘額和淨額結算，風險模組執行限額、暫停和隔離。把這些職責混在一個“跨鏈路由器”裡，短期實現簡單，長期很難審計。

職責拆分還有一個現實原因：不同元件的作惡證據不同。使用者訂單違約可以由訂單約束和目標鏈交易證明判斷；訊息協議延遲需要檢視來源鏈最終性和 relayer 狀態；Solver 是否惡意拒絕履約，需要比較它的報價承諾、目標鏈庫存和截止時間；清算層是否錯誤記賬，則要檢查索賠 proof 與虛擬餘額更新。若所有邏輯都摺疊在同一個合約或後端裡，事後只能看到“交易失敗”，無法把責任歸因到訂單、執行、證明、清算或鏈級故障。

虛擬餘額的狀態機

一個跨 Rollup 交換可以建模為狀態機：

- `Quoted`：路由器給出報價，尚未佔用庫存； - `LockedOnSource`：使用者輸入已在來源鏈鎖定或轉出； - `FilledOnDestination`：Solver 已在目標鏈付款； - `ClaimOpened`：Solver 向清算層提交索賠； - `ClaimVerified`：來源鏈事件、目標鏈付款和訂單約束透過驗證； - `NettingReady`：進入軋差批次； - `Settled`：真實資產或跨鏈信用完成結算； - `Quarantined`：相關鏈或訊息路徑異常，債務被凍結； - `Refunded`：未履約或超時後，使用者拿回來源鏈資產。

關鍵轉移可以用虛擬碼表達：

`onFill(orderId, solver, dstTx): require(output >= minOut && now < deadline)`

`openClaim(orderId): require(sourceLockFinal && destinationFillObserved)`

`verifyClaim(orderId): require(!claimed[orderId] && proofBinds(orderId, src, dst, receiver))`

`V[solver, src, assetIn] += amountIn`

`V[solver, dst, assetOut] -= amountOut`

`claimed[orderId] = true`

這個模型裡，`claimed[orderId]` 與跨鏈 proof 繫結非常重要。若只按使用者地址和金額記賬，攻擊者可能用同一筆來源鏈鎖定事件在多個目標鏈重複開啟索賠。若只按目標鏈付款記賬，Solver 也可能在來源鏈事件最終失敗時獲得不應得的債權。訂單 ID、來源鏈事件、目標鏈付款、接收地址、資產 ID 和截止時間必須共同構成不可重放的結算鍵。

序列號和併發鎖：防止跨鏈雙花

虛擬餘額系統最大的危險，是多個非同步觀察者對同一筆狀態作出不同解釋。來源鏈可能已經發生重組，目標鏈已經付款；或者兩個 Solver 幾乎同時填同一筆訂單；又或者使用者在多個前端提交等價 intent，試圖利用訊息延遲獲得重複填單。

最低限度的防線是序列號。每個 `orderId` 必須單調唯一，每個 Solver 的清算賬戶也應有 `settlementNonce`。清算層處理索賠時，不僅檢查 proof 是否有效，還檢查該 proof 是否是當前序列中唯一可接受事件：

`accept(claim) iff claim.seq gt lastSeq[path] && !spent[orderId] && finality(srcEvent) ge threshold`

這裡的 `path` 可以是 `(srcChain, dstChain, asset, messageProtocol)`。對高價值路徑，系統不能只看“交易已包含”，而要等待更強最終性。例如 Circle CCTP V2 區分不同 finality threshold，IBC packet 有明確 timeout 語義，以太坊 L2 還要考慮挑戰期、證明延遲或強制退出路徑。最終性不是抽象詞，它直接決定 Solver 能否安全把庫存從“可用”變成“已佔用”。

併發鎖也不能太粗。若對整個資產或整個鏈加全域性鎖，系統在熱點資產上會退化為單執行緒；若鎖太細，只鎖使用者地址，又會漏掉同一訂單的多 Solver 競爭。更實用的鎖粒度是 `orderId + path + asset`，再疊加 Solver 級信用額度。這樣同一資產的不同訂單可以併發，但同一訂單不能被重複索賠。

保證金設計應跟鎖粒度一致。若 Solver 的保證金只按全域性賬戶計算，某條高風險路徑的損失可能吞噬其他低風險路徑的償付能力；若每條路徑都要求獨立全額保證金，資本效率又會回到逐筆橋接的水平。折中做法是按資產和路徑給出風險權重：穩定幣主流 Rollup 路徑的保證金折扣較低，長尾資產、新 Rollup、弱訊息路徑或高波動期間的保證金折扣較高。這樣系統不是簡單說“某個 Solver 好或壞”，而是精確限制它在某條鏈、某個資產、某個結算視窗中的最大負餘額。

淨額清算降低成本，也放大尾部風險

淨額清算的收益很明確。假設一天內有大量使用者從 Arbitrum 到 Base，也有大量使用者從 Base 到 Arbitrum。逐筆橋接會產生兩邊都很高的訊息成本和等待成本；淨額清算只需要結算差額：

`net[c_i,c_j,a] = grossOut[c_i,c_j,a] - grossOut[c_j,c_i,a]`

如果兩個方向流量接近平衡，真實跨鏈再平衡可以大幅減少。Across、Everclear 等 intent/clearing 設計都在不同層面利用了這種思想：使用者訂單由填單者快速履約，系統後續再處理償付、索賠和淨額。

但淨額清算會把風險從單筆交易轉移到批次尾部。批次越長，資金效率越高，未結算敞口越大；批次越短，風險越低，結算成本越接近逐筆橋接。不存在免費的最優點，只有風險偏好的選擇。

可以用三個維度理解取捨：

- 短批次：壞賬視窗小，Gas 成本高，適合高波動或新接入鏈； - 長批次：資本效率高，尾部風險大，適合高流動性、最終性穩定的路徑； - 動態批次：按波動率、鏈健康度、Solver 保證金和訊息延遲調整視窗，實現複雜但更接近真實風險。

對 AllSwap 來說，報價不應只比較 `priceScore` 和 `speedScore`。更合理的是：

`routeScore = priceScore + speedScore - inventoryRisk - settlementLag - quarantinePenalty`

其中 `inventoryRisk` 來自 Solver 目標鏈庫存和保證金，`settlementLag` 來自來源鏈最終性與訊息證明延遲，`quarantinePenalty` 來自目標鏈進入暫停或逃生狀態的機率。

淨額批次還需要可審計的邊界。一個批次應包含開始高度、結束高度、訂單集合根、索賠集合根、每個 Solver 的餘額變化和再平衡動作。若批次只給出最終數字，外部觀察者無法判斷某個 Solver 的負餘額是來自真實填單、重複索賠、手續費調整還是人工修正。更穩健的方式是把批次寫成可重放日誌：任何人拿到來源鏈事件、目標鏈付款證明和訂單承諾，都能重新計算 `deltaV`，並得到同一個淨額結果。這樣清算層即使鏈下計算，也不會退化成不可審計賬本。

宕機、硬分叉與風險隔離

模組化流動性層必須假設接入鏈會出問題。Rollup 可能暫停排序器，橋可能停止接收訊息，證明系統可能延遲，鏈也可能發生深度重組或硬分叉。

第一類失敗是目標鏈付款成功但來源鏈事件失敗。Solver 已經把資產發給使用者，但來源鏈鎖定事件被重組或沒有達到最終性。防禦方式是按資產和鏈設定 finality threshold；低價值小額路徑可以接受較短視窗，高價值路徑必須等待更強確認。

第二類失敗是來源鏈鎖定成功但目標鏈未付款。使用者資金被來源鏈合約佔用，目標鏈沒有到帳。系統需要明確 refund path：超時後使用者能否在來源鏈取回，還是必須等待 Solver 或清算層仲裁。

第三類失敗是清算層自身延遲。使用者已完成交換，Solver 卻遲遲不能取回來源鏈債權。長期看，Solver 會提高報價或退出流動性。路由器若忽略這點，會把風險以更差價格轉嫁給後續使用者。

第四類失敗是鏈級隔離。某個接入 Rollup 進入凍結、逃生或分叉爭議狀態時，清算層應把該鏈的 `V[*,c,*]` 標記為 quarantined，只允許降低風險的動作：退款、撤銷未填訂單、減少敞口、提交證明，不允許繼續放大負餘額。

風險隔離的狀態機應是單調的。進入 `Quarantined` 後，不能由單一運營方隨意恢復；恢復條件至少應包含鏈最終性恢復、訊息協議恢復、未結算索賠重新驗證，以及 Solver 敞口重新計算。否則暫停按鈕會變成管理許可權風險，而不是安全機制。

隔離期間還要處理價格風險。假設 Solver 在目標鏈已支付 USDC，但來源鏈輸入是 ETH 或長尾資產，隔離視窗內資產價格可能大幅移動。若系統按原始報價結算，Solver 可能承擔非預期價格敞口；若按恢復時價格重算，使用者可能被事後改價。更清晰的邊界是：訂單執行價在填單時鎖定，價格風險由報價方承擔；協議只負責證明訂單是否滿足約束、索賠是否有效、退款是否到期。不要把價格再談判塞進隔離恢復，否則清算層會變成仲裁市場。

AllSwap 路由應把清算風險顯式定價

AllSwap 的使用者不需要理解虛擬餘額賬本，但路由系統需要理解。一個看似便宜的跨鏈報價，可能只是因為 Solver 暫時忽略了目標鏈庫存風險；一個稍貴的報價，可能包含更短 settlement window、更強最終性確認和可證明 refund path。

路由層至少應維護五類訊號：

- `inventoryDepth`：目標鏈可立即墊付的真實資產； - `netExposure`：Solver 在該路徑上的未結算淨負債； - `finalityLag`：來源鏈事件達到可索賠閾值所需時間； - `messageHealth`：跨鏈訊息或證明通道是否延遲； - `quarantineState`：鏈、資產或 Solver 是否處於隔離狀態。

這些訊號可以對映到使用者可感知的結果：報價上限、滑點保護、預計到帳時間、失敗退款路徑和風險提示。關鍵是不要把所有異常都顯示為“處理中”。跨鏈交換失敗後，使用者應能區分：來源鏈可退款、目標鏈待證明、Solver 已墊付待清算、路徑已隔離、還是最終失敗。

對無託管產品，透明狀態比營銷承諾更重要。AllSwap 不需要聲稱自己消除了跨鏈風險；更合理的做法，是把庫存深度、結算延遲和異常回滾能力納入路由評分，讓高風險路徑自然降低限額或提高成本。

這也影響 [/fees](/fees) 的解釋。跨鏈費用不只是目標鏈 gas 和橋費，還包括 Solver 庫存的機會成本、清算等待期間的資本佔用、訊息證明失敗的重試成本以及隔離狀態下的退款執行成本。對 [/swap/usdt-erc20](/swap/usdt-erc20) 或 [/assets/usdc](/assets/usdc) 這類高頻穩定幣路徑，使用者最關心到帳速度，但系統真正需要約束的是大額訂單在單向流量下是否會把目標鏈庫存抽乾。路由器應把單筆上限、批次視窗和 Solver 額度聯動起來，而不是等庫存耗盡後才提高報價。

仍未解決的問題

第一，虛擬餘額缺少統一審計格式。今天不同 intent 網路、橋和清算層對訂單、索賠、退款和填單證明的欄位命名不同。聚合器需要機器可讀的 `settlementCapabilities`，而不是人工閱讀文件。

第二，Solver 保證金如何跨鏈歸因仍很難。若 Solver 在 B 鏈付款失敗，但原因是 A 鏈訊息延遲或 C 鏈清算層停滯，簡單罰沒 Solver 可能不公平；不罰又會留下道德風險。

第三，淨額清算和使用者退款之間存在優先順序衝突。系統為了批次效率可能想等待更多訂單軋差，但使用者超時退款要求立即釋放來源鏈資產。兩者需要明確優先順序。

第四，跨鏈虛擬餘額最終仍依賴真實再平衡。當單向流量長期佔優時，淨額無法抵消，系統必須從外部補充庫存或提高報價。虛擬餘額不是永動機，它只是更有效地分配結算時間。

第五，隔離狀態下的 UI 仍然缺乏行業標準。使用者不需要看到全部賬本，但需要知道自己處於哪一種可行動狀態：等待、退款、提交證明、改路由，還是聯絡 Solver。沒有這種狀態分解，任何高階清算層都會在故障時退化成客服流程。

References

[1] ERC-7683: Cross Chain Intents, Ethereum EIPs, 2026, https://eips.ethereum.org/EIPS/eip-7683

[2] Across Protocol Documentation, Across, 2026, https://docs.across.to/

[3] Across Intent Lifecycle, Across, 2026, https://docs.across.to/guides/concepts/intent-lifecycle

[4] Everclear Documentation, Everclear, 2026, https://docs.everclear.org/

[5] Everclear Protocol Mechanics, Everclear, 2026, https://docs.everclear.org/developers/protocol-mechanics

[6] UniswapX Whitepaper, Uniswap Labs, 2023, https://uniswap.org/whitepaper-uniswapx.pdf

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

[8] IBC Protocol Specification, Cosmos IBC, 2026, https://github.com/cosmos/ibc/tree/main/spec

[9] L2BEAT Scaling Summary and Risk Framework, L2BEAT, 2026, https://l2beat.com/scaling/summary

[10] Optimism Standard Bridge and Finalization Concepts, OP Docs, 2026, https://docs.optimism.io/app-developers/bridging/standard-bridge