Risk Warning: Beware of illegal fundraising in the name of 'virtual currency' and 'blockchain'. — Five departments including the Banking and Insurance Regulatory Commission
Information
Discover
Search
Login
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
View Market
Hong Kong Stablecoin Regulation: Interpretation of Blockchain Technology Specifications and Security Audit Plan
星球君的朋友们
Odaily资深作者
11hours ago
This article is about 5183 words, reading the full article takes about 8 minutes
Help licensees meet the blockchain technology requirements involved in the guidelines.

Original Source: Beosin

On August 1, 2025, the regulatory regime for stablecoin issuers in Hong Kong officially came into effect. The HKMA's "Guidelines on the Supervision of Licensed Stablecoin Issuers" and " Guidelines on Combating Money Laundering and Terrorist Financing (Applicable to Licensed Stablecoin Issuers)" also came into effect simultaneously, aiming to provide detailed regulatory guidance for stablecoin issuers.

The "Guidelines for the Supervision of Licensed Stablecoin Issuers" document provides detailed technical specifications for Hong Kong's regulatory framework for stablecoins, aiming to ensure regulatory objectives such as stablecoin value stability (full reserves), redemption capability (timely redemption), risk isolation (independence of reserve assets), and consumer protection. The following is the Beosin security team's interpretation and audit plan of the blockchain technology specifications in the "Guidelines for the Supervision of Licensed Stablecoin Issuers" to help licensees meet the blockchain technology requirements set forth in the guidelines.

1. Interpretation of blockchain technical specifications

Pursuant to Articles 2.1, 3.3 and 5.4 of the Guidelines on Combating Money Laundering and Terrorist Financing, licensees should adopt a risk-based approach to formulate and implement their anti-money laundering and terrorist financing policies, procedures and control measures based on the nature, scale and complexity of their business, implement an effective transaction monitoring system at the time of issuance and redemption to identify and report suspicious transactions, and effectively manage and mitigate the relevant money laundering and terrorist financing risks.

1. Distributed Ledger

The Regulatory Guidelines do not specify a specific distributed ledger (such as Ethereum) as a stablecoin issuance network. However, Article 6.5.5 explicitly recommends that licensees conduct a detailed assessment of the security and reliability of the distributed ledger (e.g., its ability to withstand common attacks, and the presence of code defects, exploitation risks, etc.).

Licensees must rigorously evaluate the distributed ledgers on which their stablecoins are issued, prioritizing those operating on public blockchains that have been proven to be stable and market-proven. Furthermore, licensees must implement additional measures to facilitate the redemption of stablecoins in the event of an unrecoverable failure of the distributed ledger, ensuring the security and stability of their stablecoin ecosystem.

2. Token Management

2.1 Technical Documentation

For each specific stablecoin that a licensee intends to issue, the licensee should clearly record:

  • Token standards used
  • The distributed ledger on which the specific stablecoin is issued;
  • The architecture of all smart contracts related to the stablecoin (including token contracts, proxy contracts, multi-signature contracts, etc.), including upgradeability (if any), state variables, functions, function modifiers, libraries, interfaces, etc.

2.2 Permission Control

Article 6.5.3 of the "Supervisory Guidelines" recommends that licensees should clearly define all operations related to the full life cycle management of each specific stablecoin they issue, covering deployment, configuration, minting, destruction, upgrade, suspension, restoration, blacklisting, removal from blacklisting, freezing, unfreezing, whitelisting, and the use of any operating wallet .

For each operation in the stablecoin lifecycle, licensees should implement appropriate levels of authorization and trigger conditions. High-risk operations (such as contract deployment/upgrades, large-scale minting, and account freezes) must be executed through a multi-signature agreement (e.g., three signatures out of five).

Additional risk control measures:

  • Set transaction speed limits
  • Only whitelisted addresses are allowed to mint coins
  • Set a timelock for a specific operation
  • Pre-sign transactions for certain operations, perform off-chain simulation verification before broadcasting transactions, and check signed transactions

2.3 Technical Audit

Annual and event-driven audits: Article 6.5.5 of the Regulatory Guidelines recommends that licensees commission a third-party professional firm (such as Beosin) to audit the smart contracts associated with their issued stablecoins at least annually. Furthermore, an audit should be conducted promptly whenever a specific stablecoin's smart contract is first deployed, redeployed, or upgraded. This approach aims to address gaps in internal audits, ensuring that smart contracts execute correctly as designed and meet their intended functionality, and providing a high degree of assurance that the contracts are free of vulnerabilities or security flaws.

2.4 Stablecoin Monitoring System

Articles 6.5.6 and 6.8.3 of the Supervisory Guidelines recommend that licensees implement measures to continuously monitor the availability, capacity, performance, and expected updates or changes to the underlying technology, and report any anomalies (smart contract vulnerabilities; distributed ledger-related events such as hard forks and soft forks, severe network congestion, outages, attacks and unrecoverable failures; unauthorized use of private keys, etc.).

3. Key Security

