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

開啟關於 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-8236-deferred-settlement-fungible-tokens/28295)