技術指導：針對香港穩定幣發行人的智能合約實施指南

隨著《穩定幣條例》的正式通過，香港金融管理局(HKMA) 於2025 年5 月26 日發布了《持牌穩定幣發行人監管指引（草案）》，旨在確保本地穩定幣生態的穩定、安全與合規運作。該指引詳盡列明了持牌穩定幣發行人必須持續遵守的監理要求與營運標準。

近期，越來越多機構就智慧合約的合規實施問題向慢霧安全團隊(SlowMist) 諮詢。為協助發行人更好地理解和部署合規的智能合約體系，我們特別發布了《面向香港穩定幣發行人的智能合約實施指南》，以提供清晰的技術路徑與實踐建議，支持香港穩定幣生態的健康發展。

第一部分基礎架構與合規策略

本部分旨在為穩定幣系統奠定高層架構的基石，這些架構決策完全由香港金融管理局(HKMA) 框架中最根本的要求所驅動。在此處做出的選擇將決定整個實施路徑，確保從設計之初就將合規性深度嵌入技術堆疊中。

1. 底層分散式帳本的選擇

監管指令

持牌人必須評估其所使用的底層分散式帳本技術(DLT) 的穩健性。此評估涵蓋安全基礎設施、對常見攻擊（如51% 攻擊）的抵禦能力、交易最終性保障以及共識演算法的可靠性¹ 。

慢霧(SlowMist) 技術解讀

這並非一項簡單的技術偏好選擇，而是一項核心的合規任務。底層區塊鏈的選擇必須經過正式的盡職調查，整個評估過程也需被詳細記錄，以便在監管審查時提供充分理據。底層帳本的選擇過程實際上為整個穩定幣系統的安全性與穩定性奠定了基調。

香港金管局對帳本穩健性的強調，實質上是在勸誡發行方避免採用未經市場驗證、中心化程度過高或安全性存疑的新興區塊鏈。證明其安全性與穩定性的責任完全由發行方承擔。如果發行方選擇了安全性尚未被廣泛驗證的鏈，就必須設計並實施額外的補償性控制措施。

實施指南

優先選擇成熟的公有鏈：建議優先選用如Ethereum、Arbitrum 等成熟且具備高安全性的公有區塊鏈。這類網絡憑藉其久經考驗的韌性、龐大的驗證節點網絡以及持續的公眾監督，具備天然優勢。其高昂的攻擊成本（經濟安全性）可直接回應監管對抵禦51% 攻擊及保障交易最終性的關切。
替代方案的嚴格評估：若考慮採用聯盟鍊或其他類型的分散式帳本，必須進行嚴謹且可量化的對比分析，例如慢霧安全審計，以證明其安全標準不低於，甚至優於主流的公有鏈。
風險評估文件：評估報告必須全面涵蓋其抵禦常見攻擊的能力、共識演算法類型，以及與程式碼缺陷、漏洞、漏洞利用及其他威脅相關的風險² ，並詳細分析這些風險如何對穩定幣的發行、贖回及日常營運構成潛在影響。此文件是向監理機關證明技術選型審慎性的關鍵文件。

2. 核心代幣標準與監管功能擴展

監管指令

監管文件並未指定某一特定的代幣標準（如ERC-20）。然而，文件強制要求實現一系列核心管理功能，包括鑄幣(mint)、銷毀(burn)、升級(upgrade)、暫停(pause)、恢復(resume)、凍結(freeze)、黑名單(blacklist)、白名單(whitelist) 等操作³ 。

慢霧(SlowMist) 技術解讀

香港金管局事實上定義了一個功能遠超過ERC-20 標準的「監管增強型」代幣標準。該標準不僅要求具備基礎的代幣流轉功能，更強調操作安全性、權限可控制性和風險可追溯性。為了在滿足合規要求的同時最大限度地保障安全性，最高效且最穩妥的開發路徑，是採用經過廣泛審計、社區公認的標準庫（如OpenZeppelin），並在此基礎上進行功能擴展。

實施指南

基礎標準：採用ERC-20 作為基礎標準，以確保代幣的同質化和在更廣泛生態系統中的互通性。
功能擴充：必須整合以下功能模組，以滿足法規要求：

Pausable：用於實現所有代幣活動的全域暫停與恢復功能，這是應對重大安全事件的核心工具。

Mintable：用於實現持牌發行人需透過受控流程鑄造新代幣，並確保代幣發行量嚴格對應足額法幣儲備資產。

