ERC-1693：延遲結算的同質化代幣標準

為 ERC-1693 開啟討論串，這是一項針對 ERC-20 的擴展提案，引入了 T+2 結算期以及交易雙方的肯定性雙邊同意機制。

• PR： Add ERC: Deferred-Settlement Fungible Tokens by LevanIlashvili · Pull Request #1693 · ethereum/ERCs · GitHub

• 參考實作： GitHub - LevanIlashvili/erc-20t2: Reference implementation of EIP-11547: Deferred-Settlement Fungible Token Standard (T+2 settlement, bilateral consent) · GitHub (Solidity + 44 個 Foundry 測試，MIT 授權)

摘要

在 ERC-20 標準下，轉帳是原子化且不可撤銷地結算的。在 2020 年至 2026 年間，DeFi 生態系統因漏洞利用損失了超過 120 億美元，這些漏洞的共同結構特徵是「同區塊結算」：當任何一方意識到未經授權的交易時，追回已是不可能的。

ERC-1693 引入了一個生命週期，其中每筆轉帳都會進入為期兩天的結算窗口 (T+2)，在此期間發送者可以取消，接收者可以拒絕。T+2 之後的最終確認需要接收者明確確認；未經確認的轉帳在另外五天 (T+7) 後可由發送者自動收回。

在此生命週期的任何階段，都不存在代幣由單一單方面控制的間隔。這是刻意為之的設計。

動機

此設計直接借鑒了 NSCC T+2 股票清算和 ACH 五個工作日退款窗口的雙邊同意、延遲結算慣例——這些系統數十年來每年處理數萬億美元規模的結算，卻未曾出現 DeFi 中已成常態的那類損失。

規範中詳述的一個關鍵點是：僅靠發送端取消是不夠的。它能保護發送者免受自身錯誤轉帳的影響，但對於本提案最關注的情況——發送者私鑰遭破解——則無法提供保護。在這種情況下，唯一有權取消的一方就是被盜的一方。雙邊同意——要求接收者肯定地接受每筆匯入轉帳——填補了這一漏洞。

歡迎提供回饋的問題

• T+2 窗口是否正確，或者標準是否應該為每個代幣設定結算週期的參數限制（下限為 172800 秒，實作「可以」延長）？

• balanceOf 返回 availableBalanceOf（且不含待處理餘額）是否為正確的語義？規範基於防止雙重支出的理由認為是正確的；整合者可能會持不同意見。

• 取消 / 拒絕 / 收回時不恢復授權額度（Allowance）：規範認為這是防止惡意發送者進行騷擾循環（grief loop）所必需的。歡迎提供替代設計。

• 接收者確認機制是否消除了過多合法的「發送即忘（send-and-forget）」模式，還是這正是本提案的目的所在？

會破壞的事物（非詳盡清單）

• 基於 ERC-1693 資產的閃電貸（Flash loans）。需要接收者確認的閃電貸就不再是閃電貸了。

• 靜默接收整合：期望在匯入轉帳時餘額自動更新而無需調用 acknowledge 的合約，其轉帳將在 T+7 時被收回。

• 假設成交即刻結算的做市策略。

• 「發送即忘」的託管模式。

規範認為這些破壞是特性，而非缺陷。

結語

完整的規範和參考實作已在 PR 中提供。參考實作測試了所有四種最終結果（已結算 / 已取消 / 已拒絕 / 已收回）、每個時間窗口邊界以及授權額度的不變量。

樂意針對上述任何內容進行迭代。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-1693-deferred-settlement-fungible-tokens/28295)