Hkchain — Compliance Model

This document explains how Hkchain supports HKMA's supervisory mandate over licensed stablecoin issuers. It walks through each regulatory surface and describes the on-chain and off-chain mechanisms Hkchain provides.

Principle: chain-level enforcement

Hkchain's core commitment is that compliance rules run at the chain layer, not in issuer-deployed smart contracts. The rules are evaluated by the chain's transaction admission (the AnteHandler decorator chain) before a transfer takes effect, and a transfer that fails a blocking rule does not execute. They apply identically on every supported HKD transfer path:

• a Cosmos SDK MsgSend carrying an hkd.* coin;
• an issuer's MsgDistribute from its treasury to a holder;
• a holder's MsgBurn opening a redemption (it has no counterparty, so the Travel Rule payload and the recipient checks do not apply);
• an EVM call to transferWithTravelRule or transferFromWithTravelRule on an issuer's extended ERC-20 precompile, which runs the same decorators before executing and reverts if any blocking rule fails. The standard ERC-20 transfer and transferFrom revert, because they cannot carry Travel Rule evidence.

The perimeter is drawn around the regulated money and around these message shapes. Its edges are either deliberate or tracked:

• The native token is outside it by design. Transfers of HKC (ahkc), the token used for network fees, are not gated, including from a blacklisted address. The utility token and the regulated money are kept separate.
• Other value-moving messages are not yet inside it. A multi-output send (MsgMultiSend), a send wrapped in an authorisation grant (authz MsgExec) and an inter-chain transfer (IBC MsgTransfer) produce no compliance fact, so no gate inspects them. They are to be brought inside the perimeter, or disabled, before any production deployment.
• Administrative and governance messages (issuer recognition, sanctions updates, pause, parameter changes) are not transfers. They are guarded by the authority checks in the handler that executes them, not by these gates.

The technical report states the full list of current boundaries in its Section 10.2, and Transaction lifecycle names the recognised message set exactly.

This stands in contrast to contract-layer enforcement, where an issuer's Solidity logic is only as reliable as the contract's immutability and the ecosystem's discipline about not interacting with lower layers.

Customer Due Diligence (KYC)

Regulatory surface

HKMA's AML/CFT Guideline for Licensed Stablecoin Issuers requires:

• Real-name verification for all holders
• No anonymous or pseudonymous accounts
• Enhanced due diligence for politically exposed persons (PEP), high-risk jurisdictions, complex or unusual transactions
• Ongoing monitoring (not just onboarding)

Hkchain mechanism

On-chain: x/kyc maintains an address registry with six identity levels. On supported transfers to a counterparty, a level-0 (blacklisted) address can neither send nor receive HKD, a level-1 (unverified) address cannot originate a transfer, and an address with no identity record can be neither party, because the Travel Rule gate requires a registered identity for both. Such transfers are rejected at admission.

Off-chain: the actual due diligence — document verification, screening against adverse-media databases, PEP check, source-of-funds inquiry — is performed by the issuer (or a licensed KYC service the issuer contracts with) off chain. The KYC provider submits MsgEnroll to register the result on chain, signed by the provider's whitelisted key. The identity record on chain stores only the level, a VASP identifier, and a hash pointing to the off-chain IVMS101 data at the provider. No personally identifiable information (PII) is stored on chain.

Level matrix

The capability column is enforced through each level's Travel Rule tier: the sender's payload must declare the tier registered for its level, and that tier must suffice for the amount. A level-2 holder cannot claim a higher tier for a larger transfer and must be upgraded to level 3 or above to make one. The level matrix in the x/kyc parameters also carries descriptive capability flags (can_hold, can_transfer_out and others); no gate reads them, and the Travel Rule tier is the field that changes behaviour.

Sub-role delegation

Compliance teams are not single human identities. Hkchain's MsgBindSubRole lets an L5 issuer bind sub-keys under reviewer and officer roles, each intended to sign a small set of compliance messages. Mint, distribute and per-issuer pause stay with the issuer's primary key, because those handlers require the signer to be the licensed issuer that owns the denomination. Holders at levels 2 to 4 can also bind an agent sub-key that signs transfers within a spending envelope; see Roles and permissions.

Travel Rule

Regulatory surface

Hong Kong applies a zero-threshold Travel Rule. Every transfer — regardless of amount — must carry originator and beneficiary information. For transfers of HKD 8,000 or more, a broader set of IVMS101 fields is required.

