草案 ERC：風險信號與響應介面
這份 ERC 草案旨在為 DeFi 協議提出一個機器可讀的介面，用於報告與確認風險事件，並在風險產生者與下游使用者之間建立一個標準化的信號傳輸層。
大家好，我想分享一份針對 DeFi 協議、錢包、聚合器及其他外部使用者所設計的「風險信號與響應介面」（Risk Signaling and Response Interface）草案。
本草案試圖解決的問題，並非如何為每個協議提供另一個暫停按鈕。大多數主流協議已經具備暫停、凍結或守護者（guardian）式的控制功能。目前缺失的層級是一個通用的、機器可讀的介面，用以回答：已通報了哪些風險、哪些已確認，以及協議目前對外界暴露了哪些限制範圍。
預期的定位刻意保持精簡。這不是一個預准入的錢包權限系統，其本身也不是一個執行指令標準。它是一個信號總線（signaling bus）加上響應發現層（response-discovery layer），可介於上游風險產生者與下游使用者之間。
核心設計選擇在於，將「已確認的風險歷史」與「即時的協議限制」刻意分開。註冊表（registry）記錄通報內容與確認內容；響應器（responder）則揭露目前實際生效的限制。這一點至關重要，因為協議可能會在局部恢復並重啟正常流程，而不會抹除曾發生風險事件的歷史事實。
幾個 V1 版本的界限尤為重要：
這不是緊急退出（Emergency Exit）或強制提款標準；
註冊表、通報者和執行者不會獲得對協議資金的直接控制權；
「已提交」（Submitted）和「審核中」（UnderReview）是可觀測的狀態，但「絕不可」自動觸發保護行動；
外部使用者應將協議響應器視為當前限制的真理來源（source of truth），而註冊表則維持作為通報與確認歷史的總線；
核心 V1 中的 dependencyRef 刻意限制為單跳（single-hop）依賴表達；
原子級 0 日響應、完整的守護者網路（keeper networks）以及統一的獎勵曲線，明確不在第一版本的範圍內。
目前的設計也偏好異步執行：裁決者（adjudicators）更新註冊表狀態，而執行者或守護者則分別觸發響應器鉤子（hooks）。其目標是避免讓「確認」動作本身依賴於對任意協議的成功推送調用（push call），同時仍為「已確認但尚未消耗」的報告保留最小限度的機器可讀發現介面。
在此階段，我也刻意將 riskType 分類法和結構化的 evidenceRef 模式視為後續工作，而非核心 V1 的要求。我特別希望獲得關於「對於第一版本而言，這種程度的克制是否正確」的反饋。
我在此階段最看重的反饋包括：
目前的「註冊表總線 + 響應器真理來源」拆分，是否感覺像是正確的最小界限？
V1 是否應要求為異步執行下「已確認但尚未消耗」的報告提供最小限度的機器可讀發現介面？
裁決者的信任與延遲在 V1 中應保持完全由實現定義，還是需要為使用者提供更強的通用框架？
riskType 分類法和結構化證據指南在第一版本中應保持為擴展，還是作為核心要求？
草案：
參考概念驗證（PoC）：
代碼庫：GitHub - tabilabs/erc-risk-signaling · GitHub
建議審閱路徑：README → docs/reviewer-demo.md → docs/spec-map.md → docs/submission-pack.md
1 則貼文 - 1 位參與者
[閱讀完整話題](https://ethereum-magicians.org/t/draft-erc-risk-signaling-and-response-interface/28106)