How WrappedCBDC Closed a Blacklist Bypass in Its cNGN Stablecoin Before Launch

Compliance controls under adversarial pressure

For a fiat-backed stablecoin, blacklisting and freeze controls exist to satisfy AML and sanctions obligations. Any bypass isn't just a bug—it's a regulatory exposure with real-world consequences.

Canton's unfamiliar privacy model

Canton determines which parties can even read a contract, not just who can act on it. Standard EVM-style access-control review doesn't directly translate, requiring auditors fluent in DAML's stakeholder model.

No unique identity for the compliance registry

The token's blacklist and mint-policy object had no contract key or authenticated identity mechanism—nothing on-chain proved which registry copy was the issuer's real one.

Compressed 3-day review window

A full manual review of core compliance logic, spanning four DAML modules, needed to be completed and validated with runnable proof-of-concept scripts within a tight timeline.

01—Scope definition on Canton DAML modules

The audit covered four core modules from WrappedCBDC's GitHub repository: Admin.daml (compliance registry and permissions), CNGN.daml (token logic), Forwarder.daml (relayed execution), and Setup.daml (initialization).

02—Manual review by two dedicated auditors

HackenProof assigned two auditors who combined line-by-line code review with adversarial scenario modeling—testing not just what the code does, but what an attacker could make it do.

03—Findings across the severity spectrum

The team identified 1 high-severity issue, 2 medium-severity issues, 3 low-severity issues, and 4 additional informational findings covering dead code and configuration gaps.

04—Proof-of-concept validation for every finding

Each vulnerability was backed by a runnable DAML script reproducing the exact exploit or defect—not just a theoretical description, but a script that WrappedCBDC's team could execute to confirm the issue.

05—Two-stage reporting to full resolution

A preliminary report was delivered August 3, giving WrappedCBDC's team time to remediate. The final report, issued August 19, confirmed all 10 findings had been resolved.

HIGH SEVERITY—1

High-severity finding: a forged admin registry that bypassed blacklist and mint-revocation checks entirely

MEDIUM SEVERITY—2

Medium-severity findings: a policy-visibility failure blocking legitimate transfers, and an unremovable zero-value token injection

LOW SEVERITY—3

Low-severity findings: a per-holding pause that couldn't enforce a true emergency stop, a burn function bypassing the blacklist, and unscoped mint authorization

RESOLUTION RATE—10/10

Findings resolved before the final report was issued—zero outstanding issues at delivery

FINDINGS BY SEVERITY

High—1

Medium—2

Low—3

Informational—4

Caller-Controlled Admin Registry Bypasses Blacklist and Mint Revocation

Type: Access Control Bypass

cNGN's compliance state—its blacklist and mint permissions—lives in a shared registry object that transfer and mint functions are supposed to check against the issuer's official copy. But nothing in the code verified that the registry a caller supplied actually belonged to the issuer. An attacker could create their own registry naming themselves as owner, with an empty blacklist and unrestricted mint permissions, and pass that forged object into their own transaction instead of the real one.

Potential impact:

• A blacklisted (frozen) holder could transfer every cNGN token they controlled to any recipient, defeating the platform's core AML and sanctions freeze
• A minter whose permission had been revoked could still execute every outstanding mint proposal assigned to them by creating a fresh forged registry for each one
• Both the receiver blacklist check and the exact mint-amount check were evaluated against the attacker's own forged registry rather than the issuer's real one

Discovered by: HackenProof audit team (@tchkvsky, @shealtielanz)

Issuer-Only Policy Visibility Blocked Legitimate Transfers and Mints

Type: Access Control / Functionality Lock

Canton's privacy model determines who can even read a contract, not just who can act on it. The compliance registry was signed only by the issuer, meaning an ordinary holder or minter had no visibility into it at all. When a holder tried to transfer tokens, or a minter tried to execute an approved mint, the transaction failed before the blacklist or mint checks could even run—the ledger rejected the read of a contract the caller wasn't authorized to see.

Potential impact:

• Every normal transfer and every normal mint was blocked—the architecture as written could not process compliant transactions
• Transactions only succeeded during testing when attackers used their own forged registry (Finding #1)—not a safe workaround for legitimate users
• The fix required a joint-authorization design where the issuer co-signs each transfer or mint alongside the holder or minter

Discovered by: HackenProof audit team (@tchkvsky, @shealtielanz)

Unremovable Zero-Value Token Injection

Type: Denial of Service / Unwanted Contract Injection

cNGN's token contract only required the issuer field to authorize its own creation, with the recipient listed as a passive, non-consenting observer. Any party could therefore create a token naming themselves as issuer and any other user as the recipient, with a zero-value balance. The recipient could not decline it, could not burn it (burn requires a positive balance), and could not archive it themselves, since they weren't a signatory to their own holding.

Potential impact:

• An attacker could repeat the injection indefinitely, using only their own authority, to permanently clutter a victim's active-contract set
• No cap, unique key, or consent mechanism existed to prevent or clean up the spam
• At scale, this could degrade a target's active-contract queries, wallet processing, and ledger storage allocation

Discovered by: HackenProof audit team (@tchkvsky, @shealtielanz)

Three additional low-severity findings addressed further compliance-control gaps—including a pause mechanism that couldn't enforce a true emergency stop across all holdings, and a burn function that let frozen holders still redeem tokens off-ledger. Four informational findings covered dead code, build-configuration issues, and design robustness gaps. All were resolved alongside the high and medium findings.