Hkchain mechanism

The TravelRuleDecorator validates each supported HKD transfer with a counterparty before it executes:

1. The transfer must carry a Travel Rule payload attached to the transaction itself, as a transaction extension option (on the EVM path, as the payload argument of the extended transfer method). There is no companion message and no separate channel.
2. The payload holds a declared tier, the institution (VASP) identifiers of the parties and the hashes of both parties' IVMS 101 records. The records themselves stay off chain with the regulated parties, so the chain can show what was committed without holding personal data.
3. The declared tier must equal the tier registered for the sender's level, so it cannot be forged upward, and it must suffice for the amount. Below the threshold (HKD 8,000, a rule parameter set by the compliance authority) a minimal payload suffices, and its record hashes must equal those registered for both parties. At or above the threshold, and for level 3 to 5 senders at any amount, a full payload is required, and the institution identifiers it names must match those registered for both parties. A mismatch rejects the transfer.
4. One payload covers exactly one transfer; a transaction bundling several transfers is rejected.

An admitted payload is stored on the ledger against the transaction hash. On a supported path, a transfer without a valid payload cannot execute; there is no "legacy fallback". The chain verifies tiers, bindings and commitments, not the completeness of the underlying IVMS 101 records.

Cross-VASP flow

Full-tier payloads name the institution on both sides, and every admitted payload is anchored on the ledger against its transaction hash. Counterparty compliance teams can therefore correlate their customer's activity with one shared record of what was committed, across multiple licensed issuers. The underlying records are still exchanged between institutions off the ledger; the chain anchors and checks them rather than carrying them.

Sanctions screening

Regulatory surface

