AI disclosure: This article was drafted with AI assistance, then checked against the Hong Kong Monetary Authority’s Phase 2 report. It is an independent technical explainer, not a transcript of the linked 3 November 2025 DAPPWEB video, and it makes no claim that e-HKD is generally available or that any pilot use case has launched commercially.
A programmable payment sounds simple: attach conditions to money, then let software enforce them. The difficult design question is what those conditions attach to. If restrictions travel with the monetary unit itself, the unit may behave less like interchangeable money and more like a voucher. If conditions govern the payment instruction while the underlying value remains fungible, the system can preserve a different set of monetary properties.
That distinction is one of the most useful engineering lessons in the Hong Kong Monetary Authority’s e-HKD Pilot Programme Phase 2 report. The report discusses programmability alongside interoperability, privacy, identity, convertibility with conventional money, and reliability and performance. Those concerns are coupled: a design that makes one use case easy can create new assumptions at the settlement, identity, or recovery layer.
This article revisits the subject of our historical video discussion published on 3 November 2025. The video is a dated commentary; the analysis below uses the HKMA report as its factual source.
Put the condition on the instruction—or on the money?
Consider two designs. In the first, a token can only be spent at approved merchants or for approved goods. In the second, a payment instruction carries a condition—such as releasing funds after a delivery event—while the value itself remains interchangeable outside that transaction.
The first design may offer direct control, but it raises questions about fungibility and the “singleness of money”: whether different forms of money remain interchangeable at face value. The HKMA report warns that native spending conditions could make e-HKD more voucher-like and discusses the related legal-tender and public-trust implications. This is not merely a smart-contract implementation detail. It is a monetary design decision.
The report also examines purpose-bound money and programmable payments as approaches that can preserve the fungibility of the underlying value while adding conditions to a transaction. That separation is useful for engineers: keep policy about a particular payment in the payment workflow where possible, rather than silently turning every unit into a different class of asset.
Interoperability expands the failure surface
A second design pressure appears when tokenised assets and money live on different distributed-ledger networks. A settlement flow then crosses systems with different finality rules, availability, identity controls, and recovery paths. “Interoperability” is not achieved merely because a bridge can move a representation from one chain to another.
The HKMA report describes mechanisms explored in pilots, including lock-and-mint and hashed timelock contracts (HTLCs). In a lock-and-mint flow, the source asset is locked and a representation is created elsewhere. That creates an explicit dependency: the destination representation is trustworthy only while the source-side lock and the mechanism that observes it remain trustworthy. Operators need to reason about the representation’s redemption path, not only its creation.
An HTLC uses a hash condition and a time limit to coordinate claims across chains. The timeout matters as much as the happy path. A useful implementation review asks what happens when one chain is congested, a relayer is unavailable, the proof arrives late, or the participant cannot complete the second leg before expiry. A mechanism can be atomic under its stated assumptions and still have operational failure modes at the boundaries around it.
Turn the report into engineering questions
For a payment or settlement prototype, these questions make the design review concrete:
- Which object carries the condition: the monetary unit, the payment instruction, or a separate escrow contract?
- Can two supported networks disagree about finality, and how is that disagreement surfaced?
- What is the timeout and refund path when the counterparty or bridge service disappears?
- Which identity claims are necessary for the use case, and what data is exposed to each participant?
- How does the design convert to conventional money, and who is responsible for reconciliation?
- What reliability and performance targets were tested, and which remain assumptions?
These are questions, not claims that the pilot answered every production requirement. A pilot can establish that a mechanism is feasible in a bounded setting without proving broad availability, legal treatment for every use, or production-scale resilience.
The practical takeaway is to treat programmability as a boundary decision. Put conditions where they solve the payment problem while preserving the properties the wider system depends on. Then test cross-network failure and recovery explicitly. More programmable does not automatically mean more useful; the quality of the boundaries determines whether the system remains understandable, interoperable, and recoverable.
Sources
- Hong Kong Monetary Authority, e-HKD Pilot Programme Phase 2 Report.
- DAPPWEB, historical video discussion published 3 November 2025.
Top comments (0)