Hkchain — Overview
Purpose
Hkchain is a compliant payment Layer-1 blockchain purpose-built for HKD stablecoins. It provides the technical primitives that HKMA-licensed stablecoin issuers need to operate under the Hong Kong Stablecoins Ordinance — enforced at the chain layer rather than delegated to individual smart contracts.
The problem Hkchain addresses
Hong Kong's regulatory framework for fiat-referenced stablecoins (effective 2025-08-01) imposes substantial requirements on licensed issuers:
- Real-name customer due diligence (CDD) for every holder
- Zero-threshold Travel Rule compliance on every transfer
- 100% reserve backing with independent auditor attestation
- Continuous transaction monitoring with audit-ready reporting
- Public disclosure of reserve status and attestation
Licensed issuers today must meet these requirements either by deploying isolated Solidity contracts on general-purpose chains (with the bypass and fragmentation risks noted in the Executive Summary) or by restricting their stablecoin to closed networks without broad interoperability. Neither path aligns neatly with HKMA's apparent preference for a supervisable, interoperable, and publicly verifiable ecosystem.
Hkchain aims to close this gap: a payment rail where the regulatory primitives are evaluated by the chain itself before a transaction takes effect, interoperable across issuers, observable by supervisors, and verifiable by the public.
Users of the system
| Persona | Relationship to Hkchain |
|---|---|
| HKMA supervisors | Observe — read-only dashboard, block explorer and public queries |
| Licensed stablecoin issuers (HSBC, Anchorpoint, RD Technologies, …) | Operate — whitelisted L5 role; mint, distribute, complete redemptions, manage treasury; manage compliance team sub-roles |
| Compliance reviewers (issuer sub-role) | Review — resolve flagged transactions |
| Compliance officers (issuer sub-role) | Escalate — close escalated flags; a block decision blacklists the subject |
| Independent auditors | Attest — co-sign reserve attestations |
| Institutional holders (licensed VASPs, corporate clients) | Transact — L4 identities with full Travel Rule flow |
| Retail holders (individual after CDD/EDD) | Transact — L2/L3 identities with AML guardrails |
| Agentic application builders | Build — x402-compatible pay-per-request services on HKD rails |
| Public | Verify — reserve lookup for any address |
Categorically excluded: anonymous or pseudonymous holders. The Stablecoins Ordinance AML/CFT Guideline does not permit this category for licensed fiat-referenced stablecoins.
Scope of MVP
The MVP was delivered as a single-node development network demonstrating the regulatory narrative end-to-end, and the same software now also runs a five-validator permissioned test network. Demo must-show scenarios:
- Chain running with block production
- HKD lifecycle: mint → transfer (with Travel Rule metadata) → burn/redemption
- Transfer to blacklisted address rejected by the chain
- Large transfer (≥ HKD 8,000) requires a full-tier Travel Rule payload; a minimal payload or a sender whose level cannot claim the full tier → rejection
- Reserve attestation submitted by issuer, co-signed by auditor, finalized on chain
- Compliance report: a period roll-up of the audit log and flag queue (export in HKMA's prescribed formats is roadmap)
- HTTP 402 agent payment — good agent succeeds; blacklisted agent is blocked by the rail, not by the service
- Public reserve lookup for any address
- Chain-enforced agent revocation — user-bound agent sub-key spends within a
daily_cap/per_tx_capenvelope; onMsgRevokeSubRolethe next attempted payment is rejected byAgentPolicyDecoratorwithin one block, regardless of which service the agent is interacting with
Non-Goals (MVP)
- DEX / DeFi primitives — outside the "compliant payment rail" narrative
- Multi-currency — HKD only
- Production consensus (Algorand Pure PoS) — roadmap
- Mainnet deployment — the networks are a single-node development network and a permissioned test network
- Real-time sanctions oracle — sanctions updates are authorised transactions signed by the compliance authority
- Cross-chain bridging (IBC) — roadmap
Technical foundation
- Framework: Cosmos SDK with
github.com/cosmos/evmv0.6.0 - Consensus: CometBFT with a permissioned validator set (one validator on the development network, five on the test network); Algorand Pure-PoS targeted for production
- EVM compatibility: one extended ERC-20 precompile per issuer denomination, visible to MetaMask and standard EVM tooling; transfers go through Travel-Rule-carrying methods that run the same compliance gates as the native path
- Off-chain services: Next.js web app (homepage, compliance dashboard, explorer, and
/docsroutes from one origin), test network onboarding portal, Go HTTP 402 payment demo service
See Architecture for detail.
How Hkchain relates to licensed issuers
Hkchain is not itself a stablecoin issuer. The HKD stablecoin on Hkchain is issued by an HKMA-licensed entity (e.g., HSBC, Anchorpoint) with its own reserve backing, legal relationship to holders, and supervisory obligations. Hkchain provides the rail. An issuer onboards onto Hkchain via a governance-gated whitelisting process; the issuer retains sole authority to mint and distribute their own denom and to complete its redemptions.
This separation is important: Hkchain does not compete with licensed issuers. Hkchain makes it easier for licensed issuers to operate compliantly, to demonstrate compliance to HKMA, and to interoperate with each other and with downstream users.