Licensed issuers must screen against applicable sanctions lists (UN consolidated list, HKMA-specified lists, and, depending on the issuer's international exposure, jurisdictions like OFAC).

Hkchain mechanism

Sanctions have two axes, both updated by MsgUpdateSanctionsList:

• Addresses. Each listed address is blacklisted in x/kyc (level 0) and is then rejected as sender or recipient by the KycGateDecorator. Blacklisting is additive: leaving an address out of a later update does not remove it.
• Institutions. The listed VASP identifiers form the sanctioned-institution list. The SanctionsDecorator rejects a transfer when either party's registered institution identifier is on it, so a sanctioned service provider's customers are stopped before their individual addresses are listed.

Updates are authorised transactions signed by the compliance authority, a single address (which can be a multi-signature account) appointed by governance. Each update carries a reason and an evidence reference that ride through to the resulting blacklisting.

Current limitation: updates arrive as authorised transactions, not as a real-time feed. Production requires an oracle feed (real-time propagation from canonical sanctions sources) with governance as the fallback for dispute resolution. Documented in the roadmap.

Transaction monitoring and review

Regulatory surface

Ongoing monitoring requires detection of patterns (large transfers, unusual velocity, structuring) and human review of flagged activity with decision audit trail.

Hkchain mechanism

Two advisory decorators raise flags without rejecting: the ThresholdDecorator flags transfers at or above HKD 8,000, and the VelocityDecorator flags a sender that reaches the configured number of transfers in its window. Each flag is stored in the on-chain flag queue (event EventFlagEmitted) and surfaced to the issuer's reviewers on the compliance dashboard. Advisory rules never block in this version.

Review workflow:

EMITTED
    │
    ▼ (reviewer sub-role, MsgReviewFlag or MsgEscalateFlag)
    ├── approve   → RESOLVED_APPROVED
    ├── block     → RESOLVED_BLOCKED (blacklists the subject)
    └── escalate  → PENDING_OFFICER
                      │
                      ▼ (officer sub-role, MsgCloseFlag)
                      ├── approve → RESOLVED_APPROVED
                      └── block   → RESOLVED_BLOCKED (blacklists the subject)

Every decision is recorded on chain, with an evidence hash pointing to the off-chain case management artifact. A block decision moves the subject to level 0 with the flag's case reference (flag/<id>) as the evidence chain. This provides full auditability of the review process without storing case details on chain.

Forward-looking: the reviewer role is a natural candidate for AI-assisted triage. Not in MVP; documented in docs/future/ai-agent-compliance-review.md.

Proof of Reserve

Regulatory surface

HKMA expects:

• 100% reserve backing at all times, with overcollateralization buffer
• Daily statements of par value versus reserve market value
• Weekly public disclosure
• Independent auditor attestation at HKMA-acceptable frequency
• Attestation covers period-end AND a randomly selected business day
• Public disclosure of attestation at a prominent location on the issuer's website

Hkchain mechanism

Multi-signature attestation: the issuer signs MsgSubmitAttestation with period metadata, circulation, reserve market value, the random-day snapshot value, and a hash of the off-chain attestation PDF. State becomes PENDING_AUDIT. A registered auditor signs MsgCoSignAttestation; state becomes ATTESTED.

Daily statements: at the first block of each new UTC day, x/reserve's EndBlocker emits one DailyStatement{issuer, date, circulation, reserve_market_value, latest_attestation_id} per issuer that has at least one registered denom and a finalized (ATTESTED) attestation. Circulation is the SSOT formula owned by x/stablecoin (bank.GetSupply(denom) − issuer.minted_available(denom)); reserve market value is pulled from the issuer's latest ATTESTED attestation. Queryable via QueryDailyStatement{issuer, date}; also surfaced as EventDailyStatement for dashboards.

Public verifiability: QueryReserveForAddress lets any party — a holder, a regulator, a journalist — enter an address and receive one AddressReserveBinding{issuer, denom, balance, attestation} per denom the address currently holds with non-zero balance, each binding carrying the issuer's latest attestation (issuer and auditor signatures, random-day snapshot, and the hash that ties to the public PDF disclosure).

Mint freshness gate: MsgMint by an issuer is rejected if the latest ATTESTED attestation is older than a governance-parameterized freshness threshold. This ensures the issuer cannot mint beyond a stale attested reserve.

Supervisory observability

Regulatory surface

HKMA's supervisory actions include periodic report receipt, ad-hoc inspections, investigation of events, and (on findings) enforcement. The supervisor needs a stable observational surface over the issuer's operations.

Hkchain mechanism

Supervisor role is read-only by design. There is no supervisor-signed transaction type in Hkchain. The supervisor is a privileged query consumer.

Supervisor Dashboard (/dashboard/supervisor): a read-only cross-issuer overview of circulation across all hkd.* denominations, the latest attested reserve with its period and freshness, the distribution of identities by KYC level (each level opens a paged list of its addresses), and the sanctions set. The compliance view adds the flag queue with its review states, and the block explorer shows each transaction's decoded messages, Travel Rule payload, flags and audit entries. Designed so that a supervisor can "walk the floor" without reading raw blocks.

Gate trace: each node records, for every transaction it evaluates (rejected ones included), each gate's result, a regulator-legible reason and the resources it consumed. The trace is queryable by transaction hash (TxTrace), and a candidate transaction can be evaluated against the gates without changing state (SimulateTrace). It is node-local operational evidence, not consensus state: it is held in a bounded buffer, can be evicted, and exists only on nodes that processed the transaction. A rejected transaction therefore leaves no ledger record in this version. The durable record of admitted transfers is the audit log, the Travel Rule registry and the flag queue.

Reports: the Report query assembles a period roll-up from the audit log and the flag queue. Export of supervisory reports in the supervisor's prescribed formats is on the roadmap.

Event streaming: typed compliance events can be subscribed to over the CometBFT WebSocket, filtered by event type and attribute. The dashboard uses this to refresh its views as new events arrive.

Interoperability between issuers

Narrative

HKMA has signalled support for a multi-issuer stablecoin landscape. Hkchain's denom namespace (hkd.<issuer>) and VASP identifier registry let multiple licensed issuers coexist on the same rail. Cross-issuer transfers pass the same gates and carry the same Travel Rule payload as any other transfer, so supervisory correlation works from one record.

The test network carries two test issuer denominations (hkd.hsbc and hkd.anch), each exposed at its own EVM address. The architecture, denom namespace, and role model are multi-issuer-ready.

What Hkchain does NOT do

• Hkchain is not a KYC provider. The actual CDD work is performed off chain by issuers or their contracted providers. Hkchain records the outcome.
• Hkchain does not issue stablecoins. Only L5-whitelisted, HKMA-licensed entities issue. Hkchain is the rail.
• Hkchain does not replace HKMA supervision. Hkchain provides observability and enforcement primitives; the supervisor still applies supervisory judgement, inspects operationally, and enforces sanctions under their legal mandate.

See HKMA Regulatory Reference for the specific Guideline paragraphs and how each maps to a Hkchain mechanism.