ERC-1693：延期結算同質化代幣標準提案

開啟關於 ERC-1693 的討論串，這是一項針對 ERC-20 的擴展提案，引入了 T+2 結算期以及交易對手之間的雙向主動同意機制。

• PR： Add ERC-1693: 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) 所必需的。歡迎提出替代設計。

• 接收者確認機制是否消除了過多合法的「發送即忘」模式，還是這正是其目的所在？

會破壞的內容（非詳盡清單）

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

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

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

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

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

結語

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

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

        1 則貼文 - 1 位參與者

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