ERC-8226：受監管代理人授權標準，為 AI 代理建立合規框架

作者： Ludovico Rossi (Brickken), Dario Lo Buglio (Brickken), Thamer Dridi (Brickken)

GitHub PR： Add ERC: Regulated Agent Mandate by thamerdridi · Pull Request #1679 · ethereum/ERCs · GitHub

狀態： 草案 (Draft)

---

RAMS 為透過 ERC-8004 識別的 AI 代理（AI agents）定義了一個合規授權層，這些代理在受 EIP-7943 管轄的代幣化受監管資產上進行操作。

ERC-8004 賦予 AI 代理一個可移植的鏈上身份。然而，它並未解決當該代理在受監管的金融工具（如代幣化證券或現實世界資產）上執行交易時的情況，這些資產在 MiCA、VARA 或 MiFID II 等框架下受限於 KYC、反洗錢（AML）或投資者資格要求。

RAMS 透過指定以下內容填補了這一空白：

• 授權委託（Mandate delegation）： 經核實的委託人如何向 ERC-8004 代理授予具備範圍限制、時間限制及財務上限的權限，類似於傳統金融中的授權書（power of attorney）。

• 透過 canTransact 進行雙重合規檢查： 具備 RAMS 感知能力的 EIP-7943 代幣如何透過其現有的 canTransact 鉤子（hook）驗證授權有效性，並依序執行兩項檢查：首先是代幣本身對委託人的投資者資格檢查（EIP-7943 合規性絕不會被繞過），接著是代理在 RAMS 上的授權有效性。代幣發行方保留對誰可以持有或交易其工具的完整主權。

• 統一合規提供者： 單一的 IComplianceProvider 介面用於委託人資格驗證（在一次調用中完成身份 + 合規檢查），並提供結構化的原因代碼以供審計追蹤。

• 司法管轄區範圍的執法： 兩層執法者角色（PLATFORM 與 REGULATORY），其凍結權限受司法管轄區範圍限制。全局凍結僅限於 REGULATORY 層級。

該標準定義了兩個介面：IComplianceProvider（外部合規合約）和 IAgentMandate（RAMS 註冊表）。每個 agentId 在同一時間只能有一個活躍的委託人，這反映了 MiCA（第 70 條）、MiFID II（第 16 條）和 VARA 的帳戶隔離要求。代理使用標準的 ERC-20 transfer 和 transferFrom —— 代幣端不需要代理前綴的函數變體。不需要對 ERC-8004 或 EIP-7943 進行任何修改。

---

開放議題

以下議題特意保留以徵求社群意見：

代幣所有權與託管模型。 當代理代表委託人獲取代幣時，誰是登記的所有者？目前正在考慮兩種模型：

• 代理託管（Agent-custodied）： 代幣由代理錢包持有。受益所有權透過 RAMS 註冊表和 ExecutionRecorded 事件進行追蹤。適用於代理需要直接控制的高頻交易策略。

• 委託人託管（Principal-custodied）： 代幣直接轉移或鑄造到委託人的地址。代理負責協調交易，但結算是委託人對委託人。預設產生清晰的投資者名冊。適用於長期投資策略。

這兩種模型都與 RAMS 授權驗證相容。我們正在徵求關於標準應規定預設模型還是保持中立的意見。

接收端合規。 目前的規範涵蓋了由代理發起的出向轉帳（出售、移動）。對於入向轉帳（購買），代幣的 canTransact 必須驗證接收者。如果接收者是代理錢包而非委託人地址，代幣必須決定是對代理還是對委託人應用投資者資格檢查。這與託管模型密切相關。

ERC-8004 中的 regulatoryCompliance 信任信號。 我們建議在 ERC-8004 註冊文件的 supportedTrust 欄位中加入 regulatoryCompliance 值，作為代理在受監管交易的認證授權下運行的信號。這不需要對 ERC-8004 核心規範進行任何更改。

---

參考實現正在開發中：https://github.com/brickken/eip-rams。

我們歡迎針對雙重合規檢查模式、IComplianceProvider 介面、單一活躍委託人限制以及上述開放議題提供反饋。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/erc-8226-regulated-agent-mandate/28208)