Key management (including private keys and mnemonics) is one of the most detailed and important areas of the Regulatory Guidelines. Licensees should establish comprehensive management measures and operational procedures covering the entire key lifecycle, including but not limited to key generation, distribution, storage, use, backup, recovery, and destruction. In particular, for critical operations involving stablecoin smart contracts, such as contract deployment and upgrades, permission and role management, and large-scale minting and destruction, higher security standards should be adopted to ensure key security and prevent unauthorized access and potential risks.

The following are recommended implementations of key lifecycles:

  • Key Generation: For critical keys, the generation process should be performed in a completely offline environment and employ a higher level of security. In practice, seed and/or private key generation should be performed in a physically isolated environment with strict physical security controls in place to prevent unauthorized access or disclosure.
  • Key Storage: Hardware Security Module (HSM) keys with appropriate authentication mechanisms should be stored in secure storage media, such as . This storage location should be located in Hong Kong with strict access control and monitoring systems, or in another secure location approved by the Hong Kong Monetary Authority. Other hardware or software devices used to manage seeds and/or private keys should also be properly protected in an equally secure environment. Multiple mnemonics and/or private keys involved in multi-signature schemes should be stored in separate, secure environments to reduce concentration risk.
  • Key Distribution: Licensees must distribute mnemonics and/or private keys in a secure and reliable manner to ensure their integrity and confidentiality. Specific measures include applying integrity verification mechanisms, physical security measures (for manual distribution scenarios), and using validated encryption algorithms for transmission and storage to prevent leakage or tampering during the distribution process.
  • Key Usage: Licensees should adhere to the principle of least privilege and strictly limit access to keys. Keys should only be used in trusted or physically isolated secure environments to reduce the risk of key leakage or misuse.
  • Key Rotation and Destruction: Licensees should consider regularly rotating their keys to mitigate security risks associated with key compromise. They should also develop and implement a key destruction process to ensure that unused or expired keys are completely destroyed to prevent unauthorized recovery or misuse.
  • Key backup: Licensees should ensure that seed and/or private keys are backed up in multiple secure locations in Hong Kong (or other locations approved by the HKMA) . The location and nature of the backups must be kept strictly confidential from third parties. Licensees should ensure that it is not possible to recover the seed and/or private key by relying solely on backups in a single physical location. Backups should be stored on reliable media and have necessary security measures to prevent unauthorized access and tamper-proof features to ensure the integrity and security of the backups.

Stablecoin Security Audit Program

In response to the smart contract security and operational management requirements of stablecoins, Beosin has launched the following audit solutions to provide licensees with detailed audits and technical support in blockchain technology, aiming to ensure that licensees continue to meet the relevant regulatory requirements and operational standards of the HKMA.

1. Smart Contract Audit

1.1 Scope of Audit:

Contract security audit covers the following:

  • Stablecoin core contract functions (minting, destruction, transfer, freezing, suspension, etc.)
  • Design and implementation of permission and role management system
  • Upgrade Mechanism (UUPS / Transparent Proxy)
  • Emergency mechanism related functions (Pause, Freeze, Blacklist, Whitelist, etc.)
  • Event recording and on-chain behavior traceability
  • Interface standard compatibility (ERC 20, Permit, Metadata, etc.)

1.2 Audit Content:

(1) Minting and destruction

  • Whether the mint() function can be called only by authorized roles.
  • burn() correctly reduces the balance and total supply.
  • Are there any bypass paths or logic vulnerabilities (for example, bypassing permission checks through escalation).
  • Whether to support off-chain deposit confirmation (such as PoR signature or administrator confirmation).

(2) Transfer logic

  • Whether transfer() and transferFrom() comply with the ERC 20 standard.
  • Whether to prevent frozen addresses or blacklisted addresses from initiating transfers.
  • Whether the token can be effectively prevented from moving in the pause state.

(3) Suspension and freezing

  • Whether pause() / unpause() and freeze() / unfreeze() are restricted to specific roles.
  • Whether the pause state can completely freeze operations such as token transfer, minting, and destruction.
  • Whether the address freeze function is effective for transfers and minting.

1.2.2 Authority Structure and Role Management

(1) Role definition (not exhaustive)

  • ADMIN: The highest authority, manages all roles and upgrade operations.
  • MINTER: The right to mint tokens.
  • PAUSER: The right to suspend and resume the contract.
  • FREEZER: has the right to freeze and unfreeze addresses.
  • UPGRADER: Has the right to initiate contract upgrades.

(2) Permission configuration check

  • Are all roles properly allocated during deployment or initialization?
  • Are high-authority roles controlled by a multi-signature wallet to avoid single point of loss of control?
  • Whether to support revocation and emergency replacement (such as timelock management).

(3) Multi-signature and time lock control

  • Do highly sensitive operations such as minting and upgrading require a multi-signature + timelock process?
  • Whether the timelock delay is >= 48 hours makes it easier for licensees and regulators to observe and respond.
  • Whether the contract uses a secure upgrade proxy mode (such as UUPS).
  • Whether the initialize() function has the initializer modifier added.
  • Is there a risk of secondary initialization?
  • _authorizeUpgrade() Whether to allow calls to it only by specific roles.
  • Check whether the storage structure before and after the upgrade remains consistent to prevent variable overwriting.

