What Happened to HKDAP? Why Hong Kong's First Licensed Stablecoin Failed Its Security Review

Bottom line: HKDAP did not collapse, depeg or lose its reserves. Two days after its limited beta launch, security firm BlockSec published an independent review of the live Ethereum contracts and called them "not production-ready." The review found broken KYC revocation logic, inconsistent transfer checks and privileged actions that could be executed by one signer. That is a serious launch failure, but it is a failure of software, governance and assurance. It is not evidence that one HKDAP stopped being redeemable for one Hong Kong dollar.

The viral version of the story is easy to understand: Hong Kong licensed a stablecoin; it launched; it failed almost immediately.

What happened is more precise and, frankly, more embarrassing. The issuer was licensed. The reserves were supposed to be bank-managed. The product was marketed as having “bank-grade compliance and risk management.” But once the token went live on a public blockchain, researchers could compare those promises with the code that actually controlled the money.

The two did not match.

Status check, August 17, 2026: HKDAP remains in “Beta Access.” A read-only call to its verified Ethereum contract returned a total supply of 520,130 HKDAP and showed that the token was not paused. We found no public evidence of an exploit, unauthorized mint, depeg or reserve loss. Anchorpoint and the HKMA had not published a substantive response to BlockSec’s findings when this article was completed.

What was HKDAP supposed to do?

HKDAP stands for Hong Kong Dollar At Par. Each token is designed to represent HK$1 on Ethereum and be redeemable at that value.

The issuer, Anchorpoint Financial Limited, is a subsidiary of Standard Chartered Bank (Hong Kong) and a joint venture with HKT and Animoca Brands. The HKMA licensed Anchorpoint in April 2026 under Hong Kong’s Stablecoins Ordinance. Anchorpoint was one of the first two licensed issuers, and HKDAP became the first product under that regime to enter a live rollout.

According to the HKDAP website and whitepaper, the token was built for four jobs:

1. Cross-border transfers: move HKD-denominated value across accounts and borders at any time, without waiting for conventional banking hours.
2. Tokenized-asset settlement: provide cash-like settlement for tokenized funds, bonds and other real-world assets on public blockchains.
3. Payments across Web2 and Web3: let users carry the same unit of value through wallets, cards, apps, merchants and digital-asset platforms.
4. Programmable finance: give institutions and developers a regulated HKD payment primitive they could integrate into new financial products.

This was not meant to be another anonymous token launched into a decentralized exchange pool. Anchorpoint chose a B2B2C distribution model. Authorized distributors would onboard customers, perform due diligence and connect institutional, corporate and eventually retail users to the token. The initial phase began on August 12 with restricted access for distributors and their professional or institutional clients.

The financial design was conventional for a regulated fiat-backed stablecoin. Anchorpoint says every HKDAP is backed by high-quality, liquid reserve assets held in a segregated trust, with Standard Chartered entities serving as reserve manager, custodian and trustee. The peg depends primarily on reliable issuance and redemption against those assets, not on an algorithm trying to manufacture demand.

HKDAP’s purpose made sense. Hong Kong has deep capital markets, a widely used local currency and an obvious reason to want 24/7 settlement infrastructure that is not denominated in US dollars.

So what actually “failed”?

On August 14, one day after completing its review of the deployed system, BlockSec published a 26-minute technical analysis. The researchers examined the verified smart-contract source, storage and governance configuration on Ethereum mainnet.

They did not report stolen funds. They did not demonstrate that the reserve pool was missing. They did not claim that an outsider could simply mint tokens.

They found that the production code did not reliably enforce the controls the product said it had.

That is why “failed a security review” is accurate, while “the stablecoin failed” is too broad.

The five problems in plain English

1. Revoking a KYC provider did not revoke its wallets

HKDAP’s compliance system lets approved identity providers mark wallets as KYC-verified. If a provider is compromised or removed, the wallets it vouched for should stop passing the KYC check until they are reviewed.

BlockSec found that this revocation path was effectively dead code. A loop used the wrong comparison, so it never ran, and a later line compared values instead of assigning the result. The contract therefore checked a wallet’s activation counter but ignored the fact that its identity provider had been deregistered.

The deregistration function had another problem: it moved the provider into a different list but did not change the provider’s status to inactive. A supposedly removed verifier could continue registering or deactivating wallets.

For a regulated token whose access model depends on KYC, this is not a cosmetic bug. It weakens the ability to remove trust after a provider fails.

2. The contract accepted a KYC “proof” without checking it

The registration flow passed a KYC proof into an internal function. That function ignored the proof and returned true as long as the caller was an active verifier.

This was not a permissionless bypass: an approved verifier still had to make the call. But the chain itself did not validate whether the submitted evidence was real, correctly signed or even non-empty. The design therefore placed all integrity in the off-chain verifier while presenting an on-chain proof parameter that did no work.

