ERC-7484 把「這顆模組可不可信」壓成一次 staticcall 就讀得完的鏈上狀態，帳戶內部從此有了自己的信任查詢層。但整個系列做到這裡，使用者打開錢包仍然會看到一個下拉選單問他：你現在在哪條鏈。7702 讓 EOA 長出程式碼、passkey 換掉助記詞、session key 免掉逐筆簽名、社交恢復處理遺失、7579 與 7484 把模組治理攤開——這一整串優化的都是「帳戶」，而「鏈」完全沒被動過。今天處理最後這層，方法是讓使用者簽的東西從「一串步驟」變成「一個結果」。
📖 學
交易描述過程，意圖描述結果
一筆傳統交易是命令式的：呼叫哪個合約、傳什麼 calldata、在哪條鏈上。使用者必須先把「我想在 Base 上拿到 100 USDC」翻譯成一條具體路徑，並對這條路徑負全責。意圖(intent)反過來，是宣告式的。ERC-7683 對訂單的定義很直白:訂單是一個「用付款換取一組需求被滿足」的要約。使用者簽的是「我願意付出這些、換到那些結果」，至於中間要做幾筆交易、走哪條橋、先墊誰的錢，交給求解者(solver)或填單者(filler)去競標執行。
規格把訂單生命週期拆成七步：表達意圖 → 應用合成為某協議的訂單 → 使用者簽名授權資金 → 送進訂單流(鏈上或鏈下)→ 填單者評估安全性與獲利性 → 填單者用自己的流動性送進結算合約執行 → 結算完成、填單者拿到補償。關鍵在第六步：錢是填單者先墊的，使用者的體驗之所以「快」，是因為有人願意先承擔跨鏈結算的等待。
第一版 ERC-7683:標準化訂單格式，不標準化結算
ERC-7683 由 Uniswap Labs 與 Across 共同提出。它最為人熟知的第一版設計，標準化的是訂單結構與填單者的消費介面，明確不管你用什麼方式做跨鏈驗證與結算。
訂單有兩種形態。GaslessCrossChainOrder 是使用者鏈下簽名、填單者代送上鏈，所以必須自帶 originSettler、user、nonce、originChainId、openDeadline 這些填單者無法代替決定的欄位;OnchainCrossChainOrder 由使用者自己發交易開單,msg.sender 就是使用者，欄位因此只剩三個：
struct OnchainCrossChainOrder {
uint32 fillDeadline;
bytes32 orderDataType; // EIP-712 typehash
bytes orderData; // 實作專屬:代幣、金額、目的鏈、費用、結算參數
}orderDataType + orderData 這組欄位就是它的可擴充機制：任何協議都能定義自己的子型別塞進 orderData,再用 typehash 宣告自己是哪一種。對應的結算介面則是：
interface IOriginSettler {
function openFor(GaslessCrossChainOrder calldata order, bytes calldata signature, bytes calldata originFillerData) external;
function open(OnchainCrossChainOrder calldata order) external;
function resolveFor(GaslessCrossChainOrder calldata order, bytes calldata originFillerData) external view returns (ResolvedCrossChainOrder memory);
function resolve(OnchainCrossChainOrder calldata order) external view returns (ResolvedCrossChainOrder memory);
}
interface IDestinationSettler {
function fill(bytes32 orderId, bytes calldata originData, bytes calldata fillerData) external;
}resolve / resolveFor 是整套設計的樞紐：把不透明的 orderData 展開成填單者看得懂的 ResolvedCrossChainOrder,裡面有 maxSpent(最多要付出多少)、minReceived(最少會收到多少)、fillInstructions(每一腿要在哪條鏈的哪個合約上填)。填單者理論上只要讀 resolve 的回傳值就能判斷划不划算，不必看懂協議細節。授權面則常搭配 Permit2 的 witness:一個簽名同時授權代幣轉移與訂單條款，避免「先無限授權、再另外簽單」把代幣長期暴露在合約 bug 底下。
2026 年的轉折：原作者自己把它拆掉重寫
這裡是今天最該記住的事實，也是多數中文材料還沒更新到的:上面那套介面，已經被 ERC-7683 自己標為「先前草案」(Previous Draft)。
2026 年 2 月,Francisco Giordano 在 Ethereum Magicians 貼出〈ERC-7683 Redux: Programmable Fillers〉，參與者包含 Across 與 Uniswap(原作者)、LI.FI、OpenZeppelin,背景是 Open Intents Framework。開場就承認:ERC-7683 儘管受到廣泛關注,實際採用度並不高,並附上 Dune 查詢佐證。四個診斷：
| 問題 | 內容 |
|---|---|
orderData 是實作專屬 | 訂單只是「表面上標準化」。填單者要支援 7683 訂單，仍得逐一實作各協議的子型別，跟每家自訂介面沒有本質差別 |
| 獲利只能估下界 | 使用者簽的通常是「我能接受的最差價格」，方向與 maxSpent 正好相反；遇到 Priority Gas Auction 這種由填單者出價決定成本的設計,maxSpent 只能填 UINT256_MAX,等於沒有資訊，好訂單會被誤判成不划算而沒人填 |
| 以託管為中心 | 介面預設「填單前必須先在來源鏈託管資金」。基於資源鎖(resource lock)的 fill-first 協議根本不需要 open,只能把它當事後結算函式硬用 |
| Gas 開銷 | openFor 的 calldata 太肥,Open 事件把整個 resolved order 全發出來。標準介面比自訂介面貴，就是在跟採用作對 |
另外還有兩個小問題：鏈 ID 與位址沒有遵循任何標準(位址編成 bytes32 是為支援非 EVM,卻沒說非 EVM 的鏈 ID 怎麼編),以及 fill 的 fillerData 是完全未指定編碼的 bytes。
重寫版在 2026 年 5 月 13 日以 PR #1741 送進 ERCs 倉庫。截至查證時,eips.ethereum.org 上的 ERC-7683 已是新版內容、狀態標為 Draft、Requires 欄位列著 EIP-7930。
新設計：標準化的不是訂單，是 resolver
新版的判斷是:訂單怎麼產生(使用者端)很難標準化也不需要；真正卡住互通性的是訂單怎麼被消費(填單者端)。 所以整份 ERC 現在只標準化一個東西——resolver。
interface IResolver {
struct ResolvedOrder {
bytes[] steps; // IStep ABI calldata
bytes[] variables; // IVariableRole ABI calldata
bytes[] payments; // IPayment ABI calldata
Assumption[] assumptions;
}
struct Assumption { string name; bytes data; }
function resolve(bytes calldata payload) external view returns (ResolvedOrder memory);
}協議把訂單編成不透明的 payload,並部署一份 resolver 合約，把 payload 翻譯成一組通用指令。填單者透過 eth_call 在鏈下呼叫 resolve,拿回四樣東西：
- Steps:要送哪些交易。每個
Call步驟給的不是扁平 calldata,而是target+selector+arguments陣列，方便把變數注入參數位置。步驟上掛屬性:SpendsERC20(會花多少代幣、需要什麼授權)、SpendsGas、TimingBounds(必須在哪個區塊區間被打包)、RevertPolicy(可以 revert 嗎、revert 了要忽略還是中止)、NeedsStep/NeedsVariable(硬相依，必須無環)。 - Variables:填單者要自己決定的值。
PaymentRecipient、PaymentChain(在哪條鏈的哪個位址收錢)、StepCaller、ExecutionOutput(從執行結果讀回block.timestamp之類)、Query(用eth_call問合約)、Witness(得從鏈下取得，例如 merkle proof)。 - Payments:照做之後會收到什麼。
ERC20payment 有一個非常誠實的欄位estimatedDelaySeconds,直接把「這筆錢大概幾秒後才到」寫進標準。 - Assumptions:resolver 驗不了、但安全性依賴它的前提，以具名字串交給填單者自己查(例如「這張單指定了某個跨鏈訊息協議做結算，你自己判斷信不信」)。frangio 在討論串裡把界線講死了:assumption 之所以是 assumption,就是因為 resolver 沒辦法在鏈上檢查它，所以按設計不會有鏈上強制。
這個模型的目標叫「可編程填單者」(programmable filler):用通用積木組出來的填單者不必事先知道每個協議的執行細節，把 resolver 位址加進白名單就能開始接單。信任點也因此被明確指定——resolver 就是那個點,靠稽核、賞金、時間存活性(lindiness)背書。這跟 ERC-7484 是同一招：不宣稱安全，只把「誰替你背書」變成鏈上可查、可白名單的物件。
填單者的經濟學：資本、延遲、重組
填單者是拿真錢在跑的做市商：他在目的鏈先把 100 USDC 給你，再等結算流程把來源鏈上託管的錢還給他。從掏錢到款項可花用之間，他至少扛三種風險。
資本效率:同一筆資本在結算完成前不能重複使用，獲利率因此受限於「週轉次數 × 每次利差」。結算越慢，同樣年化報酬需要的利差越大，手續費就越貴。新版規格把 estimatedDelaySeconds 拉成一等公民，正是承認延遲是定價的一部分。
重組風險:填單者在目的鏈填完單，依據的是「來源鏈上那筆存款已經確認」。若來源鏈重組、存款消失，他付出去的錢拿不回來。所以他要嘛等更多確認(變慢變貴),要嘛自己吃掉這段風險(反映在報價裡)。這是使用者感覺不到、但一定有人付錢的成本。
集中化:能同時在幾十條鏈備妥庫存、跑最佳化、扛重組風險的機構本來就不多。獨占期機制(指定 exclusive filler 與期限)讓大戶拿到優先權；規模大的報價更好、拿到更多單、規模又更大。ERC-7683 的重寫明說要降低參與門檻，但門檻是不是低到讓小填單者活得下去，目前沒有證據支持樂觀。
這張圖上還有誰
| 層 | 標準 | 抽掉什麼 |
|---|---|---|
| 帳戶授權 | EIP-7702 / ERC-4337 | 「我必須用私鑰逐筆簽名」 |
| Gas 來源 | ERC-4337 paymaster | 「我必須持有這條鏈的原生代幣」 |
| 帳戶能力 | ERC-7579 / 6900 + 7484 | 「我必須信任錢包廠商的功能集」 |
| 位址表示 | ERC-7930(二進位)/ ERC-7828(人類可讀) | 「位址在哪條鏈上是我要記的事」 |
| 執行路徑 | ERC-7683 | 「我必須知道要走哪條橋、幾步」 |
ERC-7930 定義給合約用的緊湊二進位鏈上位址格式，其 ChainType 是對應 CAIP-2 命名空間的 2 byte 值(由 CAIP-350 規定各命名空間的轉換規則);ERC-7828 則是建在其上的人類可讀名稱層。新版 ERC-7683 把 ERC-7930 列為相依，就是在補「鏈 ID 與位址沒有標準」那個洞——訂單裡的 target、token 都是 interoperable address,同一張單因此可以指向 EVM 以外的地方。這幾層彼此不重疊:paymaster 解決「我沒有 gas」，意圖解決「我不在對的鏈上」，兩者都不解決「我不知道自己簽了什麼」。
底下墊著什麼
意圖層看起來乾淨，是因為髒東西被推到下面。結算驗證最終要回答「目的鏈上真的填單了嗎」，而這只有三類答案：樂觀式(先假設有效、留爭議期、靠爭議者與保證金)、輕客戶端/證明式(在來源鏈驗證目的鏈共識或狀態證明，最貴但信任假設最小)、預言機式或委員會式(相信一組簽名者，最快最便宜，信任假設最大)。填單者的 assumption 清單裡，十有八九就是這件事。
再往下是排序層。共享排序器與 based rollup 的方向是讓跨 rollup 操作能同步組合，那樣意圖裡的「等待」會消失，填單者的資本佔用也一起消失。但截至查證時，主要 L2 的排序器仍然中心化，共享排序方案處在受許可節點集或分階段推出的狀態，跨 rollup 原子組合性還不是已上線的生產功能。填單者存在的理由，很大一部分就是因為這層還沒做好。
界線：意圖沒有消除信任，只是搬家
最後把反方講完，這些不是細節，是設計的本體。
信任被搬到 resolver 與結算合約上。 使用者原本信任「我選的橋」，現在信任「應用替我選的協議 + 填單者網路 + 結算驗證方式」。ERC 的 Security Considerations 講得很白：這份標準規範的是協議怎麼向填單者描述訂單,不標準化、也不保證最終結算那個協議的安全性。
MEV 從交易層搬到意圖層。 訂單流本身就是有價值的資訊：誰能看到訂單、看到多久、能不能在履行前先去別處交易，這些都可以被賣。訂單流拍賣與私有訂單流會長在意圖層，和它們過去長在交易層是同一套經濟學。
使用者無法驗證自己拿到的是不是最佳報價。 你簽的是「結果」，填單者只需要達到你簽下的最低標準，超出的部分全歸他。理論上競爭會壓縮利差，但競爭是否真的發生、發生在什麼樣的拍賣機制裡，一般使用者既看不到也驗不了。放棄對路徑的控制權，換來的是對執行者的信任義務。
還有一類問題連規格都沒解。 若目的鏈上的「填單」會改變某應用的正規狀態(例如把資金收進隱私池、賦予成員資格),樂觀式的先填後結算就不安全：攻擊者同時控制使用者與填單者，可在目的鏈完成狀態轉換後不去結算，等失敗被發現時狀態已經改完。這類「有狀態的意圖」需要「填單前先證明來源鏈鎖倉存在」，規格目前沒有明確涵蓋。
採用度要誠實說。 一個討論了快兩年的標準被作者自己判定「未獲得足夠採用」而整份重寫，重寫版仍是 Draft、初始屬性集與變數角色集還在收斂，實務上跑的仍是各協議自己的介面。今天學的價值在於理解問題的形狀，不是明天就去接一個穩定的 API。
🧠 記
- 意圖 = 宣告式訂單:訂單是「用付款換取一組需求被滿足」的要約；使用者簽結果，填單者競標執行過程。
- 第一版的三個名字:
GaslessCrossChainOrder(鏈下簽、填單者代送，靠openFor)、OnchainCrossChainOrder(自己送，靠open)、ResolvedCrossChainOrder(resolve展開後的通用形式);可擴充靠orderDataType+orderData。 - 被重寫的四個理由:
orderData實作專屬只有表面標準化、獲利只能估下界、介面預設託管排除 fill-first 協議、gas 開銷讓標準介面輸給自訂介面。 - 新版只標準化 resolver:
IResolver.resolve(payload)回傳ResolvedOrder{steps, variables, payments, assumptions};信任點是 resolver。Assumption 按設計沒有鏈上強制——存在的理由就是 resolver 檢查不了。estimatedDelaySeconds則把結算延遲寫成欄位，是理解填單者定價的最短路徑。 - 一句話總結:意圖抽掉的是使用者對路徑的認知負擔，不是風險；風險被重新打包賣給願意先墊錢的人，再以價差形式賣回給使用者。
✍️ 實踐
15 分鐘，不需要送任何交易，重點是把「抽象費用」拆回具體成本。
第一步(5 分鐘):打開 https://eips.ethereum.org/EIPS/eip-7683,只讀 Rationale 底下的 Previous Draft 一小節，用自己的話寫下被放棄標準化的五個生命週期環節，再把 Security Considerations 的第一句抄下來。
第二步(5 分鐘):打開任一意圖式跨鏈前端(例如 Across 的 app),輸入 100 USDC 從 Arbitrum 到 Base,停在報價畫面不要送出。把畫面上所有數字抄下來，分成三堆:(a) 填單者利差,(b) 目的鏈執行 gas,(c) 來源鏈開單 gas;分不出來的列成第四堆「無法歸因」。
第三步(5 分鐘):寫三句話回答:(1) 填單者在目的鏈填了單卻拿不到補償，我的錢會在哪裡?(2)「這張單已經被填了」是誰在什麼地方做出的判斷?(3) 這個判斷需要相信誰？列出具體角色名稱。
自我檢查:
- 第二步的「無法歸因」若是空的，幾乎可確定你把某些數字歸錯類——重組風險溢價與資本佔用成本不會被單獨標示，它們一定混在利差裡。
- 第三步第 3 題，如果答案是「相信以太坊」，那大概率答錯了。結算驗證幾乎一定經過某個跨鏈訊息系統，答案應該是一組具名角色：某爭議期的爭議者、某組驗證者簽名、或某個輕客戶端證明的來源。答不出具體名字，就代表這筆交易對你仍然是黑箱——而這正是今天想讓你感覺到的東西。
🔗 延伸學習
- ERC-7683: Cross Chain Intents(EIP 原文，重寫後的 resolver 版本)
- ERC-7683 Redux: Programmable Fillers(Ethereum Magicians,2026-02,重寫的動機與診斷)
- erc7683.org Spec(第一版介面與 Permit2 說明的完整保存)
- ERC-7930: Interoperable Addresses(新版 7683 的相依標準)
💬 問 AI
我正在理解跨鏈意圖(cross-chain intents)與 ERC-7683,請用具體機制回答,不要用「更快更便宜」這種描述:
1. ERC-7683 在 2026 年被原作者重寫成 resolver 中心的設計:舊版標準化訂單結構,新版只標準化 IResolver.resolve。從「填單者的整合成本」角度,這個改動具體省掉什麼?又新增什麼風險?
2. 新版把 resolver 明確定為信任點,填單者要白名單它。這跟 ERC-7484 把 attester 定為信任點在結構上是同一招嗎?兩者在「信任被撤銷時會發生什麼」上有什麼差別?
3. 舊版的 maxSpent / minReceived 只能給出利潤下界。請用具體數字例子說明,為什麼「下界不夠緊」會導致本來划算的訂單沒人填。
4. 填單者在目的鏈墊了 100 USDC 等來源鏈結算。請逐項列出他這段期間承擔的風險,並說明每一項最後怎麼反映到使用者看到的報價上。
5. 意圖層的 MEV 跟交易層的 MEV 有什麼結構性差異?使用者有沒有任何技術手段可以驗證自己拿到的報價接近最佳?如果沒有,請直說沒有。
6. 如果共享排序器與 based rollup 真的提供了跨 rollup 同步組合性,填單者這個角色會消失還是改變形態?這件事離生產環境還有多遠?