1.2.4 Event Logging and Operation Tracking

Whether all key operations emit explicit events.

Recommended events are as follows:

  • Mint(address to, uint 256 amount, address by)
  • Burn(address from, uint 256 amount, address by)
  • Pause(address by) / Unpause(address by)
  • Freeze(address target, address by) / Unfreeze (address target, address by)
  • Upgrade(address newImpl, address by)
  • Each event suggestion includes: operator, target address, timestamp, and detailed parameters.
  • Log information should facilitate audit tracing and regulatory review.

1.2.5 Standard Interface Compatibility

  • Whether the ERC 20 standard interface is fully implemented (name, symbol, decimals, balanceOf, etc.).
  • Whether EIP-2612 (Permit, no gas authorization) is supported.
  • Whether ERC 20 Metadata is supported for wallet identification and display.
  • Whether all standard interfaces return values according to specifications and handle abnormal inputs.

2. Operation and maintenance governance and upgrade security strategies

2.1 Audit Scope

Focus on the governance structure design, authority management logic, security of the contract upgrade process, and key operation control mechanisms of the stablecoin contract system in the long-term operation and maintenance process. This aims to ensure that the project has sustainable operation and maintenance capabilities and mechanisms to resist risks such as authority abuse and version hijacking.

2.2 Audit Content

  • Contract upgrade plan: Evaluate whether a secure upgrade mode (such as UUPS or Transparent Proxy) is used, check whether the upgrade function has permission control and access restrictions, and confirm whether the storage layout of the logic contract and the proxy contract is consistent to avoid storage conflict risks.
  • Upgrade permission boundaries and authorization mechanisms: Verify whether upgrade operations are restricted to specific roles (such as UPGRADER), whether mechanisms such as _authorizeUpgrade() are used for authorization protection, and confirm that such permissions are not bypassed by other logic.
  • High-authority operation control mechanism: Check whether the system has the principle of separation of powers and least authorization, such as whether operations such as casting, upgrading, and freezing are managed by independent roles to avoid the risk of abuse of power due to multiple responsibilities.
  • Multi-signature wallet and timelock configuration: Confirm whether key permissions (such as ADMIN and UPGRADER) are controlled by the multi-signature wallet, and whether a delay window for key operations is increased through the Timelock contract to introduce a governance observation period and risk buffer.
  • Role system and permission lifecycle management: Evaluate whether long-term operation and maintenance roles and temporary roles (such as operation accounts, upgrade administrators, etc.) are clearly divided, and check whether there are permission transfer, revocation and recovery mechanisms to prevent roles from being out of control for a long time.
  • Emergency control mechanism: Analyze whether emergency measures such as contract pause, role freeze, and permission revoke are supported to prevent systemic risks brought about by potential attacks, external security incidents, or internal operational errors.
  • Upgrade behavior records and audit logs: Verify whether upgrade and operation and maintenance-related events have on-chain logs (such as Upgrade, GrantRole, Pause, etc.) to ensure post-event traceability and facilitate audits and compliance investigations.
  • On-chain governance adaptability and scalability: If an on-chain governance module is planned to be introduced in the future, it is recommended to evaluate whether the current permission structure supports the governance contract takeover operation and whether it can trigger upgrades, revocations, freezes, and other operations based on the governance results.

3. Log analysis and risk monitoring

3.1 Audit Scope

Focusing on the on-chain behavior logs of stablecoin contracts during operation and the risks derived therefrom, Beosin provides log collection, behavior modeling, risk identification, compliance reporting, and real-time monitoring system services to ensure that licensees have comprehensive operational traceability, visual risk control, and compliance response capabilities.

  • On-chain log collection and analysis

Based on on-chain events triggered by contracts (such as Mint, Burn, Transfer, Freeze, RoleGranted, etc.), an operation record of the entire life cycle of the stablecoin is established, and log compatibility analysis of different contract versions and different deployment environments is supported.

  • Automated behavioral analysis

Combining logs with on-chain state snapshots, behavioral modeling is used to automatically identify abnormal operation paths, abnormal transaction frequencies, and other suspicious/high-risk behaviors.

  • Risk level identification and report generation

Output standardized behavioral audit reports, including time, address, transaction hash, operation type, permission path and other information, for project parties to retain and the HKMA to review; the operational risk level is simultaneously marked in the report for internal reference of the project.

  • Monitoring system integration and alarm mechanism

Beosin provides a dedicated on-chain monitoring system that supports real-time monitoring of multiple indicators (such as large-scale minting, abnormal destruction, permission changes, blacklist transaction triggering, etc.). Once the preset risk threshold is triggered, the system will immediately issue an alarm to assist the project in responding in a timely manner.


stable currency
Welcome to Join Odaily Official Community