3. One signer could perform several high-risk actions

This finding drove the headlines. BlockSec mapped the live authorization matrix and found that one role, held by one address, could mint, burn, freeze or deactivate KYC. Other single-signer roles could pause the token, destroy blacklisted funds, register verifiers or blacklist addresses.

The viral retelling often says one key could mint “unlimited” HKDAP. That overstates the finding: BlockSec noted that the contract had a supply velocity limit. The problem was unilateral authorization. A designated signer could initiate and complete a high-risk action without a second on-chain signer approving it.

BlockSec also found no timelock. Even operations requiring two roles executed as soon as the final signature arrived, leaving no delay for monitoring, cancellation or independent review.

That directly clashes with the HKMA’s supervisory guideline. Paragraph 6.5.3 says high-risk operations should be designed so no single party can perform them unilaterally, while paragraph 6.5.4 requires adequate segregation of duties and immediate revocation of authority.

4. The same transfer could face different compliance rules

ERC-20 tokens have two common transfer paths: transfer, used when someone moves their own tokens, and transferFrom, used when an approved spender moves tokens on someone’s behalf.

HKDAP applied its deposit and redemption whitelist shortcuts only in the second path. Its “checking mode” also evaluated different parties depending on which function was called. That meant the same economic movement could receive different KYC treatment simply because an application used a different ERC-20 entry point.

Compliance code should be boring and predictable. Here, it was difficult to reason about and potentially avoidable.

5. The deployed build carried pre-production warning signs

BlockSec found debug logging in the proxy fallback, contradictory comments, inconsistent role-name hashes, an unreliable approval event and a hand-written ERC-20 implementation. The project had also rebuilt multisignature approval, access control, timelocks, linked collections and the token itself in custom code.

The more security-critical machinery a team writes from scratch, the more behavior it must specify, test and audit. Standard ERC-20 contracts, named access-control roles, established multisig wallets and timelocks are not automatically safe, but they reduce the amount of novel code sitting between a private key and other people’s money.

Most of BlockSec’s findings were in HKDAP’s custom machinery.

Why the regulatory contradiction matters

Anchorpoint’s own whitepaper says that “no single individual can unilaterally sign or execute smart contract transactions.” It says sensitive actions follow maker-checker controls and that findings from an extensive penetration-testing program were remediated before the mainnet contract was deployed.

The public contract appeared to tell a different story.

BlockSec showed a completed mint that reached quorum and executed inside a transaction sent by the sole holder of the relevant role. The researchers also showed that one account combined execution powers with several auditor roles, weakening the separation between doing and reviewing.

There may be off-chain protections that the blockchain cannot see. A blockchain address can be controlled by an HSM-backed enterprise workflow, and several people may be required to authorize use of one key inside an institution. BlockSec explicitly limited its conclusions to public code and on-chain facts.

But the HKMA rule is about how high-risk operations are designed, and it specifically gives multisignature protocols as an example. If one on-chain credential can complete the action, the smart contract itself has a single point of failure even if internal procedures make misuse less likely.

Licensing the issuer did not make every line of its deployed code correct. It established a regulated entity, capital and reserve obligations, redemption duties, governance expectations and supervisory access. A licence is not a cryptographic proof that the final implementation matches those expectations.

Did HKDAP lose its peg or its backing?

There is no public evidence that it did.

HKDAP is not an algorithmic stablecoin like TerraUSD. Its stated stability mechanism is a reserve of cash, short-term deposits and other permitted liquid assets, held in trust and valued at least equal to the tokens in circulation. Authorized distributors pre-fund issuance, and redemption removes tokens in exchange for HKD.

BlockSec did not audit that reserve. Its report expressly excluded backing, custody and off-chain key management because those cannot be established from the token contract alone.

The public evidence is still incomplete. Anchorpoint’s transparency page says weekly unaudited reserve statements will be available during Beta Access and audited attestations will begin after Full Launch. When checked on August 17, the page still displayed dashes for circulation, reserves, issuance and redemptions. Its balance date showed August 10, two days before beta began.

That does not prove a reserve shortfall. It means the public cannot yet use Anchorpoint’s transparency dashboard to independently reconcile the live supply with disclosed reserves.

The smart-contract findings create a different risk. A compromised privileged key could interfere with supply or holders even if every reserve dollar existed. Reserve quality and contract security are separate layers, and a credible stablecoin needs both.

Why did HKDAP fail this test?

Buggy and overcomplicated custom code caused the technical problems. The final quality gate also failed.

Anchorpoint had spent years in development, participated in the HKMA sandbox, received one of only two licences and conducted mainnet tests with regulated partners. Its whitepaper said deployed findings had been remediated. Yet independent researchers found basic logic errors and governance choices that appeared inconsistent with the regulator’s published requirements immediately after launch.

