Nguồn: Công nghệ SlowMist
Liên kết gốc: https://mp.weixin.qq.com/s/3KGxo7PVvNHfcMcc8KCfcw
Với việc chính thức thông qua Sắc lệnh stablecoin , Cơ quan Quản lý Tiền tệ Hồng Kông (HKMA) đã ban hành "Dự thảo Chỉ dẫn Giám sát các Tổ chức Phát hành Stablecoin được Cấp phép" vào ngày 26 tháng 5 năm 2025, nhằm đảm bảo tính ổn định, bảo mật và tuân thủ của hệ sinh thái stablecoin địa phương. Chỉ dẫn này nêu chi tiết các yêu cầu pháp lý và tiêu chuẩn hoạt động mà các tổ chức phát hành stablecoin được cấp phép phải tiếp tục tuân thủ.
Gần đây, ngày càng nhiều tổ chức tham khảo ý kiến đội ngũ bảo mật SlowMist về việc triển khai hợp đồng thông minh tuân thủ. Để giúp các đơn vị phát hành hiểu rõ hơn và triển khai các hệ thống hợp đồng thông minh tuân thủ, chúng tôi đã phát hành riêng "Hướng dẫn Triển khai Hợp đồng Thông minh dành cho Đơn vị Phát hành Stablecoin tại Hồng Kông" nhằm cung cấp các lộ trình kỹ thuật rõ ràng và các đề xuất thiết thực, hỗ trợ sự phát triển lành mạnh của hệ sinh thái stablecoin tại Hồng Kông.
Phần I Chiến lược cơ sở hạ tầng và tuân thủ
Phần này nhằm mục đích đặt nền tảng kiến trúc cấp cao cho hệ thống stablecoin. Các quyết định về kiến trúc này hoàn toàn dựa trên các yêu cầu cơ bản nhất trong khuôn khổ của Cơ quan Tiền tệ Hồng Kông (HKMA). Các lựa chọn được đưa ra ở đây sẽ quyết định toàn bộ lộ trình triển khai, đảm bảo tính tuân thủ được tích hợp độ sâu vào hệ thống công nghệ ngay từ đầu quá trình thiết kế.
1. Lựa chọn sổ cái phân tán cơ bản
Chỉ thị quản lý
Người được cấp phép phải đánh giá tính vững chắc của công nghệ sổ cái phân tán(DLT) cơ bản mà họ sử dụng. Đánh giá này bao gồm cơ sở hạ tầng bảo mật, khả năng phục hồi trước các cuộc tấn công phổ biến (chẳng hạn như các cuộc tấn công 51%), đảm bảo tính cuối cùng của giao dịch và độ tin cậy của thuật toán đồng thuận1.
Giải thích về công nghệ SlowMist
Đây không chỉ đơn giản là lựa chọn công nghệ ưu tiên, mà còn là một nhiệm vụ tuân thủ cốt lõi. Việc lựa chọn blockchain nền tảng phải trải qua quá trình thẩm định chính thức, và toàn bộ quá trình đánh giá phải được ghi lại chi tiết để cung cấp đủ căn cứ trong quá trình xem xét theo quy định. Quá trình lựa chọn sổ cái nền tảng thực sự quyết định tính bảo mật và ổn định của toàn bộ hệ thống stablecoin.
Việc HKMA nhấn mạnh vào tính vững chắc của sổ cái về cơ bản là một lời cảnh báo đối với các đơn vị phát hành nhằm tránh áp dụng blockchain mới nổi chưa được chứng minh, quá tập trung hoặc có tính bảo mật đáng ngờ. Trách nhiệm chứng minh tính bảo mật và ổn định của chúng hoàn toàn thuộc về đơn vị phát hành. Nếu đơn vị phát hành chọn Chuỗi chưa được xác minh rộng rãi về tính bảo mật, họ phải thiết kế và triển khai các biện pháp kiểm soát bổ sung.
Hướng dẫn thực hiện
Ưu tiên Chuỗi công khai trưởng thành: Nên ưu tiên blockchain công khai trưởng thành và có độ bảo mật cao như Ethereum và Arbitrum . Các mạng lưới này có lợi thế tự nhiên nhờ khả năng phục hồi đã được chứng minh, mạng lưới nút xác minh lớn và sự giám sát công khai liên tục. Chi phí tấn công cao (an ninh kinh tế) của chúng có thể đáp ứng trực tiếp các mối lo ngại về mặt pháp lý trong việc chống lại các cuộc tấn công 51% và đảm bảo tính toàn vẹn của giao dịch.
Đánh giá nghiêm ngặt các giải pháp thay thế: Nếu xem xét Chuỗi liên kết hoặc loại sổ cái phân tán khác, cần phải tiến hành phân tích so sánh nghiêm ngặt và có thể định lượng, chẳng hạn như kiểm toán bảo mật SlowMist , để chứng minh rằng tiêu chuẩn bảo mật của nó không thấp hơn hoặc thậm chí không tốt hơn các Chuỗi công khai chính thống.
Tài liệu Đánh giá Rủi ro : Báo cáo đánh giá phải bao quát toàn diện khả năng chống lại các cuộc tấn công phổ biến, loại thuật toán đồng thuận và rủi ro liên quan đến lỗi mã, lỗ hổng bảo mật, khai thác lỗ hổng bảo mật và các mối đe dọa khác2, đồng thời phân tích chi tiết cách rủi ro này có thể ảnh hưởng đến việc phát hành, quy đổi và hoạt động hàng ngày của stablecoin. Tài liệu này là một tài liệu quan trọng để chứng minh với các cơ quan quản lý về sự thận trọng trong việc lựa chọn công nghệ.
2. Tiêu chuẩn token cốt lõi và mở rộng chức năng quản lý
Chỉ thị quản lý
Tài liệu quy định không nêu rõ tiêu chuẩn token cụ thể (chẳng hạn như ERC-20). Tuy nhiên, tài liệu yêu cầu triển khai sê-ri các chức năng quản lý cốt lõi, bao gồm đúc, đốt, nâng cấp, đóng băng danh sách đen, đưa vào danh sách trắng, v.v.3.
Giải thích về công nghệ SlowMist
Trên thực tế, Cơ quan Quản lý Tiền tệ Hồng Kông đã xác định một tiêu chuẩn token"được tăng cường về mặt quy định" với các chức năng vượt xa tiêu chuẩn ERC-20. Tiêu chuẩn này không chỉ yêu cầu các chức năng lưu thông token cơ bản mà còn nhấn mạnh đến bảo mật vận hành, khả năng kiểm soát quyền hạn và khả năng truy xuất rủi ro. Để tối đa hóa bảo mật đồng thời đáp ứng các yêu cầu tuân thủ, con đường phát triển hiệu quả và an toàn nhất là áp dụng một thư viện tiêu chuẩn được cộng đồng công nhận và kiểm toán rộng rãi (chẳng hạn như OpenZeppelin) và mở rộng các chức năng trên cơ sở này.
Hướng dẫn thực hiện
Tiêu chuẩn cơ bản: ERC-20 được áp dụng làm tiêu chuẩn cơ bản để đảm bảo tính đồng nhất của token và khả năng tương tác trong hệ sinh thái rộng lớn hơn.
Mở rộng chức năng: Mô-Đun chức năng sau đây phải tích hợp để đáp ứng các yêu cầu theo quy định:
Có thể tạm dừng: Được sử dụng để triển khai chức năng tạm dừng và tiếp tục toàn cục của tất cả các hoạt động token. Đây là công cụ cốt lõi để ứng phó với các sự cố bảo mật lớn.
Có thể đúc: Được sử dụng để thực hiện yêu cầu rằng các đơn vị phát hành được cấp phép đúc token mới thông qua một quy trình được kiểm soát và đảm bảo rằng số lượng token được phát hành phải tương ứng chặt chẽ với đủ tài sản dự trữ tiền tệ hợp pháp.
Burnable: Cung cấp chức năng đốt token. Trong bản triển khai cụ thể, chức năng này sẽ được kiểm soát chặt chẽ bằng quyền, thay vì cho phép bất kỳ người dùng nào tự đốt.
Có thể đóng băng: Được sử dụng để tạm dừng chức năng chuyển token của một tài khoản cụ thể (chẳng hạn như những tài khoản liên quan đến giao dịch đáng ngờ).
Danh sách trắng: Được sử dụng để triển khai các biện pháp bảo mật bổ sung, chỉ cho phép các địa chỉ đã vượt qua quá trình thẩm định và phê duyệt mới được tham gia vào các hoạt động cốt lõi (chẳng hạn như nhận token mới đúc4).
Danh sách đen: Được sử dụng để thực hiện lệnh cấm giao dịch đối với các địa chỉ liên quan đến hoạt động bất hợp pháp (như rửa tiền, gian lận), cấm họ gửi/nhận token. Việc quản lý danh sách đen cần được liên kết với hệ thống AML/CFT để giám sát các giao dịch đáng ngờ theo thời gian thực.
AccessControl: Đây là cơ sở để triển khai một hệ thống quản lý quyền dựa trên nhân vật được tinh chỉnh. Tất cả các chức năng quản lý phải tuân theo quy trình kiểm soát quyền hạn thông qua mô-đun này để đáp ứng các yêu cầu phân quyền5.
3. Mô hình tuân thủ chính: lựa chọn danh sách đen và danh sách trắng
Chỉ thị quản lý
Liên quan đến hoạt động giám sát đang diễn ra, tài liệu tham vấn về Chống rửa tiền/Chống tài trợ khủng bố (AML/CFT) đề xuất nhiều biện pháp, trong đó“đưa các địa chỉ ví được xác định là bị xử phạt hoặc có liên quan đến hoạt động bất hợp pháp vào danh sách đen” hoặc “đưa các địa chỉ ví của người nắm giữ stablecoin vào danh sách trắng hoặc mô hình vòng kín”6.
Giải thích về công nghệ SlowMist
Đây là điểm quyết định quan trọng nhất trong toàn bộ kiến trúc hệ thống, quyết định trực tiếp đến tính minh bạch, tính thực tiễn và tính phức tạp của các hoạt động tuân thủ của stablecoin.
Chế độ danh sách đen: Chế độ "mở mặc định". Tất cả các địa chỉ đều có thể giao dịch tự do theo mặc định, và chỉ những địa chỉ được xác định rõ ràng và được thêm vào danh sách đen trên Chuỗi mới bị hạn chế.
Chế độ danh sách trắng: Chế độ vòng kín được "đóng theo mặc định". Bất kỳ địa chỉ nào cũng không thể nắm giữ hoặc nhận token trừ khi địa chỉ đó đã được bên phát hành kiểm tra và phê duyệt rõ ràng, đồng thời được thêm vào danh sách trắng trên Chuỗi .
Mặc dù mô hình danh sách trắng cung cấp khả năng kiểm soát AML (chống rửa tiền), nhưng đối với một stablecoin được thiết kế để sử dụng rộng rãi, hệ thống danh sách trắng nghiêm ngặt có nghĩa là stablecoin chỉ có thể lưu hành giữa những người tham gia đã được kiểm tra trước, khiến nó giống một hệ thống sổ cái ngân hàng đóng hơn là một loại tiền kỹ thuật số linh hoạt.
Do đó, mô hình danh sách đen, vốn cũng được cơ quan quản lý đề cập rõ ràng, kết hợp với các công cụ phân tích ngoài Chuỗi mạnh mẽ theo yêu cầu của cơ quan quản lý, tạo nên một giải pháp cân bằng hơn. Nó không chỉ đáp ứng các yêu cầu quản lý mà còn duy trì tính thực tiễn của tài sản.
Về mặt thiết kế, hệ thống có thể được xây dựng để có thể nâng cấp hoặc triển khai cả hai chế độ cùng lúc, để có thể chuyển đổi dễ dàng sang chế độ danh sách trắng khi các quy định thắt chặt hoặc mô hình việc kinh doanh thay đổi trong tương lai.
Hướng dẫn thực hiện
Chế độ danh sách đen (giải pháp mặc định được đề xuất):
Ưu điểm: Tính thực tiễn cao hơn và có thể tương tác liền mạch với hệ sinh thái tài chính phi tập trung(DeFi) rộng lớn, mang đến cho người dùng ngưỡng sử dụng thấp hơn và trải nghiệm mượt mà hơn.
Nhược điểm: Việc tuân thủ phụ thuộc rất nhiều vào khả năng giám sát và phân tích ngoài Chuỗi mạnh mẽ, theo thời gian thực để phát hiện và chặn kịp thời các địa chỉ bất hợp pháp.
Phương pháp triển khai: Thêm kiểm tra logic vào hàm chuyển của hợp đồng thông minh để đảm bảo rằng địa chỉ người gửi (từ) và người nhận (đến) của giao dịch không được ghi vào danh sách đen.
Chế độ danh sách trắng
Ưu điểm: Cung cấp mức độ kiểm soát AML/CFT cao nhất, đạt được mục tiêu phòng ngừa thay vì khắc phục.
Nhược điểm: Hạn chế đáng kể tính linh hoạt và khả năng áp dụng của stablecoin, gây ra chi phí vận hành khổng lồ cho việc quản lý danh sách trắng và có thể khiến chúng khó trở thành phương tiện trao đổi được chấp nhận rộng rãi.
Phương pháp triển khai: Thêm kiểm tra logic vào hàm truyền của hợp đồng thông minh, yêu cầu cả địa chỉ người gửi (từ) và người nhận (đến) của giao dịch phải nằm trong danh sách trắng. Khuyến nghị phát triển một hệ thống backend người dùng web chuyên dụng để vận hành nhằm tăng tính tiện lợi.
Phần 2 Triển khai hợp đồng thông minh
Phần này cung cấp bản thiết kế chi tiết về chức năng cốt lõi của hợp đồng thông minh, chuyển đổi các yêu cầu quy định phức tạp thành logic cấp mã, mô hình bảo mật và giao thức vận hành cụ thể.
1. Thiết kế hệ thống kiểm soát ra vào tinh vi
Chỉ thị quản lý
Các hoạt động rủi ro cao phải được thiết kế để “ngăn chặn bất kỳ bên nào có thể đơn phương thực hiện các hoạt động có liên quan (ví dụ: thông qua giao thức đa chữ ký)”7. Trách nhiệm đối với các hoạt động khác nhau phải được phân tách đầy đủ.
Giải thích về công nghệ SlowMist
Điều này có nghĩa là bắt buộc phải có một hệ thống kiểm soát truy cập dựa trên nhân vật(RBAC) mạnh mẽ. Bất kỳ hình thức private key nào của "chủ sở hữu" hoặc "quản trị viên" đều không tuân thủ.
Hướng dẫn thực hiện
Cần xác định và phân công rõ ràng sê-ri tập nhân vật nhân vật cho các thực thể hoặc nhân viên khác nhau được kiểm soát bởi ví đa chữ ký để phân tách nhiệm vụ và giảm thiểu rủi ro lỗi đơn lẻ hoặc thông đồng. 8 Mỗi nhân vật nên được giới hạn trong các chức năng cụ thể, tất cả các hoạt động đều yêu cầu ủy quyền đa chữ ký và đảm bảo không một nhân viên nào nắm giữ nhiều nhân vật rủi ro cao cùng một lúc. Tất cả các hoạt động phải được ghi lại và chịu kiểm toán hàng năm của bên thứ ba, và việc phân bổ quyền phải được giám sát bởi quản trị viên hoặc hội đồng quản trị.
MINTER_ROLE: Chịu trách nhiệm xử lý các hoạt động đúc stablecoin, bao gồm tạo đơn vị token khi nhận được yêu cầu phát hành hợp lệ và đảm bảo rằng hoạt động đúc tiền khớp với mức tăng tương ứng trong nhóm tài sản dự trữ.
BURNER_ROLE: Chịu trách nhiệm xử lý đốt stablecoin , bao gồm đốt các đơn vị token khi nhận được yêu cầu đổi hợp lệ.
PAUSER_ROLE: Chịu trách nhiệm tạm dừng các hoạt động stablecoin, chẳng hạn như tạm dừng chuyển tiền, đúc tiền hoặc đổi tiền khi phát hiện sự kiện bất thường (chẳng hạn như mối đe dọa bảo mật).
RESUME_ROLE: Chịu trách nhiệm tiếp tục hoạt động stablecoin, chẳng hạn như kích hoạt lại việc chuyển tiền, đúc tiền hoặc đổi tiền sau khi sự kiện tạm dừng được giải quyết.
FREEZER_ROLE: Chịu trách nhiệm đóng băng và đóng băng các ví hoặc token cụ thể, chẳng hạn như đóng băng tạm thời tài sản khi phát hiện các hoạt động đáng ngờ (như rủi ro rửa tiền).
WHITELISTER_ROLE: Chịu trách nhiệm quản lý danh sách trắng, bao gồm thêm hoặc xóa các địa chỉ ví được phép, chẳng hạn như giới hạn việc đúc tiền vào các địa chỉ có trong danh sách trắng.
BLACKLISTER_ROLE: Chịu trách nhiệm quản lý danh sách đen và xóa danh sách đen, chẳng hạn như đưa các ví đáng ngờ vào danh sách đen để ngăn chặn việc chuyển tiền.
UPGRADER_ROLE: Nếu áp dụng mô hình nâng cấp, người chịu trách nhiệm nâng cấp hợp đồng thông minh, chẳng hạn như cập nhật mã hợp đồng để sửa lỗ hổng hoặc thêm tính năng.
Bảng 1: Ma trận kiểm soát truy cập dựa trên nhân vật(Ma trận RBAC)
Bảng sau đây cung cấp thông số kỹ thuật rõ ràng, trực quan để các nhà phát triển và kiểm toán sử dụng, ánh xạ rõ ràng từng hoạt động có đặc quyền với nhân vật và loại kiểm soát cần thiết.
2. Cơ chế phát hành (đúc tiền)
Chỉ thị quản lý
Việc phát hành phải “thận trọng và mạnh mẽ”. Việc đúc tiền phải “đi kèm với mức tăng tương ứng trong quỹ dự trữ tài sản cơ sở”. Bên phát hành chỉ nên phát hành cho khách hàng sau khi đã nhận được tiền và có yêu cầu phát hành hợp lệ9.
Giải thích về công nghệ SlowMist
Bản thân hợp đồng thông minh không thể và không cần phải thực thi yêu cầu "dự trữ đầy đủ". Thay vào đó, chúng đóng nhân vật như một sổ cái được kiểm soát, trong đó cơ quan phát hành là điểm kiểm soát chính. Tuân thủ dự trữ đầy đủ là một hoạt động có thể kiểm toán xác minh được, diễn ra ngoài Chuỗi . Quy định ràng buộc việc phát hành với hai sự kiện ngoài Chuỗi : "yêu cầu phát hành hợp lệ" và "tiền đã nhận". Do đó, chức năng đúc trên Chuỗi phải được thiết kế để chỉ được gọi bởi một thực thể đáng tin cậy (tức là chính đơn vị phát hành) có thể xác minh rằng các điều kiện Chuỗi này đã được đáp ứng.
Hướng dẫn thực hiện
Kiểm tra trước: Trước khi thực hiện chức năng đúc tiền, chức năng này phải kiểm tra xem địa chỉ đích có nằm trong danh sách đen hay trạng thái đóng băng hay không.
Quy trình hoạt động:
Thẩm định ngoài Chuỗi: Khách hàng hoàn tất tất cả các quy trình KYC và CDD ngoài Chuỗi bắt buộc10. Ngoài ra, các quy định về AML/CFT yêu cầu CDD11 đối với khách hàng thiết lập mối quan hệ việc kinh doanh hoặc thực hiện các giao dịch không thường xuyên vượt quá một ngưỡng nhất định (ví dụ: 8.000 đô la Hồng Kông).
Nhận tiền: Khách hàng chuyển số tiền hợp pháp tương đương vào tài khoản ngân hàng do đơn vị phát hành chỉ định.
Xác minh nội bộ: Hệ thống nội bộ của bên phát hành xác nhận việc nhận tiền và cập nhật hồ sơ kế toán về tài sản dự trữ cho phù hợp.
Thực hiện trên Chuỗi: Đội ngũ vận hành tạo và ký giao dịch đa chữ ký, gọi hàm token đúc hợp đồng thông minh và gửi các stablecoin mới đúc đến địa chỉ ví đã đăng ký và xác minh trước của khách hàng.
3. Cơ chế cứu chuộc ( đốt )
Chỉ thị quản lý
Người được cấp phép phải xử lý các yêu cầu đổi tiền hợp lệ “càng sớm càng tốt và trong vòng một ngày làm việc kể từ khi nhận được yêu cầu”12. Rút tài sản dự trữ phải “tương ứng với mức giảm tương ứng trong mệnh giá của stablecoin được chỉ định đang lưu hành”13.
Giải thích về công nghệ SlowMist
Quy trình đổi thưởng là một quy trình hai bước bao gồm các tương tác trên Chuỗi và ngoài Chuỗi. Trong quá trình đổi thưởng, cân nhắc đến rủi ro chuyển tiền fiat không thành công, đốt token phải được thực hiện sau khi quyết toán fiat được xác nhận, chứ không phải trước đó. Điều này bảo vệ đơn vị phát hành khỏi đốt token sớm do việc đổi thưởng cuối cùng không thành công.
Nếu bên phát hành đốt token trước và giao dịch chuyển khoản ngân hàng không thành công, bên phát hành sẽ phải chịu trách nhiệm mà không có tài sản tương ứng; ngược lại, nếu bên phát hành thanh toán bằng tiền pháp định trước nhưng không đốt token tương ứng, bên phát hành cũng sẽ chịu lỗ.
Do đó, trong quá trình đổi token, người dùng cần chuyển token đến một địa chỉ được chỉ định do bên phát hành kiểm soát, sau đó bên phát hành sẽ đốt sau khi hoàn tất thanh toán bằng tiền pháp định. Mô hình này cho phép người dùng "khóa"token của mình để đổi, và bên phát hành sẽ chỉ đốt token sau khi hoàn tất nghĩa vụ thanh toán bằng tiền pháp định, do đó mang lại quy trình vận hành an toàn hơn cho cả hai bên.
Hướng dẫn thực hiện
Chuẩn bị đổi: Trước tiên, người dùng cần chuyển token cần đổi đến một địa chỉ được chỉ định do đơn vị phát hành kiểm soát.
Quy trình hoạt động:
Yêu cầu ngoài Chuỗi: Người dùng gửi yêu cầu đổi thưởng ngoài Chuỗi thông qua nền tảng của đơn vị phát hành. Trước khi xử lý yêu cầu, đơn vị phát hành phải thực hiện thẩm định khách hàng (CDD) phù hợp đối với khách hàng.
Xác minh hệ thống: Hệ thống của bên phát hành xác minh tính hợp lệ của yêu cầu và kiểm tra xem người dùng đã hoàn tất thao tác chuyển mã token tương ứng trên Chuỗi hay chưa.
Thanh toán bằng tiền pháp định: Bên phát hành chuyển số tiền pháp định tương đương vào tài khoản ngân hàng đã đăng ký và xác minh trước của người dùng.
Đốt trên Chuỗi : Sau khi xác nhận việc chuyển tiền fiat thành công, ví đa chữ ký chứa BURNER_ROLE sẽ gọi hàm đốt đốt số lượng token tương ứng từ địa chỉ đã chỉ định.
4. Thực hiện các biện pháp kiểm soát khẩn cấp: đình chỉ và đóng băng
Chỉ thị quản lý
Hợp đồng phải hỗ trợ các hành động như tạm dừng, tiếp tục, đưa vào danh sách đen, bỏ danh sách đen, đóng băng và đóng băng. Đây là những thành phần chính của khuôn khổ quản lý sự cố14.
Giải thích về công nghệ SlowMist
Tài liệu quy định liệt kê "tạm dừng" và "đóng băng" là hai mục riêng biệt, cho thấy các cơ quan quản lý kỳ vọng các đơn vị phát hành có khả năng ứng phó sự cố linh hoạt, đa tầng. Tạm dừng là một biện pháp ứng phó với các cuộc khủng hoảng lớn (chẳng hạn như khai thác hợp đồng), trong khi đóng băng là một công cụ chính xác để giải quyết các vấn đề pháp lý hoặc tuân thủ cụ thể (chẳng hạn như lệnh của tòa án đối với một tài khoản duy nhất). Hai biện pháp này khác biệt về mặt chức năng và phải được triển khai riêng biệt:
Tạm dừng: "Công tắc dừng khẩn cấp" toàn cầu có chức năng dừng giữa chừng lập tức mọi chức năng cốt lõi của hợp đồng, bao gồm chuyển nhượng, đúc tiền và đốt.
Đóng băng: Một hạn chế ở cấp độ tài khoản ngăn một địa chỉ cụ thể gửi hoặc nhận token, nhưng không ảnh hưởng đến hoạt động bình thường của các địa chỉ khác trong mạng.
Hướng dẫn thực hiện
Chức năng tạm dừng: Chỉ được gọi bởi ví đa chữ ký chứa PAUSER_ROLE, chức năng này được sử dụng để dừng giữa chừng chức năng hợp đồng trên toàn cầu. Các điều kiện kích hoạt bao gồm phát hiện các sự kiện bất thường (chẳng hạn như tấn công mạng hoặc không khớp tài sản dự trữ), cần được hội đồng quản trị hoặc ban quản lý cấp cao phê duyệt. Chức năng khôi phục được xử lý bởi một RESUME_ROLE riêng biệt để phân tách nhiệm vụ.
Hàm Đóng băng: Được gọi bởi ví đa chữ ký chứa FREEZER_ROLE để hạn chế việc chuyển tiền đến một địa chỉ cụ thể. Điều kiện kích hoạt bao gồm các hoạt động đáng ngờ (chẳng hạn như cảnh báo AML hoặc lệnh của tòa án), yêu cầu xác minh Chuỗi chuỗi trước khi thực hiện. Đóng băng được xử lý bởi cùng nhân vật, nhưng yêu cầu xác minh kiểm toán bổ sung và các thông báo liên quan để ngăn chặn việc lạm dụng.
5. Cơ chế sàng lọc địa chỉ và danh sách đen
Chỉ thị quản lý
Người được cấp phép nên thực hiện các bước như "đưa các địa chỉ ví được xác định là bị xử phạt hoặc liên quan đến hoạt động bất hợp pháp vào danh sách đen"15. Đây là biện pháp kiểm soát cốt lõi để giám sát liên tục và các bên phát hành nên sử dụng các giải pháp kỹ thuật như công cụ phân tích blockchain để xác định các giao dịch liên quan đến hoạt động bất hợp pháp hoặc đáng ngờ16.
Giải thích về công nghệ SlowMist
Đây phải là một cơ chế thực thi trên Chuỗi. Việc chỉ đưa ra cảnh báo ngoài Chuỗi là chưa đủ, giao dịch phải được ngăn chặn ngay từ cấp độ giao thức. Yêu cầu về danh sách đen yêu cầu các bên được cấp phép phải áp dụng các công cụ/dịch vụ phân tích blockchain thời gian thực (như MistTrack , Chainalysis, Elliptic). Đội ngũ tuân thủ sử dụng kết luận rút ra từ các công cụ này để chuyển đổi chúng một cách an toàn thành các giao dịch được ký bằng nhiều chữ ký nhằm cập nhật danh sách đen Chuỗi.
Hướng dẫn thực hiện
Triển khai chức năng: Các chức năng triển khai thêm danh sách đen và xóa danh sách đen và chỉ có thể được gọi bởi ví đa chữ ký có chứa BLACKLISTER_ROLE.
Hạn chế chuyển nhượng: các địa chỉ nằm trong danh sách đen bị cấm chuyển/nhận token.
Quy trình vận hành: Công cụ phân tích phát ra cảnh báo, kích hoạt quy trình đánh giá tuân thủ nội bộ. Sau khi đội ngũ tuân thủ xem xét và xác nhận, ví đa chữ ký BLACKLISTER_ROLE sẽ khởi tạo giao dịch bổ sung danh sách đen.
6. Nâng cấp của Hợp đồng thông minh
Chỉ thị quản lý
Tất cả các kiến trúc hợp đồng thông minh liên quan đến stablecoin đều có thể áp dụng “nâng cấp”17. Bất cứ khi nào một hợp đồng thông minh được “nâng cấp”, nó phải kiểm toán.
Giải thích về công nghệ SlowMist
Nâng cấp theo thiết kế là một yêu cầu cốt lõi để đảm bảo tính linh hoạt về mặt kỹ thuật và quản lý rủi ro trong khuôn khổ pháp lý. Nó cho phép các bên phát hành cập nhật logic mà không làm gián đoạn trạng thái hợp đồng hiện có để đáp ứng các bản sửa lỗi, mở rộng chức năng hoặc thay đổi về quy định.
Tuy nhiên, điều này cũng mang lại rủi ro cao: quy trình nâng cấp có thể bị lạm dụng, gây ra những thay đổi bất ngờ trong hành vi hợp đồng hoặc tạo ra các lỗ hổng bảo mật mới. Do đó, nâng cấp phải được coi là hoạt động có rủi ro cao và cần được thiết kế để ngăn chặn việc thực thi đơn phương bởi một bên (chẳng hạn như thông qua các giao thức đa chữ ký) và tích hợp với các hệ thống kiểm soát truy cập dựa trên nhân vật (RBAC).
Kiểm toán được các cơ quan quản lý nhấn mạnh có nghĩa là nâng cấp không chỉ là thay thế mã mà còn là các sự kiện được kiểm soát trong các quy trình quản lý thay đổi nghiêm ngặt để đảm bảo rằng các hợp đồng logic mới được bên thứ ba xác minh trước khi triển khai và không có lỗ hổng hoặc lỗi bảo mật.
Hướng dẫn thực hiện
Mô hình proxy: Đối với các hợp đồng thông minh kiểu EVM, có thể áp dụng mô hình proxy ERC-1967 hoàn thiện để đạt được nâng cấp.
Kiểm soát quyền: Chức năng nâng cấp chỉ có thể được gọi bởi ví đa chữ ký có UPGRADER_ROLE.
Quy trình quản lý thay đổi: Theo yêu cầu của quy định, một quy trình quản lý thay đổi nghiêm ngặt phải được hoàn tất trước khi đề xuất bất kỳ nâng cấp, trong đó gồm kiểm toán bảo mật toàn diện, độc lập của bên thứ ba đối với hợp đồng logic mới.
7. Nhật ký sự kiện trên Chuỗi để phân tích và báo cáo
Chỉ thị quản lý
Người được cấp phép phải thiết lập “hệ thống thông tin và kế toán” mạnh mẽ để “ghi lại tất cả các hoạt động việc kinh doanh, bao gồm Chuỗi và ngoài Chuỗi, một cách kịp thời và chính xác” và “duy trì các dấu vết kiểm toán phù hợp”19.
Giải thích về công nghệ SlowMist
Hợp đồng thông minh là nguồn dữ liệu chính xác cho mọi hoạt động trên Chuỗi. Chúng phải phát ra các sự kiện chi tiết cho mọi thay đổi trạng thái quan trọng để các hệ thống Chuỗi có thể ghi lại, giám sát và tạo báo cáo. Những sự kiện này tạo ra một nhật ký bất biến và vĩnh viễn trên blockchain . Nhật ký này là nguồn dữ liệu chính cho tất cả các hệ thống giám sát, kế toán và báo cáo Chuỗi , cung cấp nền tảng vững chắc cho kiểm toán .
Hướng dẫn thực hiện
Ngoài các sự kiện Chuyển giao và Phê duyệt theo yêu cầu của tiêu chuẩn ERC-20, hợp đồng phải xác định và phát hành các sự kiện tùy chỉnh cho tất cả các hành động quản lý và thay đổi trạng thái:
Sự kiện đúc/ đốt token
Sự kiện tạm dừng / tiếp tục hợp đồng
Sự kiện BlacklistAdded / BlacklistRemoved
Sự kiện WhitelistAdded / WhitelistRemoved
Sự kiện đóng băng/ đóng băng
Sự kiện nhân vật/ RoleRevoked
Sự kiện nâng cấp hợp đồng
Phần III An toàn vận hành và Quản lý vòng đời
Phần này trình bày chi tiết các quy trình bảo mật vận hành quan trọng liên quan đến hợp đồng thông minh. Các quy trình này cũng quan trọng như chính mã nguồn và cần thiết để đạt được tính bảo mật và tuân thủ toàn diện.
1. Kiến trúc quản lý khóa an toàn
Chỉ thị quản lý
Đây là một trong những lĩnh vực quy định chi tiết và nghiêm ngặt nhất. Người được cấp phép phải thực hiện các biện pháp kiểm soát chặt chẽ đối với toàn bộ vòng đời của private key, bao gồm tạo, lưu trữ, sử dụng, sao lưu và đốt. “Các khóa riêng và/hoặc private key quan trọng” (ví dụ: khóa dùng để nâng cấp, quản lý nhân vật, đúc tiền quy mô lớn) yêu cầu các tiêu chuẩn bảo mật cao hơn, bao gồm tạo ngoại tuyến trong “hoàn cảnh cách ly không khí”21 và lưu trữ trong mô-đun bảo mật phần cứng (HSM)22.
Giải thích về công nghệ SlowMist
HKMA về cơ bản đang yêu cầu áp dụng chế độ bảo mật "mức độ tài chính truyền thống" cho các hoạt động crypto gốc. Chi phí và độ phức tạp của việc triển khai mức độ quản lý khóa này là rất lớn và sẽ trở thành một phần hoạt động cốt lõi của bất kỳ tổ chức phát hành được cấp phép nào. Mô hình bảo mật này vượt xa các thông lệ tiêu chuẩn của các dự án DeFi thông thường. Tài liệu quy định cung cấp danh sách kiểm tra chi tiết để quản lý khóa, đề cập rõ ràng đến HSM (mô-đun bảo mật phần cứng), hoàn cảnh air-gapped, nghi lễ khóa và đa chữ ký. Điều này thực sự yêu cầu xây dựng kiến trúc quản lý khóa phòng thủ chuyên sâu: các tài khoản được giữ trong ví phần cứng đóng vai trò là người ký ví đa chữ ký, bản thân các ví này giữ nhân vật quản trị trên hợp đồng thông minh. Đối với nhân vật bảo mật cao nhất, bản thân các ví phần cứng này phải được quản lý trong một hoàn cảnh air-gapped được chỉ định, an toàn về mặt vật lý. Toàn bộ kiến trúc xây dựng một hệ thống phòng thủ nhiều lớp để chống lại sự xâm phạm khóa.
Hướng dẫn thực hiện
Tạo khóa: phải được hoàn thành thông qua “lễ trao Key ” được ghi chép đầy đủ23 trong hoàn cảnh an toàn về mặt vật lý, khép kín và hoàn toàn tách biệt với thế giới bên ngoài.
Lưu trữ khóa: Tất cả nhân vật quản trị phải được kiểm soát bởi ví đa chữ ký. Private key được sử dụng bởi người ký của các ví đa chữ ký này phải được lưu trữ trong HSM hoặc ví phần cứng an toàn khác. Đối với nhân vật, khóa tương ứng của họ phải được lưu trữ trong một hệ thống air-gap, tách biệt vật lý với bất kỳ hoàn cảnh trực tuyến nào.
Sử dụng khóa: Chính sách đa chữ ký phải được áp dụng. Đối với chữ ký giao dịch liên quan đến "private key quan trọng", nhân sự liên quan có thể cần phải có mặt trực tiếp24.
Sao lưu và Phục hồi: Bản sao lưu của các phân đoạn khóa hoặc Cụm từ hạt giống phải được lưu trữ tại nhiều địa điểm an toàn và phân tán về mặt địa lý trong Hồng Kông (hoặc các địa điểm được cơ quan quản lý phê duyệt) và trong bao bì chống giả mạo25.
2. Hoàn tất quá trình triển khai và giám sát thời gian chạy
Chỉ thị quản lý
Người được cấp phép phải thuê một "bên thứ ba đủ điều kiện kiểm toán kiểm toán hợp đồng thông minh" ít nhất hàng năm và sau lần lần triển khai, tái triển khai hoặc nâng cấp. Kiểm toán phải đảm bảo hợp đồng được triển khai đúng cách, hoạt động như mong đợi và không chứa bất kỳ lỗ hổng bảo mật hoặc lỗi nào "ở mức độ bảo mật cao"26. Người được cấp phép phải triển khai các biện pháp để giám sát việc sử dụng Cụm từ hạt giống và/hoặc khóa private key(ví dụ: kiểm tra IP, giám sát hành vi, cảnh báo hoạt động quan trọng, sàng lọc thiết bị, giám sát Chuỗi, giám sát kiểm soát truy cập, v.v.)27. Và người được cấp phép phải thực hiện các biện pháp thích hợp để giám sát thông tin tình báo về mối đe dọa nhằm phát hiện các mối đe dọa mới nổi. Thông tin tình báo về mối đe dọa phải được phân tích để các biện pháp giảm thiểu có thể được triển khai kịp thời28.
Giải thích về công nghệ SlowMist
Quy trình triển khai và giám sát thời gian chạy là phần mở rộng trực tiếp của khuôn khổ quy định về quản lý rủi ro kỹ thuật, nhấn mạnh vào việc ngăn ngừa lỗ hổng ngay từ nguồn và giám sát liên tục rủi ro vận hành. Kiểm toán trước khi triển khai yêu cầu hợp đồng thông minh phải được coi là cơ sở hạ tầng quan trọng và phải được đảm bảo không có lỗi thông qua nhiều lớp xác minh (chẳng hạn như kiểm thử đơn vị, kiểm toán độc lập và đóng băng mã), phản ánh việc theo đuổi các tiêu chuẩn "có độ tin cậy cao" của cơ quan quản lý để tránh lỗi mã hoặc khai thác lỗ hổng ảnh hưởng đến việc phát hành, đổi thưởng hoặc hoạt động hàng ngày của stablecoin. Giám sát thời gian chạy tập trung vào phát hiện mối đe dọa theo thời gian thực, kết hợp giám sát việc sử dụng private key(chẳng hạn như phân tích hành vi) và phân tích tình báo mối đe dọa để hình thành cơ chế phản ứng vòng kín. Điều này không chỉ đáp ứng nhu cầu của khuôn khổ quản lý sự cố mà còn đảm bảo hệ thống có thể phản ứng linh hoạt với rủi ro mới nổi. Nhìn chung, việc triển khai kỹ thuật phần này cần tích hợp các công cụ trên Chuỗi và ngoài Chuỗi để tạo thành một dấu vết kiểm toán có thể theo dõi, từ đó chuyển đổi phòng thủ thụ động thành tuân thủ chủ động.
Hướng dẫn thực hiện
Trước khi triển khai chính thức, phải lập "danh sách kiểm tra trước khi triển khai" và tuân thủ nghiêm ngặt:
Kiểm thử toàn diện: Đảm bảo độ bao phủ của thử nghiệm đơn vị trên 95%, độ bao phủ của mã lõi là 100% và đảm bảo đầu ra của báo cáo về độ bao phủ của thử nghiệm đơn vị.
Kiểm toán độc lập: Hoàn thành ít nhất một, và tốt nhất là hai, báo cáo kiểm toán bảo mật độc lập từ các công ty kiểm toán có uy tín.
Đóng băng mã: Sau khi kiểm toán hoàn tất, mã đóng băng cho đến ra mắt và không có thay đổi nào về mã được thực hiện.
Kiểm thử hồi quy: Trước khi triển khai chính thức, hãy thực hiện kiểm thử đơn vị và kiểm thử hồi quy.
Xác nhận tuân thủ: Nhận được sự xác nhận chính thức từ đội ngũ tuân thủ nội bộ để xác nhận rằng logic hợp đồng đáp ứng mọi yêu cầu quy định có liên quan.
Diễn tập triển khai: Chuẩn bị các tập lệnh triển khai chi tiết và tiến hành diễn tập triển khai hoàn chỉnh trên mạng thử nghiệm giống hệt với hoàn cảnh mainnet .
Triển khai được ủy quyền: Hoạt động triển khai cuối cùng được thực hiện bởi ví được ủy quyền.
Sau khi triển khai, cần thực hiện các biện pháp giám sát phù hợp để theo dõi việc sử dụng nhân vật đặc quyền và thực hiện các biện pháp giảm thiểu các mối đe dọa mới nổi:
Giám sát hoạt động trên Chuỗi: Giám sát việc sử dụng nhân vật quản lý (ví dụ: sử dụng hệ thống giám sát bảo mật SlowMist MistEye để thêm chức năng giám sát hoạt động nhân vật chính) để phát hiện kịp thời các tình huống trái phép.
Giám sát thông tin tình báo về mối đe dọa: Các mối đe dọa mới nổi cần được phát hiện kịp thời (ví dụ: sử dụng đăng ký thông tin tình báo về mối đe dọa của hệ thống giám sát bảo mật SlowMist MistEye) và thông tin tình báo về mối đe dọa cần được phân tích để có thể triển khai các biện pháp giảm thiểu kịp thời.
3. Cung cấp hỗ trợ kỹ thuật cho việc duy trì hoạt động việc kinh doanh và lập kế hoạch thoát hiểm
Chỉ thị quản lý
Người được cấp phép phải chuẩn bị “kế hoạch thoái vốn việc kinh doanh để thực hiện việc đóng cửa có trật tự việc kinh doanh stablecoin được cấp phép của họ”29. Kế hoạch này phải bao gồm các thủ tục thanh lý tài sản dự trữ và phân phối lợi nhuận cho người nắm giữ.
Giải thích về công nghệ SlowMist
Điều này có nghĩa là các hợp đồng thông minh phải tự xem xét quy trình "nghỉ hưu" của riêng chúng ngay từ khi thiết kế, và chúng cần có các trạng thái và cơ chế cho phép đóng cửa một cách có trật tự. Yêu cầu về cơ chế thoát có nghĩa là vòng đời của hợp đồng thông minh không kết thúc khi triển khai, mà phải có một giao thức "kết thúc vòng đời" được xác định rõ ràng ở cấp độ giao thức. Đây là một khái niệm mới đối với nhiều nhà phát triển đã quen với việc xây dựng hợp đồng "vĩnh viễn", và nó cũng thúc đẩy tư duy "thiết kế để chấm dứt". Một quy trình thanh lý có trật tự đòi hỏi một hồ sơ rõ ràng, cuối cùng và không thể tranh cãi về việc ai sở hữu cái gì tại thời điểm đóng cửa. Mục tiêu này sẽ khó đạt được nếu việc đóng cửa được thực hiện trong trạng thái hỗn loạn, nơi các giao dịch vẫn đang diễn ra. Do đó, một chức năng có thể đóng băng trạng thái của hợp đồng là một biểu hiện kỹ thuật trực tiếp của yêu cầu quy định này. Do đó, trạng thái Chuỗi trở thành nguồn dữ liệu xác thực cuối cùng, kiểm toán trong tay người thanh lý.
Hướng dẫn thực hiện
Xây dựng kế hoạch thoát khỏi việc kinh doanh: Kế hoạch này bao gồm các tình huống khác nhau có thể dẫn đến việc chấm dứt hợp đồng và các biện pháp giám sát khả năng xảy ra thực tế hoặc tiềm ẩn của các tình huống này.
Quy trình thoát trên Chuỗi 30:
Hợp đồng thông minh nên bị tạm dừng để ngăn chặn mọi hoạt động chuyển nhượng token nhằm đảm bảo lợi nhuận thanh lý tài sản dự trữ tối đa và giảm thiểu tác động đến sự ổn định chung của thị trường.
Dựa vào chức năng đổi thưởng và chức năng danh sách trắng, hỗ trợ người nắm giữ stablecoin gửi đơn xin đổi thưởng.
Phụ lục Phần IV: Bảng tham chiếu chéo các yêu cầu quy định
Bảng này ánh xạ từng tính năng kỹ thuật của hệ thống hợp đồng thông minh trực tiếp với văn bản quy định cụ thể yêu cầu:
Tài liệu liên quan
[1]Cơ quan Quản lý Tiền tệ Hồng Kông. (26 tháng 5 năm 2025). Tài liệu tham vấn về các yêu cầu AML/CFT được đề xuất đối với các hoạt động stablecoin được quản lý. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf
[2]Cơ quan Tiền tệ Hồng Kông. (Tháng 5 năm 2025). Dự thảo hướng dẫn về giám sát các tổ chức phát hành stablecoin được cấp phép. https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf
Tài liệu tham khảo
[1]Tham vấn_về_Dự thảo_Hướng_dẫn_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 21, 6.5.5
[2]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 21, 6.5.5
[3]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 20, 6.5.3
[4]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 20, 6.5.3
[5]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 21, 6.5.4
[6]Tài liệu tham vấn về Đề xuất Yêu cầu AMLCFT cho các Hoạt động Đồng ổn định được Quy định.pdf, trang 13, 3.6.2
[7]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 20, 6.5.3
[8]Tham vấn_về_Bản_dự_luận_về_Hướng_dẫn_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 21, 6.5.4
[9]Tham vấn_về_Dự thảo_Hướng_dẫn_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 10, 3.1.1
[10]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 12, 3.4.1
[11]Tài liệu tham vấn về Đề xuất yêu cầu AMLCFT cho các hoạt động đồng ổn định được quản lý.pdf, trang 9, 3.2.1
[12]Tham vấn về Dự thảo Hướng dẫn Giám sát các Nhà phát hành Đồng ổn định được cấp phép.pdf, trang 11, 3.2.3
[13]Tham vấn về Dự thảo Hướng dẫn Giám sát các Nhà phát hành Đồng ổn định được cấp phép.pdf, trang 11, 3.2.5
[14]Tham vấn_về_Bản_dự_luận_về_Hướng_dẫn_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 38, 6.8.2
[15]Tài liệu tham vấn về Đề xuất yêu cầu AMLCFT cho các hoạt động đồng ổn định được quản lý.pdf, trang 13, 3.6.2
[16]Tài liệu tham vấn về Đề xuất yêu cầu AMLCFT cho các hoạt động đồng ổn định được quản lý.pdf, trang 11, 3.4.2
[17]Tham vấn về Dự thảo Hướng dẫn Giám sát các Nhà phát hành Đồng ổn định được cấp phép.pdf, trang 20, 6.5.2
[18]Tham vấn về Dự thảo Hướng dẫn Giám sát các Nhà phát hành Đồng ổn định được cấp phép.pdf, trang 21, 6.5.5
[19]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 51, 8.1.1
[20]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 22, 6.5.8
[21]Tham vấn_về_Dự thảo_Hướng_dẫn_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 23, 6.5.8(ii)
[22]Tham vấn_về_Dự thảo_Hướng_dẫn_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 23, 6.5.8(iv)
[23]Tham vấn_về_Dự thảo_Hướng_dẫn_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 22, 6.5.8(ii)
[24]Tham vấn_về_Dự thảo_Hướng_dẫn_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 24, 6.5.8(vii)
[25]Tham vấn_về_Dự thảo_Hướng dẫn_về_Giám sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 25, 6.5.8(x)
[26]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 21, 6.5.5
[27]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 24 6.5.8(ix)
[28]Tham vấn_về_Dự thảo_Hướng_dẫn_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 34 6.5.20(ii)
[29]Tham vấn_về_Bản_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 42, 6.8.16
[30]Tham vấn_về_Bản_dự_luận_về_Hướng_dẫn_dự_luận_về_Giám_sát_các_nhà_phát_hành_đồng_ổ_ổn_định_được_cấp_phép.pdf, trang 42, 6.8.16
