撰文：慢霧安全團隊
隨着(穩定幣條例)的正式通過，香港金融管理局(HKMA) 於 2025 年 5 月 26 日發佈了(持牌穩定幣發行人監管指引（草案）)，旨在確保本地穩定幣生態的穩定、安全與合規運作。該指引詳盡列明瞭持牌穩定幣發行人必須持續遵守的監管要求與運營標準。
近期，越來越多機構就智能合約的合規實施問題向慢霧安全團隊(SlowMist) 諮詢。爲協助發行人更好地理解和部署合規的智能合約體系，我們特別發佈了(面向香港穩定幣發行人的智能合約實施指南)，以提供清晰的技術路徑與實踐建議，支持香港穩定幣生態的健康發展。
第一部分 基礎架構與合規策略
本部分旨在爲穩定幣系統奠定高層架構的基石，這些架構決策完全由香港金融管理局(HKMA) 框架中最根本的要求驅動。在此處做出的選擇將決定整個實施路徑，確保從設計之初就將合規性深度嵌入技術棧中。
1. 底層分佈式賬本的選擇
監管指令
持牌人必須評估其所使用的底層分佈式賬本技術(DLT) 的穩健性。此評估涵蓋安全基礎設施、對常見攻擊（如 51% 攻擊）的抵禦能力、交易最終性保障以及共識算法的可靠性1。
慢霧(SlowMist) 技術解讀
這並非一項簡單的技術偏好選擇，而是一項核心的合規任務。對底層區塊鏈的選擇必須經過正式的盡職調查，整個評估過程也需被詳細記錄，以便在監管審查時提供充分理據。底層賬本的選擇過程實際上爲整個穩定幣系統的安全性與穩定性奠定了基調。
香港金管局對賬本穩健性的強調，實質上是在勸誡發行方避免採用未經市場驗證、中心化程度過高或安全性存疑的新興區塊鏈。證明其安全性與穩定性的責任完全由發行方承擔。如果發行方選擇了安全性尚未被廣泛驗證的鏈，就必須設計並實施額外的補償性控制措施。
實施指南
優先選擇成熟的公有鏈：建議優先選用如 Ethereum、Arbitrum 等成熟且具備高安全性的公有區塊鏈。這類網絡憑藉其久經考驗的韌性、龐大的驗證節點網絡以及持續的公衆監督，具備天然優勢。其高昂的攻擊成本（經濟安全性）可直接回應監管對抵禦 51% 攻擊及保障交易最終性的關切。
替代方案的嚴格評估：若考慮採用聯盟鏈或其他類型的分佈式賬本，必須開展一項嚴謹且可量化的對比分析，例如慢霧安全審計，以證明其安全標準不低於，甚至優於主流的公有鏈。
風險評估文檔：評估報告必須全面覆蓋其抵禦常見攻擊的能力、共識算法類型，以及與代碼缺陷、漏洞、漏洞利用及其他威脅相關的風險2，並詳細分析這些風險如何對穩定幣的發行、贖回及日常運營構成潛在影響。此文檔是向監管機構證明技術選型審慎性的關鍵文件。
2. 核心代幣標準與監管功能擴展
監管指令
監管文件並未指定某一特定的代幣標準（如 ERC-20）。然而，文件強制要求實現一系列核心管理功能，包括鑄幣(mint)、銷燬(burn)、升級(upgrade)、暫停(pause)、恢復(resume)、凍結(freeze)、黑名單(blacklist)、白名單(whitelist) 等操作3。
慢霧(SlowMist) 技術解讀
香港金管局事實上定義了一個功能遠超 ERC-20 標準的「監管增強型」代幣標準。該標準不僅要求具備基礎的代幣流轉功能，更強調操作安全性、權限可控性和風險可追溯性。爲了在滿足合規要求的同時最大限度地保障安全性，最高效且最穩妥的開發路徑，是採用經過廣泛審計、社區公認的標準庫（如 OpenZeppelin），並在此基礎上進行功能擴展。
實施指南
基礎標準：採用 ERC-20 作爲基礎標準，以確保代幣的同質化和在更廣泛生態系統中的互操作性。
功能擴展：必須集成以下功能模塊，以滿足監管要求：
Pausable：用於實現對所有代幣活動的全局暫停與恢復功能，這是應對重大安全事件的核心工具。
Mintable：用於實現持牌發行人需通過受控流程鑄造新代幣，並確保代幣發行量嚴格對應足額法幣儲備資產。
Burnable：提供銷燬代幣的功能。在具體的實現中，此功能將是受嚴格權限控制的，而非允許任意用戶自行銷燬。
Freezable：用於暫停特定賬戶的代幣轉移功能（如涉及可疑交易）。
Whitelist：用於實施額外的安全措施，僅允許通過盡職調查和批准的地址參與核心操作（如接收新鑄代幣4）。
Blacklist：用於實現對涉及非法活動（如洗錢、欺詐）的地址實施交易禁令，禁止其發送 / 接收代幣。黑名單管理需與 AML / CFT 系統聯動，實時監控可疑交易。
AccessControl：這是實現精細化、基於角色的權限管理系統的基礎。所有管理功能都必須通過此模塊進行權限控制，以滿足職責分離的要求5。
3. 主要合規模式：黑名單與白名單的選擇
監管指令
關於持續監控，反洗錢 / 打擊恐怖分子資金籌集(AML / CFT) 的諮詢文件提出了多種措施，其中包括「將被識別爲受制裁或與非法活動相關的錢包地址列入黑名單」，或者採取更嚴格的「對穩定幣持有人的錢包地址實行白名單制，或採用閉環模式」6。
慢霧(SlowMist) 技術解讀
這是整個系統架構中最爲關鍵的決策點，它直接決定了穩定幣的開放性、實用性以及合規操作的複雜性。
黑名單模式：一種「默認開放」的模式。所有地址默認可以自由交易，只有那些被明確識別並添加至鏈上黑名單的地址，纔會被限制。
白名單模式：一種「默認關閉」的閉環模式。任何地址，除非經過發行方明確的盡職調查和批准，並被添加至鏈上白名單，否則無法持有或接收代幣。
儘管白名單模式提供了 AML（反洗錢）控制能力，但對於一個旨在被廣泛使用的穩定幣而言，嚴格的白名單制度意味着穩定幣只能在預先審查過的參與者之間流轉，這使其更像一個封閉的銀行賬本系統，而非一種靈活的數字貨幣。
因此，同樣被監管明確提及的黑名單模式，結合監管所要求的強大鏈下分析工具，構成了一種更爲平衡的方案。它既滿足了監管要求，又保留了資產的實用性。
在設計上，系統可以被構建爲可升級的，或同時實現兩種模式，以便在未來監管收緊或業務模式變更時，能夠平滑過渡或切換至白名單模式。
實施指南
黑名單模式（默認推薦方案）：
優點：具有更高的實用性，能夠與廣闊的去中心化金融(DeFi) 生態系統無縫互操作，爲用戶提供更低的使用門檻和更流暢的體驗。
缺點：合規性高度依賴於強大的、實時的鏈下監控分析能力，以便及時發現並封堵非法地址。
實現方式：在智能合約的轉賬函數中，增加邏輯檢查，確保交易的發送方(from) 和接收方(to) 地址均未被記錄在黑名單中。
白名單模式
優點：提供最高級別的 AML / CFT 控制，實現了事前預防，而非事後補救。
缺點：極大地限制了穩定幣的通用性和採納率，爲管理白名單帶來了巨大的運營開銷，可能使其難以成爲一種被廣泛接受的交易媒介。
實現方式：在智能合約的轉賬函數中，增加邏輯檢查，要求交易的發送方(from) 和接收方(to) 地址都必須存在於白名單中。建議開發專用 Web 用戶後臺系統進行操作，增加操作的便利性。
第二部分 智能合約實現
本部分爲智能合約的核心功能提供了一份詳盡的藍圖，將複雜的監管要求轉化爲具體的代碼級邏輯、安全模式和操作協議。
1. 設計精細化的訪問控制系統
監管指令
高風險操作的設計必須「防止任何單一方能夠單方面執行相關操作（例如，通過多重簽名協議）」7。不同操作的職責應被充分隔離。
慢霧(SlowMist) 技術解讀
這意味着，一個強大且基於角色的訪問控制系統(RBAC) 是強制性的。任何形式的單一「所有者」或「管理員」私鑰，都是不合規的。
實施指南
必須定義一系列清晰的角色，並將這些角色分配給不同的、由多重簽名錢包控制的實體或員工，以實現職責分離，最大限度降低單一故障點或合謀操縱的風險8。每個角色應僅限於特定職能，所有操作需多簽名授權，並確保無單一員工同時持有多個高風險角色。所有操作需記錄日誌，並接受年度第三方審計，權限分配由管理員或董事會監督。
MINTER_ROLE：負責處理穩定幣的鑄幣(mint) 操作，包括在收到有效發行請求後創建代幣單位，並確保鑄幣與儲備資產池的相應增加匹配。
BURNER_ROLE：負責處理穩定幣的銷燬(burn) 操作，包括在收到有效贖回請求後銷燬代幣單位。
PAUSER_ROLE：負責暫停(pause) 穩定幣的操作，例如在檢測到異常事件（如安全威脅）時臨時停止轉賬、鑄幣或贖回。
RESUME_ROLE：負責恢復(resume) 穩定幣的操作，例如在暫停事件解決後重新啓用轉賬、鑄幣或贖回。
FREEZER_ROLE：負責凍結(freeze) 和解除凍結(remove freeze) 特定錢包或代幣的操作，例如在檢測到可疑活動（如洗錢風險）時臨時凍結資產。
WHITELISTER_ROLE：負責管理白名單(whitelist)，包括添加或移除允許的錢包地址，例如限制鑄幣僅限於白名單地址。
BLACKLISTER_ROLE：負責管理黑名單(blacklist) 和移除黑名單(remove blacklist)，例如將可疑錢包列入黑名單以阻止轉賬。
UPGRADER_ROLE：如果採用可升級模型，負責升級(upgrade) 智能合約，例如更新合約代碼以修復漏洞或添加功能。
表 1：基於角色的訪問控制矩陣(RBAC Matrix)
下表提供了一個清晰、直觀的規範，供開發人員和審計人員使用，明確地將每個特權操作映射到其所需的角色和控制類型。
2. 發行（鑄幣）機制
監管指令
發行必須是「審慎和穩健的」。鑄幣必須「與相關儲備資產池的相應增加相匹配」。發行人應僅在收到資金和有效的發行請求後向其客戶發行9。
慢霧(SlowMist) 技術解讀
智能合約本身無法也無需強制執行「完全儲備」的要求。相反，它扮演的是一個受控賬本的角色，其中鑄幣權限是關鍵的控制點。完全儲備的合規性是一項發生在鏈下、可通過審計驗證的操作流程。監管將鑄幣行爲與「有效的發行請求」和「收到資金」這兩個鏈下事件綁定。因此，鏈上的鑄造函數必須被設計爲只能由一個能夠驗證這些鏈下條件已滿足的可信實體（即發行人自己）調用。
實施指南
前置檢查：函數在執行鑄幣前，必須檢查目標地址 to 是否處於黑名單或被凍結狀態。
操作流程：
鏈下盡職調查：客戶完成所有必需的鏈下客戶身份識別(KYC) 和客戶盡職調查(CDD) 流程10。此外，AML / CFT 法規要求，對於建立業務關係或進行超過特定閾值（如 8,000 港元）的偶爾交易的客戶，必須執行 CDD11。
資金接收：客戶將等值的法幣資金轉入發行人指定的銀行賬戶。
內部驗證：發行人的內部系統確認收到資金，並相應更新儲備資產的會計記錄。
鏈上執行：運營團隊創建並簽署一個多重簽名交易，調用智能合約的鑄造代幣函數，將新鑄造的穩定幣發送到客戶預先註冊並經驗證的錢包地址。
3. 贖回（銷燬）機制
監管指令
持牌人必須在收到有效的贖回請求後，「在切實可行的範圍內儘快並在收到請求後的一個營業日內」處理12。儲備資產的提取必須「與流通中的指定穩定幣面值的相應減少相匹配」13。
慢霧(SlowMist) 技術解讀
贖回是一個涉及鏈上與鏈下交互的兩步過程。在贖回過程中，考慮到法幣轉賬可能失敗的風險，代幣的銷燬操作必須在確認法幣結算之後進行，而非在此之前。這樣可以保護髮行人，避免其因一筆最終失敗的贖回而提前銷燬代幣。
如果發行人先銷燬代幣，而銀行轉賬失敗，將導致其承擔無對應資產的負債；反之，如果發行人先支付法幣，卻無法銷燬對應的代幣，也將蒙受損失。
因此，在贖回操作中，用戶需先將代幣轉移至由發行人控制的指定地址，隨後發行人在完成法幣支付後再執行銷燬。此模式允許用戶將其代幣「鎖定」以供贖回，而發行人僅在履行完法幣支付義務後才銷燬代幣，從而爲雙方提供了一個更安全的操作流程。
實施指南
贖回準備：用戶首先需要先將要贖回的代幣轉移至發行人控制的指定地址。
操作流程：
鏈下請求：用戶通過發行方的平臺提交一個鏈下贖回請求。在處理請求前，發行人必須對客戶進行適當的客戶盡職調查(CDD)。
系統驗證：發行人的系統驗證請求的有效性，並檢查用戶是否已在鏈上完成了相應的代幣轉移操作。
法幣支付：發行人將等值的法幣轉賬至用戶預先註冊並驗證的銀行賬戶。
鏈上銷燬：在確認法幣轉賬成功後，持有 BURNER_ROLE 的多重簽名錢包調用銷燬函數，從指定的地址中銷燬相應數量的代幣。
4. 實施緊急控制：暫停與凍結
監管指令
合約必須支持暫停、恢復、拉黑、移除黑名單、凍結、解除凍結等操作。這些是事件管理框架的關鍵組成部分14。
慢霧(SlowMist) 技術解讀
監管文件將「暫停」和「凍結」作爲兩個獨立項目列出，這表明監管機構期望發行人具備靈活、分層的事件響應能力。暫停是應對重大危機（如合約被利用）的一種手段，而凍結則是處理特定法律或合規問題（如針對單個賬戶的法院命令）的精確工具。兩者在功能上截然不同，必須分別實現：
暫停(Pause)：一個全局性的「緊急停止開關」，可瞬間中止合約的所有核心功能，包括轉賬、鑄幣和銷燬。
凍結(Freeze)：一種賬戶級別的限制措施，可阻止某個特定地址發送或接收代幣，但不會影響網絡中其他地址的正常活動。
實施指南
暫停功能：僅由持有 PAUSER_ROLE 的多重簽名錢包調用，用於全局中止合約功能。觸發條件包括檢測到異常事件（如網絡攻擊或儲備資產不匹配），需董事會或高級管理層批准。恢復功能由獨立的 RESUME_ROLE 處理，以實現職責分離。
凍結功能：由持有 FREEZER_ROLE 的多重簽名錢包調用，用於針對特定地址的轉賬限制。觸發條件包括可疑活動（如 AML 警報或法院命令），需鏈下驗證後執行。解除凍結由同一角色處理，但需額外審計驗證，發佈相關公告，以防止濫用。
5. 地址篩選與黑名單機制
監管指令
持牌人應採取措施，例如「將被識別爲受制裁或與非法活動相關的錢包地址列入黑名單」15。這是持續監控的核心控制手段，發行人應採用區塊鏈分析工具等技術方案，以識別與非法或可疑活動相關的交易16。
慢霧(SlowMist) 技術解讀
這必須是一個在鏈上強制執行的機制。僅僅在鏈下發出警告是不夠的，必須在協議層面阻止交易的發生。黑名單的要求使持牌人需要採用實時的區塊鏈分析工具 / 服務（如 MistTrack、Chainalysis、Elliptic）。合規團隊利用這些工具得出的結論，安全地轉化爲由多重簽名簽署的交易，以更新鏈上的黑名單。
實施指南
函數實現：實現黑名單添加、黑名單移除功能的函數，並且僅由持有 BLACKLISTER_ROLE 的多重簽名錢包調用。
轉賬限制：禁止加入黑名單的地址轉移 / 接收代幣。
操作流程：分析工具發出警報，觸發內部合規審查，合規團隊審查確認後，由 BLACKLISTER_ROLE 多籤錢包發起黑名單添加交易。
6. 智能合約的可升級性
監管指令
穩定幣相關的所有智能合約架構可能採用「可升級性」17。每當智能合約進行「升級」時，都必須進行審計18。
慢霧(SlowMist) 技術解讀
可升級性設計是監管框架中對技術靈活性和風險管理的核心要求。它允許發行人在不中斷現有合約狀態的情況下更新邏輯，以應對漏洞修復、功能擴展或監管變更。
然而，這也帶來了高風險：升級過程可能被濫用，導致合約行爲意外變更或引入新漏洞。因此，升級必須被視爲高風險操作，設計時應防止單一方單方面執行（如通過多重簽名協議），並與基於角色的訪問控制系統(RBAC) 集成。
監管強調的審計要求意味着，升級不僅是代碼替換，更是嵌入嚴格變更管理流程的受控事件，確保新邏輯合約在部署前經過第三方驗證，無漏洞或安全缺陷。
實施指南
代理模型：對於 EVM 類型的智能合約來說，可以採用成熟的 ERC-1967 代理模型以實現可升級性。
權限控制：升級函數必須僅由持有 UPGRADER_ROLE 的多重簽名錢包調用。
變更管理流程：根據監管要求，在提議任何升級之前，必須完成一個嚴格的變更管理流程，其中包括對新的邏輯合約進行全面的、獨立的第三方安全審計。
7. 用於分析和報告的鏈上事件日誌
監管指令
持牌人必須建立穩健的「信息和會計系統」，以「及時、準確地記錄所有業務活動，包括鏈上和鏈下信息」，並「保留適當的審計追蹤」19。
慢霧(SlowMist) 技術解讀
智能合約是所有鏈上活動的主要事實來源。它必須爲每一次重要的狀態變更發出詳細的事件(Events)，以便鏈下系統進行日誌記錄、監控和生成報告。這些事件在區塊鏈上創建了一個不可篡改且永久的日誌。該日誌是所有鏈下監控、會計和報告系統的主要數據源，爲審計提供了堅實的基礎。
實施指南
除了 ERC-20 標準的要求的轉賬(Transfer)、授權(Approval) 事件外，合約必須爲所有管理行爲和狀態變更定義併發出自定義事件：
代幣鑄造 / 銷燬(Minted / Burned) 事件
合約暫停 / 恢復(Paused / Resume) 事件
黑名單添加 / 移除(BlacklistAdded / BlacklistRemoved) 事件
白名單添加 / 移除(WhitelistAdded / WhitelistRemoved) 事件
地址凍結 / 解除凍結(AddressFrozen / AddressUnfrozen) 事件
特權角色變更(RoleGranted / RoleRevoked) 事件
合約升級(Upgraded) 事件
第三部分 運營安全與生命週期管理
本部分詳細闡述了圍繞智能合約的、至關重要的運營安全程序。這些程序與代碼本身同等重要，是實現全面安全和合規的必要條件。
1. 安全密鑰管理架構
監管指令
這是監管文件中規定最爲詳盡和嚴格的領域之一。持牌人必須對私鑰的整個生命週期實施強有力的控制，包括生成、存儲、使用、備份和銷燬20。「重要種子和/或私鑰」（例如，用於升級、角色管理、大規模鑄幣的密鑰）需要採用更高級別的安全標準，包括在「氣隙環境」(air-gapped environment) 中進行離線生成21，並存儲在硬件安全模塊(HSM) 中22。
慢霧(SlowMist) 技術解讀
香港金管局實質上是在要求將「傳統金融級別」的安全態勢應用於加密原生操作。實施這種級別的密鑰管理所帶來的成本與複雜性是巨大的，它將成爲任何持牌發行人的核心運營部分。這種安全模型遠遠超出了典型 DeFi 項目的實踐標準。監管文件爲密鑰管理提供了一份詳細清單，明確提到了 HSM（硬件安全模塊）、氣隙環境、密鑰儀式和多重簽名。這實際上強制要求構建一個縱深防禦的密鑰管理架構：由保存在硬件錢包中的賬戶作爲多重簽名錢包的簽名者，而該多重簽名錢包本身則持有智能合約上的管理角色。對於安全級別最高的角色，這些硬件錢包本身必須在指定的、具備物理安全性的氣隙環境中進行管理。整個架構構建了一個用於抵禦密鑰泄露的多層防禦體系。
實施指南
密鑰生成：必須通過一個有詳細文檔記錄的「密鑰儀式」(key ceremony)23，在一個物理安全的、與外界網絡完全隔離的氣隙環境中完成。
密鑰存儲：所有管理角色都必須由多重簽名錢包控制。這些多籤錢包的簽名者所使用的私鑰，必須存儲在 HSM 或其他的安全硬件錢包中。對於最關鍵的角色其對應的密鑰必須保存在氣隙系統中，與任何在線環境物理隔離。
密鑰使用：必須強制執行多重簽名策略。對於涉及「重要私鑰」的交易簽名，可能需要相關人員親自到場操作24。
備份與恢復：密鑰分片或助記詞的備份必須存儲在香港境內（或經監管批准的地點）的多個安全且地理上分散的位置，並採用防篡改的包裝25。
2. 完備的部署流程與運行時監控
監管指令
持牌人必須聘請「合格的第三方實體審計智能合約」，審計頻率至少爲每年一次，並且在每次部署、重新部署或升級時都必須進行。審計必須確保合約實現正確、功能符合預期，並且在「高度可信的水平上」不存在任何漏洞或安全缺陷26。被許可方應實施措施監控助記詞和 / 或私鑰的使用情況（例如 IP 檢查、行爲監測、關鍵活動警報、設備篩查、鏈上監測、訪問控制監測等）27。並且被許可方應採取適當措施監測威脅情報，以發現新出現的威脅。應對威脅情報進行分析，以便能夠及時實施緩解措施28。
慢霧(SlowMist) 技術解讀
部署流程和運行時監控是監管對技術風險管理框架的直接延伸，強調從源頭防範漏洞並持續監測運營風險。部署前審計要求將智能合約視爲關鍵基礎設施，必須通過多層驗證（如單元測試、獨立審計和代碼凍結）確保無缺陷，這反映了監管對「高度可信」標準的追求，以避免代碼缺陷或漏洞利用影響穩定幣的發行、贖回或日常運營。運行時監控則聚焦於實時威脅檢測，結合私鑰使用監控（如行爲分析）和威脅情報分析，形成閉環響應機制。這不僅滿足事件管理框架的需求，還確保系統能動態應對新興風險。整體而言，此部分的技術實現需整合鏈上鍊下工具，形成可追溯的審計追蹤，從而將被動防禦轉化爲主動合規。
實施指南
在正式部署之前，必須制定並嚴格執行一份「部署前檢查清單」：
全面測試：確保單元測試覆蓋率 95% 以上，核心代碼覆蓋率 100%，確保輸出單元測試的覆蓋率報告。
獨立審計：完成至少一家、最好是兩家信譽良好的審計公司出具的獨立安全審計報告。
代碼凍結：完成審計後，凍結代碼直至上線，不再做任何代碼改動。
迴歸測試：在正式部署前，執行單元測試並進行迴歸測試。
合規籤核：獲得內部合規團隊的正式籤核，確認合約邏輯滿足所有相關監管要求。
部署演練：準備詳細的部署腳本，並在一個與主網環境完全一致的測試網上進行完整的部署演練。
授權部署：由授權的錢包執行最終的部署操作。
完成部署後應採取適當監控措施，以對特權角色的使用情況以及新出現的威脅及時實施緩解措施：
鏈上活動監控：監控管理角色的使用情況（例如，使用慢霧安全監控系統 MistEye 添加關鍵角色活動監測），及時發現未授權情況的發生。
威脅情報監測：應及時發現新出現的威脅（例如，使用慢霧安全監控系統 MistEye 的威脅情報訂閱），並對威脅情報進行分析，以便能夠及時實施緩解措施。
3.爲業務連續性和退出計劃提供技術支持
監管指令
持牌人必須制定一份「業務退出計劃，以實現其持牌穩定幣業務的有序清盤」29。該計劃必須包括清算儲備資產和向持有人分配收益的程序。
慢霧(SlowMist) 技術解讀
這意味着智能合約從設計之初就必須考慮其自身的「退役」過程，它需要具備能夠實現有序關停的狀態與機制。退出機制的要求意味着，智能合約的生命週期並不在部署時終結，而是必須擁有一個明確定義的、協議層的「生命終結」協議。這對許多習慣於構建「永久」合約的開發者來說是一個新穎的概念，也由此推動了一種「爲終止而設計」的思維模式。一個有序的清盤過程需要一份乾淨、最終且無爭議的記錄，明確在關停時刻誰擁有什麼。如果在一個混亂的、仍在進行交易的狀態下進行關停，這一目標將難以實現。因此，一個能夠凍結合約狀態的函數，就是這一監管要求的直接技術體現。鏈上狀態由此成爲清算人手中最終的、可審計的事實來源。
實施指南
制定業務退出計劃：計劃涵蓋可能導致有序終止的各類情形，幷包含對這些情形實際發生或潛在發生的監測措施。
鏈上退出流程30：
應暫停智能合約以停止所有代幣轉移行爲，以確保最大化儲備資產變現收益、最小化對整體市場穩定的影響。
依託贖回功能與白名單功能，協助穩定幣持有人提交贖回申請。
第四部分 附錄：監管要求交叉引用表
本表將智能合約系統的每一個技術特性直接映射到強制要求它的具體監管文本：
相關資料
[1]Hong Kong Monetary Authority. (2025, May 26). Consultation paper on the proposed AML/CFT requirements for regulated stablecoin activities. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf
[2]Hong Kong Monetary Authority. (2025, May). Draft guideline on supervision of licensed stablecoin issuers. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf
文中引用出處
[1]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5
[2]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5
[3]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.3
[4]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.3
[5]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.4
[6]Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf, p. 13, 3.6.2
[7]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.3
[8]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.4
[9]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 10, 3.1.1
[10]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 12, 3.4.1
[11]Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf, p. 9, 3.2.1
[12]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 11, 3.2.3
[13]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 11, 3.2.5
[14]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 38, 6.8.2
[15]Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf, p. 13, 3.6.2
[16]Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf, p. 11, 3.4.2
[17]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 20, 6.5.2
[18]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5
[19]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 51, 8.1.1
[20]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 22, 6.5.8
[21]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 23, 6.5.8(ii)
[22]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 23, 6.5.8(iv)
[23]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 22, 6.5.8(ii)
[24]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 24, 6.5.8(vii)
[25]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 25, 6.5.8(x)
[26]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 21, 6.5.5
[27]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 24 6.5.8(ix)
[28]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 34 6.5.20(ii)
[29]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 42, 6.8.16
[30]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf, p. 42, 6.8.16