The licence review and the deployed build appear to have been treated as one assurance problem. They are not. Institutional fitness, reserve management and redemption planning do not replace line-by-line verification of the final contracts and live role configuration.

The architecture also created too much novel attack surface. HKDAP reinvented widely used token and governance components instead of composing a smaller system from heavily reviewed primitives.

Finally, beta seems to have been treated as a softer standard despite the contract being on mainnet. Once a token represents a legal claim on real Hong Kong dollars and is controlled by real keys, “beta” limits access. It does not limit the consequences of a privileged-key failure.

The review also exposes a healthy feature of public blockchains: the implementation was visible. A traditional payment system can make broad claims about internal controls that outsiders cannot test. HKDAP’s verified contracts allowed researchers to compare the claim with the mechanism before the beta expanded.

What needs to happen next?

Anchorpoint can fix these issues, but a quiet patch would not be enough. Trust now depends on a transparent remediation process.

Anchorpoint should:

1. respond to each BlockSec finding and identify any factual or architectural disagreement;
2. put minting, burning, freezing, blacklisting, pausing and upgrades behind genuine multisignature authorization with clearly separated roles;
3. add appropriate timelocks and emergency-cancellation procedures;
4. repair KYC provider revocation, proof handling and the inconsistent transfer paths;
5. remove debug and ambiguous audit behavior, then publish the corrected source;
6. commission a new independent audit of the exact implementation and role configuration that will run on mainnet;
7. publish beta circulation and reserve statements so holders can reconcile on-chain supply with off-chain backing; and
8. explain whether the HKMA required, approved or has since reviewed the live configuration.

The HKMA also has a credibility test. Hong Kong built one of the world’s most explicit stablecoin regimes and granted only two licences from a much larger field. If the first live product appears to contradict the technical safeguards in that regime, the public needs to know whether this was a disclosure gap, a launch-control failure or a supervisory blind spot.

The verdict

HKDAP was built for a legitimate purpose: giving Hong Kong a regulated, programmable HKD settlement asset for payments and tokenized markets. That purpose did not fail.

The peg did not visibly fail either.

What failed was the claim that a licensed, bank-backed stablecoin had arrived with bank-grade controls already translated into production-grade public code. BlockSec found that key compliance logic did not work as written, critical powers were too concentrated and the deployed system carried the fingerprints of a pre-production build.

The viral headline is wrong if it makes you imagine a Terra-style collapse. This story is about the gap between regulation on paper and control in code. For a token whose name literally promises “at par,” that gap has to be closed before broader adoption, not after something goes wrong.

HKDAP FAQ

What is HKDAP?

HKDAP, or Hong Kong Dollar At Par, is an Ethereum-based stablecoin issued by HKMA-licensed Anchorpoint Financial. Each token is designed to represent and be redeemable for HK$1.

Did HKDAP depeg?

There was no public evidence of a depeg when this article was completed. The controversy concerns BlockSec's review of the smart contracts and governance, not a demonstrated failure of the HKD reserve or redemption mechanism.

Was HKDAP hacked?

No exploit or unauthorized mint was publicly identified. BlockSec reported weaknesses and design conflicts that could increase risk if privileged credentials were compromised or controls failed.

Can one key mint unlimited HKDAP?

BlockSec found that one on-chain role holder could authorize minting without a second signer. The contract also had a supply velocity limit, so describing the finding as completely unlimited minting is imprecise.

Is HKDAP fully backed?

Anchorpoint says circulating HKDAP is backed at least one-to-one by segregated liquid reserves held in trust. BlockSec did not audit those reserves, and Anchorpoint's public transparency dashboard had not yet populated beta circulation and reserve figures when checked on August 17, 2026.

Why was HKDAP created?

Its intended uses include 24/7 HKD transfers, cross-border payments, merchant settlement, tokenized-asset settlement and programmable financial applications distributed through authorized partners.

Who owns Anchorpoint?

Anchorpoint is majority owned by Standard Chartered Bank (Hong Kong) and was established as a joint venture with HKT and Animoca Brands.

Is HKDAP available to retail users?

HKDAP is currently in a restricted Beta Access phase for selected authorized distributors and their institutional or corporate users. Broader access depends on the issuer's rollout and applicable local rules.

Sources and methodology

The Coin Bureau X post was treated as the lead, not as proof that HKDAP had economically collapsed. This article checked the claim against BlockSec’s full review, Anchorpoint’s HKDAP product page, whitepaper and transparency page, Standard Chartered’s licensing announcement, the HKMA supervisory guideline and read-only calls to the verified Ethereum contract.

Disclosure: This article is for general information and does not constitute financial, legal or investment advice. Smart-contract findings can change after upgrades. Verify the current contract, issuer disclosures and regulatory status before relying on HKDAP.