Burnable：提供銷毀代幣的功能。在具體的實作中，此功能將是受嚴格權限控制的，而非允許任意使用者自行銷毀。

Freezable：用於暫停特定帳戶的代幣轉移功能（如涉及可疑交易）。

Whitelist：用於實施額外的安全措施，僅允許透過盡職調查和批准的地址參與核心操作（如接收新鑄代幣⁴ ）。

Blacklist：用於實現對涉及非法活動（如洗錢、詐欺）的地址實施交易禁令，禁止其發送/ 接收代幣。黑名單管理需與AML / CFT 系統連動，即時監控可疑交易。

AccessControl：這是實現精細化、基於角色的權限管理系統的基礎。所有管理功能都必須透過此模組進行權限控制，以滿足職責分離的要求⁵ 。

3. 主要合規模式：黑名單與白名單的選擇

監管指令

關於持續監控，反洗錢/ 打擊恐怖分子資金籌集(AML / CFT) 的諮詢文件提出了多種措施，其中包括“將被識別為受制裁或與非法活動相關的錢包地址列入黑名單”，或者採取更嚴格的“對穩定幣持有人的錢包地址實行白名單制，或採用閉環模式” ⁶ 。

慢霧(SlowMist) 技術解讀

這是整個系統架構中最關鍵的決策點，它直接決定了穩定幣的開放性、實用性以及合規作業的複雜性。

黑名單模式：一種「預設開放」的模式。所有地址預設可以自由交易，只有那些被明確識別並添加至鏈上黑名單的地址，才會被限制。
白名單模式：一種「預設為關閉」的閉環模式。任何地址，除非經過發行方明確的盡職調查和批准，並被添加至鏈上白名單，否則無法持有或接收代幣。

儘管白名單模式提供了AML（反洗錢）控制能力，但對於一個旨在被廣泛使用的穩定幣而言，嚴格的白名單制度意味著穩定幣只能在預先審查過的參與者之間流轉，這使其更像一個封閉的銀行賬本系統，而非一種靈活的數字貨幣。

因此，同樣被監管明確提及的黑名單模式，結合監管所要求的強大鏈下分析工具，構成了更平衡的方案。它既滿足了監管要求，也保留了資產的實用性。

在設計上，系統可以建構成可升級的，或同時實現兩種模式，以便在未來監管收緊或業務模式變更時，能夠平滑過渡或切換至白名單模式。

實施指南

黑名單模式（預設推薦方案） ：

優點：具有更高的實用性，能夠與廣闊的去中心化金融(DeFi) 生態系統無縫互通，為使用者提供更低的使用門檻和更流暢的體驗。

缺點：合規性高度依賴強大的、即時的鏈下監控分析能力，以便及時發現並封鎖非法位址。
實作方式：在智慧合約的轉帳函數中，增加邏輯檢查，確保交易的發送方(from) 和接收方(to) 位址均未被記錄在黑名單中。

白名單模式

優點：提供最高等級的AML / CFT 控制，實現了事前預防，而非事後補救。

缺點：極大地限制了穩定幣的通用性和採納率，為管理白名單帶來了巨大的營運開銷，可能使其難以成為一種被廣泛接受的交易媒介。

實作方式：在智慧合約的轉帳函數中，增加邏輯檢查，要求交易的傳送者(from) 和接收者(to) 位址都必須存在於白名單中。建議開發專用Web 使用者後台系統進行操作，增加操作的便利性。

第二部分智能合約實現

本部分為智慧合約的核心功能提供了一份詳盡的藍圖，將複雜的監管要求轉化為具體的程式碼級邏輯、安全模式和操作協議。

1. 設計精細化的門禁系統

監管指令

高風險操作的設計必須「防止任何單一方能夠單方面執行相關操作（例如，透過多重簽章協議）」 ⁷ 。不同操作的職責應充分隔離。

慢霧(SlowMist) 技術解讀

這意味著，一個強大且基於角色的存取控制系統(RBAC) 是強制性的。任何形式的單一「所有者」或「管理員」私鑰，都是不合規的。

實施指南

必須定義一系列清晰的角色，並將這些角色分配給不同的、由多重簽名錢包控制的實體或員工，以實現職責分離，最大限度降低單一故障點或合謀操縱的風險⁸ 。每個角色應僅限於特定職能，所有作業需多簽章授權，並確保無單一員工同時持有多個高風險角色。所有操作需記錄日誌，並接受年度第三方審計，權限分配由管理員或董事會監督。

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