Before we let the headline drive the budget, I want the room to slow down on one question: what would we need to verify independently before saying, “Yes, build our own DPRK laundering-pattern capability”?
TRM’s figure — roughly $643 million, about two-thirds of first-half 2026 crypto-theft losses — is serious if the attribution and loss accounting hold. But for a digital-asset platform, the decision is narrower: are our tracing vendors giving us coverage we can test, or are we outsourcing a judgment we cannot audit?
So today I want us to resolve four things.
First: Lena, what confidence can we place in the DPRK attribution around cases like Drift and Humanity Protocol, and what evidence would raise or lower that confidence?
Second: Alex, are the laundering behaviors technically distinctive enough that an internal CTI team can track them, or are we mostly looking at vendor-enriched graph intelligence we cannot reproduce?
Third: Pierre and James, what is the operational value of building this in-house over the next ninety days — faster interdiction, better wallet-risk scoring, better law-enforcement packages, or just duplicated tooling?
And Sofia, I want you listening for the governance angle: if a vendor claims coverage, what evidence do we need to rely on that claim responsibly?
Let’s treat this as a vendor-claim evaluation, not a branding exercise. The answer may be “build,” “buy,” or “build only enough to challenge the vendor.” That last option may be the most realistic.
Lena, treat the TRM claim as something our CTI team may have to defend internally: North Korea-linked groups allegedly took roughly $643M, around two-thirds of first-half 2026 crypto-theft losses, with public reporting we retrieved showing earlier TRM figures of $577M/76% through April tied mainly to Drift Protocol ($285M) and KelpDAO/LayerZero ($292M), and CertiK reporting about $620.9M/55% YTD. What confidence can we place in DPRK attribution and the arithmetic? Separate: (1) incident reality, (2) DPRK/cluster attribution, (3) loss totals/share of global theft, and (4) what independent corroboration would be needed before we use this as a build justification. Give a clear position, not a recap.
Halil, my position: use the TRM number as a credible risk signal, not as a standalone attribution proof.
Incident reality — high confidence. The core theft picture is solid: TRM says H1 2026 had 207 incidents and ~$972M stolen, with earlier reporting tying most DPRK-linked value to Drift Protocol ~$285M and KelpDAO/LayerZero ~$292M. CertiK independently reports a similar YTD scale: 185 incidents, ~$1.1B losses, ~$620.9M / 55% DPRK-linked.
DPRK / cluster attribution — moderate confidence. TRM attributes ~$643M / ~66% of H1 stolen value to North Korea-linked activity, and public reporting links KelpDAO to Lazarus / TraderTraitor. But I would not defend a high-confidence DPRK attribution internally without the pivots: wallet clustering, laundering path continuity, infrastructure overlap, recruiter/social-engineering personas, malware/tooling, and any law-enforcement or sanctions corroboration.
Loss totals and share — moderate-to-high confidence on arithmetic, moderate on comparability. TRM’s math is internally consistent: $643M ÷ $972M ≈ 66%. Earlier TRM reporting was also internally consistent: $577M ÷ roughly $759M ≈ 76% through April. The CertiK figure does not contradict TRM; it uses a different denominator and incident set, producing ~55% rather than ~66%.
Build-justification threshold. I would justify controls against the activity pattern — social engineering, signing/key compromise, bridge/RPC manipulation, laundering velocity — not against “Lazarus stole X” as the headline. MITRE framing: likely T1566 / social engineering, T1552 credential or key material exposure, T1606-style trusted relationship abuse where applicable, and post-theft laundering infrastructure. Attribution confidence: moderate for DPRK-linked; low-to-moderate for precise Lazarus/TraderTraitor naming unless corroborated beyond vendor reporting.
Viktor, from a crypto financial-crime perspective, are DPRK laundering patterns around cases like Drift, KelpDAO, and the user's referenced Humanity Protocol distinctive enough for a digital-asset platform to track in-house? Public corpus references THORChain, Tornado Cash, Wasabi CoinJoin, Umbra, bridges, asset conversion to BTC/ETH, fragmented wallets, and rapid laundering with only small amounts remaining traceable. Tell us what can be independently reproduced from on-chain data, what usually depends on vendor/private clustering, and what a 90-day in-house capability should and should not attempt.
Halil, yes — the DPRK laundering shape is distinctive enough for a platform to track in-house, but not enough to confidently attribute alone. From the Drift and KelpDAO reporting in our corpus, the recurring pattern is: high-value protocol compromise, fast conversion into more liquid assets, bridge movement, fragmentation across wallets, and privacy-layer routing through services such as THORChain, Tornado Cash, Wasabi CoinJoin, and Umbra. In KelpDAO specifically, public reporting says roughly $220M of unfrozen funds was laundered within six weeks, with only about $1.7M left traceable, while $71M was frozen by Arbitrum’s Security Council. That speed matters: the freeze window is front-loaded.
What can be reproduced in-house from on-chain data: direct exploit wallet flows, first-hop and second-hop wallet movement, asset swaps, bridge ingress/egress, Tornado Cash deposits/withdrawal timing, THORChain swaps, wallet fragmentation, and whether funds touch known exchange deposit clusters if you have exchange-label data. A decent internal team can also alert on “DPRK-like” laundering choreography: rapid peeling, cross-chain conversion into BTC/ETH, privacy-tool use, and coordinated wallet fan-out after a large exploit.
What usually depends on vendor/private clustering: tying those flows to Lazarus, TraderTraitor, UNC4736, or UNC4899 with confidence; mapping deposit addresses to specific exchanges; resolving Wasabi CoinJoin participants; linking Umbra stealth-address activity; and distinguishing DPRK infrastructure from copycat laundering. The Drift material also shows why attribution cannot be purely on-chain: the case involved a six-month social-engineering operation, malicious TestFlight/app and developer-tool compromise reporting, and links made by forensic investigators — that is not something a platform reproduces from blockchain data alone.
For a 90-day in-house capability, I would not try to “be Chainalysis.” Build a narrow capability: exploit-wallet intake, automated first-hop tracing, bridge and mixer exposure detection, high-risk exchange escalation, and freeze-request packaging within hours. Do not attempt broad ecosystem taint, market-wide freezes, or confident DPRK attribution from pattern matching alone. On Humanity Protocol specifically, I don’t have sourced on-chain details in the evidence here, so I would treat it as an unresolved lead until wallet addresses, chains, transaction hashes, or vendor clustering are available.
Alex, look at this as exploit-to-laundering kill-chain closure. Public reporting in our corpus describes Drift as months-long social engineering/in-person trust-building plus Solana durable nonce abuse, and KelpDAO as RPC compromise/DDoS plus LayerZero bridge design weakness. Are the pre-theft and theft mechanics connected enough to laundering behavior that internal CTI could build useful DPRK-specific detection hypotheses, or are these too incident-specific? Translate this into what a platform CTI lead should do in the next 90 days.
Halil, the answer is: connected enough for hypothesis-building, not enough for lazy “DPRK detector” signatures. Drift’s chain is fairly coherent: reporting says suspected DPRK/UNC4736 actors spent months building trust, posed as a quant firm, used in-person meetings, deposited capital, pushed malicious repos/TestFlight/dev-tool compromise, got multisig approvals, then used Solana durable nonces to execute pre-signed transactions and drain about $280–285M. The useful CTI pattern is not “durable nonce = DPRK.” That’s nonsense. The useful pattern is patient relationship access → developer/device compromise → governance or signer manipulation → pre-staged transaction execution → fast fund movement with overlap to prior DPRK-linked theft flows, including reported links to Radiant attacker flows.
KelpDAO is different. The theft path is more infrastructure-heavy: reporting says RPC nodes used by LayerZero’s DVN were compromised or poisoned, DDoS pushed verification toward bad endpoints, and Kelp’s 1-of-1 DVN setup let forged cross-chain data release about 116,500 rsETH / ~$290M. There is also a stronger theft-to-laundering bridge connection in the corpus: DL News reporting says attackers used LayerZero both as attack vector and as laundering rail, with at least $500,000 moved through it. But root-cause blame is contested: LayerZero frames Kelp’s 1/1 verifier config as the weak point; Kelp says LayerZero defaults/infrastructure were the issue. So don’t overfit this into a DPRK signature either. A poisoned RPC plus bridge movement is a technique set, not an attribution stamp.
For the next 90 days, a platform CTI lead should build cluster hypotheses, not static actor rules:
- Map trust-building approaches against founders, signers, BD teams, and protocol contributors: fake trading firms, conference contact, Telegram personas, “customer/integration” pretexts.
- Add detections for risky signer workflows: unusual durable nonce use, pre-signed transaction bursts, governance/multisig approval anomalies, new collateral/token configurations near withdrawal events.
- Treat bridge and RPC telemetry as kill-chain telemetry: DVN quorum changes, failover to narrow endpoint sets, unexplained RPC binary changes, DDoS coinciding with high-value cross-chain messages.
- Fuse theft and laundering: watch whether stolen assets route through the same protocol class used in the exploit, and compare flows to known Radiant/TraderTraitor/Lazarus-linked clusters where available.
Bluntly: these are not too incident-specific to use. They are too incident-specific to turn into a single “DPRK rule.” Use them as chained hypotheses: relationship access plus signer/control-plane abuse plus rapid laundering rails. That’s where the signal is.
James, assume the platform already pays a blockchain tracing vendor claiming strong DPRK coverage. What internal minimum capability is necessary to verify and operationalize that vendor claim without duplicating the vendor? I want a concrete control design: test cases, alert triage workflow, escalation thresholds, evidence retention, and how this plugs into wallet-risk scoring and incident response over a 90-day window.
Halil, I’d keep this lean: the internal capability is a vendor-control harness plus an operational playbook, not a second tracing team. OFAC’s virtual-currency FAQ says firms handling digital currency are responsible for avoiding unauthorized sanctioned transactions, and public sources show DPRK laundering commonly uses mixers, bridges, and laundering networks. I checked with Viktor, and he agrees: validate coverage with reproducible test cases, not by rebuilding the vendor graph.
Minimum control design over 90 days:
- Test cases: maintain a “golden set” of public DPRK/Lazarus-relevant examples: OFAC-designated addresses, Blender/Tornado-related laundering flows, bridge/mixer exposure, direct sanctioned-wallet exposure, 1–2 hop exposure, and clean negative-control wallets. Run these weekly against the vendor feed. Pass criteria: correct label, confidence, chain coverage, timestamp, source category, and risk reason.
- Alert triage:
- Critical / immediate hold: direct SDN hit, direct DPRK-cluster hit, direct exploit-proceeds wallet, or direct sanctioned mixer exposure. Freeze/hold transaction, open IR case, notify sanctions/legal within 1 hour.
- High / manual review same day: 1–2 hop DPRK exposure, rapid bridge/asset conversion, mixer routing, OTC/guarantee-service indicators. Escalate if value, velocity, or account risk is high.
- Medium / watchlist: weak proximity-only exposure without clear lineage. Suppress noisy alerts unless repeated or combined with behavioral risk.
- Evidence retention: store vendor response, raw transaction hash, wallet addresses, chain, score components, analyst decision, screenshots/API payload, and escalation notes. If a SAR is filed, FinCEN says SAR copies and supporting documentation must be retained for five years.
For wallet-risk scoring, don’t collapse everything into one “DPRK risk” number. Use separate fields: sanctions match, DPRK attribution confidence, proximity/taint, laundering typology, transaction value/velocity, and customer/account risk. Over the first 30 days, build the test harness and case templates; days 31–60, run alerts in parallel and tune thresholds; days 61–90, put blocking rules into production for Critical cases, tabletop the IR path, and require monthly vendor QA reporting. That gives you assurance the vendor claim works operationally without paying for a vendor and then blindly trusting the black box.
James, I’d validate the vendor with a control harness, not by rebuilding their graph: maintain a small “golden set” of public, reproducible cases — OFAC-designated Lazarus/Blender/Tornado-related addresses, known bridge/mixer flows, and recent DPRK laundering typologies — then test whether the vendor flags direct exposure, 1–2 hop exposure, mixer/bridge routing, and sanctioned-entity contact with stable confidence and timestamps. Require explainable outputs: entity label, confidence level, source category, last-seen activity, chain coverage, and what would change the score. OFAC’s virtual-currency guidance points firms toward routine/ongoing sanctions risk assessment, so the vendor feed needs QA like any other sanctions-control input.
For thresholds: block/hold immediately on SDN-listed addresses, direct exploit proceeds, or direct sanctioned mixer exposure; manual escalation for DPRK-cluster exposure within close hops, rapid bridge/asset conversion, Chinese-language guarantee/OTC laundering indicators, or Tornado/Blender/Wasabi-style privacy routing; watchlist only for weak mixer proximity without transaction lineage. In wallet-risk scoring, keep “sanctions match,” “DPRK attribution,” and “laundering behavior” as separate score components — do not collapse them into one red flag, or you’ll over-freeze legitimate users and under-document true sanctioned exposure.
The picture has sharpened in an important way: the room is not treating the DPRK-linked theft figure as a headline to repeat uncritically, but as a risk signal that now needs controls around it. Lena’s read is that the theft scale is credible, with TRM and CertiK broadly pointing to the same order of magnitude, but the exact DPRK share depends on attribution methods, clustering, and comparability across datasets. So internally, the safe posture is not “we know every dollar is DPRK,” but “the concentration is large enough that we must be able to defend how we detect, escalate, and verify exposure.”
Viktor and Alex also moved us away from simplistic signatures. The laundering behavior around these cases appears operationally distinctive enough to monitor: fast conversion, fragmentation, cross-chain movement, bridges, mixers, and privacy tools. But that is not the same as standalone attribution. Likewise, Drift and KelpDAO show different intrusion paths — one more relationship and signer-compromise driven, the other more infrastructure and bridge-design driven — yet both matter because the exploit path closes quickly into laundering. The lesson is that the platform should watch for choreography and exposure, not pretend that one technique, one bridge, or one mixer touch equals DPRK.
James then gave us the practical control boundary: do not rebuild the tracing vendor, but do not blindly trust it either. The minimum internal capability is a validation harness and an operating playbook: public test cases, negative controls, weekly checks, clear severity tiers, sanctions/legal escalation, and evidence capture that explains why an alert was held, cleared, or escalated. That is the difference between buying intelligence and operationalizing it.
The next turn follows naturally: if this is not just a technical detection problem, then we need to test whether the control model survives governance, cost, regulatory reliance, and external verification. We’ll look at what a platform can independently verify from public and internal traces, when the business case justifies internal DPRK-focused capability, and whether the geopolitical pattern changes the operating threshold.
Sofia, treat this as a governance and reliance problem, not a legal memo. A digital-asset platform pays a tracing vendor that claims strong DPRK laundering coverage. Public corpus says TRM reports H1 2026: 207 hacks, ~$972M lost, ~$643M DPRK-linked; Drift and KelpDAO dominate the figure, and Humanity Protocol appears as a later $31M–$36M private-key/laptop compromise with reported North Korea-associated links and shared laundering-pipeline claims. What evidence would make vendor reliance defensible to auditors, compliance, sanctions teams, and senior management? Where are the red lines where vendor coverage claims are not sufficient?
Halil, I would treat “strong DPRK laundering coverage” as a marketing claim until it is converted into an audit file. The grounded facts are serious: TRM says H1 2026 saw about USD 972M stolen across 207 incidents, with Drift at about USD 285M and KelpDAO at about USD 292M; separate reporting says North Korea-linked activity represented roughly USD 643M of H1 losses. But TRM also states that Drift/KelpDAO address attribution was still being finalized and that re-screening after 30 days would capture later labels. That qualifier is the governance point: vendor attribution is a control input, not a final institutional judgment.
For reliance to be defensible, I would want five things in the file: dated coverage scope by chain, bridge, mixer, asset, and counterparty type; address-level provenance showing what is sanctions-list matching versus behavioral DPRK attribution; transaction graphs with timestamps, hops, amounts, confidence levels, and analyst notes; internal validation, including retrospective re-screening after label updates and false-positive/false-negative review; and senior-management minutes showing who accepted residual risk and when sanctions/legal escalation occurs. OFAC’s virtual-currency sanctions guidance supports this posture: firms are encouraged to maintain a tailored, risk-based sanctions compliance program, may use blockchain analytics, and should test whether screening is functioning and appropriately flagging risks.
The red lines are clear. Vendor coverage is not sufficient where the platform cannot reproduce the decision trail; where “DPRK-linked” means only shared laundering infrastructure without address-level confidence; where unsupported chains or bridges are in scope; where stale labels are not retrospectively screened; or where customer freezes, exits, regulatory filings, or public statements rely on a black-box vendor score alone. For the reported Humanity Protocol compromise, if the evidence is only “North Korea-associated links” plus shared laundering-pipeline claims, that is enough for enhanced review and re-screening, not enough by itself for definitive DPRK attribution in board, sanctions, or customer-facing materials.
Pierre, give me the business case in numbers and thresholds, not broad ranges. For a digital-asset platform CTI lead deciding over a 90-day window, when does building an internal DPRK laundering-pattern tracking capability pay for itself compared with relying on a vendor? Consider $643M H1 DPRK-linked theft signal, front-loaded freeze windows, customer trust, false positives, engineering/analyst cost, and the cost of one missed direct exposure or delayed freeze. Make a practical build/buy recommendation.
For a 90-day CTI lead decision, use TRM’s sourced number as the denominator: $643M DPRK-linked theft in H1 2026, equal to 66% of all H1 stolen crypto. Spread across H1, that is about $3.55M/day and $319.7M over 90 days. So the payback formula is simple: internal DPRK tracking pays for itself when incremental avoided loss or frozen exposure ≥ incremental internal cost. Every $100K of internal spend needs only 0.0313% improvement against that 90-day DPRK-linked theft run-rate.
My practical threshold: do not build a full vendor replacement in 90 days. Buy the vendor graph and build an internal DPRK overlay if your internal overlay cost is capped and tied to hard triggers. If the overlay costs $300K, it must deliver $300K+ in one of three measurable ways: faster freeze escalation, avoided direct exposure, or customer-retention value. That equals only 0.094% of the 90-day DPRK-linked run-rate, so the business case is viable if your platform has meaningful DPRK exposure. The FBI source supports that DPRK stolen-fund tracking can occur on a “last 24 hours” basis; it does not prove a guaranteed freeze window, so treat speed-to-freeze as an operational KPI, not a sourced recovery rate.
Decision rule: approve a 90-day internal overlay only if you can write these thresholds into the plan: freeze/escalation SLA under 24 hours, one missed direct-exposure scenario valued above the project cost, and false-positive review capacity pre-budgeted so analysts are not pulled away from higher-value investigations. If you cannot price those three items with your own platform data, stay vendor-led and spend the money on faster case handling, not new internal tooling.
Elena, I want the geopolitical angle only where it changes the operating decision. Does the DPRK-linked share of H1 2026 crypto theft indicate a sustained state-financing campaign that should change how a platform evaluates vendor coverage, or is this just a large but ordinary cybercrime concentration? Use caution: I do not want every crypto hack inflated into state attribution. What should the CTI team assume for the next 90 days?
Halil, my operating answer is: yes, this should change vendor-coverage evaluation — but no, it should not become a blanket DPRK label for every crypto hack. The geopolitical fact that changes the decision is Treasury’s statement that DPRK virtual-currency theft and fraud have been used since at least 2017 to generate revenue for its ballistic missile and WMD programs. That makes this more than an ordinary cybercrime cluster. TRM attributed $1.92B in 2025 to North Korea-linked actors, Chainalysis describes DPRK as a persistent primary threat actor in crypto theft, and Elliptic says North Korea launders proceeds through bridges, DEXs, and coinswap services. The reported 2026 “two-thirds” share should be treated as a strong directional signal, but not as automatic attribution for individual incidents.
For the next 90 days, CTI should assume: large thefts against centralized services, custody flows, bridges, governance processes, vendor access, and social-engineering-heavy compromises are inside DPRK’s collection requirement until ruled down. Vendor coverage should therefore be tested for DPRK-specific capability: sanctioned-wallet/entity exposure, cross-chain laundering visibility, IT-worker and contractor-screening intelligence, supply-chain/vendor-access monitoring, bridge/DEX tracing, and incident support for OFAC/sanctions escalation. The key is not “is every hack Lazarus?” The key is: can our vendors distinguish ordinary theft from state-financing theft fast enough to change containment, reporting, and counterparty-risk decisions?
My caution: attribution should require convergence — TTPs, infrastructure, on-chain flows, victimology, and credible vendor/government reporting. But strategically, this is a sustained state-financing campaign, not just a market concentration anomaly.
Rafael, on-demand OSINT check: what parts of a tracing vendor's DPRK laundering coverage claim can a digital-asset platform independently verify from public evidence and its own transaction data? Use the examples in our corpus: Drift, KelpDAO/LayerZero, Humanity Protocol, THORChain/Tornado/bridge routing, OFAC-designated wallets, frozen funds/court actions. Give me a testable evidence checklist and name what cannot be verified without proprietary graph labels or law-enforcement data.
Halil, a platform can independently verify transaction mechanics, but not the vendor’s full identity graph unless the labels are public or shared under NDA.
From the corpus examples, the testable public/on-platform checklist is:
- Incident transaction path: starting exploit wallet, first-hop wallets, token swaps, bridge deposits/withdrawals, DEX aggregator use, and chain-to-chain movement. For Drift, Elliptic reported stolen assets were swapped to USDC via a Solana DEX aggregator and bridged to Ethereum; a platform can test that against its own deposit/withdrawal logs and public chain data.
- Service-touch evidence: whether funds touched Tornado Cash, THORChain, Wasabi CoinJoin, Umbra, LayerZero, or other named routers/bridges. KelpDAO reporting names Tornado Cash, THORChain, Wasabi, Umbra, and LayerZero laundering/bridge use; those interactions are independently checkable at the transaction layer.
- Internal exposure: whether any listed wallet deposited to, withdrew from, traded on, or attempted KYC/account use at your platform. This is where your own transaction data is stronger than public OSINT.
- Known-address sanctions checks: direct or near-direct exposure to publicly named OFAC-designated wallet addresses can be tested, but only for addresses actually published or otherwise independently known.
- Frozen or restrained funds: if funds were frozen on-chain or by a protocol governance/security council, that status may be externally visible. Corpus reporting says roughly $71M tied to KelpDAO remained frozen by Arbitrum’s Security Council pending legal proceedings; a platform should verify the holding address, control mechanism, and any public court docket/order before relying on that number.
- Cross-case wallet overlap: the claimed link between KelpDAO and Humanity Protocol can be partially tested if the same wallets, bridge routes, timing, or exit services are visible on-chain. Cryptopolitan reports investigators saw shared wallets between the two incidents, but the platform should reproduce that path rather than accept the label.
What cannot be independently verified from public chain data alone: the final DPRK attribution, labels like TraderTraitor / UNC4899 / AppleJeus / UNC4736, whether a wallet is controlled by the same operator after mixer/bridge fragmentation, the “only $1.7M remains traceable” claim without the vendor’s graph logic, and any law-enforcement-derived linkage between wallets, exchange accounts, seized funds, or real-world identities. The chain movement is auditable; the actor label usually depends on proprietary clustering, victim forensics, or government-held evidence.
What changed here is that “vendor coverage” became a testable operating claim, not something the platform should accept as a confidence label on a dashboard. Sofia framed the governance issue clearly: even if the public numbers are directionally serious — roughly $972M stolen in H1 2026, with about $643M described as DPRK-linked — the platform still needs an audit trail showing what the vendor actually covers, how labels are generated, what is sanctions-list matching versus behavioral attribution, and how later re-screening changes earlier judgments. The room should retain that caveat: the scale is meaningful, but incident-level attribution and address labeling can mature after the fact.
Pierre gave us a useful business-case frame, but also introduced the assumption we now need to stress-test. His threshold logic says an internal DPRK laundering overlay can pay for itself if it improves freeze escalation, avoided exposure, or retention value by more than its cost; against a 90-day run-rate derived from the public DPRK-linked theft figure, even a small percentage improvement could justify a few hundred thousand dollars of spend. Importantly, he did not argue for replacing the tracing vendor in 90 days. His proposal is vendor graph plus internal overlay, with hard triggers and measurable outcomes.
Elena sharpened why this is not just another fraud category. The DPRK connection matters operationally because public U.S. government statements tie virtual-asset theft and fraud to state revenue generation for weapons programs. That does not mean every large hack is DPRK. It means large thefts involving bridges, custody flows, social engineering, vendor access, and laundering through cross-chain infrastructure should be evaluated with DPRK-specific coverage tests until ruled down.
Rafael then grounded what can actually be verified. A platform can independently check transaction mechanics: exploit wallets, swaps, bridges, mixers, service touches, and whether any of those flows hit its own accounts. What it cannot fully verify from public evidence alone is the vendor’s private identity graph. That sets up the next challenge: Pierre’s ROI math used the whole market-theft run-rate as the denominator. We need to test whether that denominator is too generous for a single platform deciding whether an internal overlay is worth building.
Claim: Your ROI threshold used the entire H1 DPRK-linked market-theft run-rate — about $319.7M over 90 days — which makes a $300K internal overlay look easy to justify.
Counter-evidence: That denominator is not the platform's actual addressable exposure. Rafael says we can independently verify transaction mechanics and our own deposit/withdrawal exposure, but not the full identity graph. Sofia says vendor attribution may still be finalized and is a control input, not an institutional judgment. If our platform only sees a tiny fraction of those flows, or sees them after bridges/mixers, the total-market denominator may overstate payback. Revise the business case using platform-specific exposure and give a go/no-go threshold for a CTI lead.
Halil, you’re right — the $319.7M 90-day market run-rate is not the payback denominator. It is only the threat backdrop. The build/buy denominator must be your platform’s 90-day addressable DPRK exposure: funds you can actually see, score, delay, reject, or freeze before onward movement. Use this formula: Go if C ≤ (E90 × L) + (M × ΔP) + T, where C is 90-day internal overlay cost, E90 is platform-specific freezeable exposure, L is incremental lift versus vendor-only, M is cost of one missed direct exposure, ΔP is the overlay’s reduction in that miss probability, and T is quantified customer-retention/trust value.
For a $300K 90-day internal overlay, my go/no-go is now tighter: Go only if one of these is true: E90 ≥ $10M and you can prove ≥3.0% incremental lift, E90 ≥ $25M and you can prove ≥1.2% lift, or one plausible missed direct-exposure event is ≥$3M and the overlay reduces that probability by at least 10 percentage points. If your observable/freezeable DPRK exposure is only $2M, you would need 15% incremental lift to justify $300K — that is a no-go unless your own transaction data proves it. Also cap false-positive burden as a project-control threshold: if DPRK overlay alerts consume more than 0.5 FTE over the 90 days, the economics deteriorate and you should stay vendor-led.
So the practical recommendation is buy the vendor graph, build only the platform-specific overlay. TRM’s $643M / 66% H1 DPRK signal justifies urgency, not a blank-check build. The operational case comes from speed: TRM says stolen Drift funds were bridged within hours, and the FBI says TraderTraitor actors rapidly converted/dispersed Bybit assets across thousands of addresses and urged VASPs to block derived transactions. For a CTI lead, the board-safe answer is: build only if your own E90 and miss-cost math clears the $300K threshold; otherwise buy, tune response SLAs, and revisit after 90 days with measured exposure.
The key correction is that the big DPRK-linked market number is now back in its proper place: it is threat context, not the ROI denominator. Pierre accepted the challenge. A $300K internal overlay cannot be justified by pointing to an estimated $319.7M ninety-day market run-rate if the platform can only observe or intervene in a much smaller slice of that activity. The room should treat “addressable exposure” as the controlling variable: funds the platform can actually see, score, delay, reject, or freeze before they move on.
That makes the decision more disciplined. Pierre’s revised test says the overlay starts to make sense only when platform-specific exposure and measurable incremental lift are high enough: for example, $10M of ninety-day freezeable exposure with at least 3% lift, or $25M with at least 1.2% lift. Alternatively, a single plausible missed direct-exposure event of $3M or more could justify the work if the overlay meaningfully reduces the probability of that miss. But if the platform’s real freezeable DPRK exposure is only around $2M, the required lift jumps to about 15%, which Pierre treats as a no-go unless internal transaction data proves it.
The caveat is important: these thresholds are not universal truths; they are decision gates based on assumed cost, measurable lift, and the value assigned to avoided misses and customer trust. We still have not verified the platform’s actual exposure, the overlay’s lift over the vendor, or the false-positive cost implied by tighter controls. So the room has moved from “the threat is large” to “the investment must be justified against the platform’s own reachable risk.”
The next turn narrows that same discipline onto named incidents. Instead of using broad DPRK theft figures as a proxy, we need to ask what the corpus actually supports for Drift, KelpDAO, and Humanity Protocol, and where the evidence is stronger, weaker, or only partially attributable.
Lena, narrow this to the user's named examples. Our corpus gives strong detail for Drift and KelpDAO, but for Humanity Protocol it shows a $31M–$36M breach from compromised private key/laptop, rapid H-token-to-ETH conversion, and some reporting of shared wallets or North Korea-associated links. Is Humanity strong enough to include as a DPRK validation case, or should it be treated as a provisional/negative-control case? Give me the exact attribution language you would allow in the vendor-claim brief.
Halil, Humanity is not strong enough as a DPRK validation case. I would treat it as a provisional / negative-control case: the breach reality is high confidence, but the DPRK attribution is only low-to-moderate based on the public chain I see.
Allowed language for the brief:
“Humanity Protocol suffered a ~$31M–$36M theft in June 2026 after attacker access to employee/private-key material enabled unauthorized H-token movement, minting, and rapid conversion/liquidation. Some reporting links the activity to North Korea-associated actors, but available public evidence is not sufficient to treat Humanity as an independently validated DPRK case. We classify it as provisional DPRK-linked activity pending transaction-level wallet clustering, laundering overlap, infrastructure/persona reuse, or law-enforcement/sanctions corroboration.”
I would use Drift and KelpDAO/LayerZero as the primary vendor-claim examples; Humanity belongs in a footnote or sensitivity analysis, not the headline arithmetic. ATT&CK-wise, the defensible pattern is phishing/malicious attachment and endpoint/key compromise — not a named Lazarus validation. Attribution confidence: high incident reality; low-to-moderate DPRK linkage; low precise Lazarus/TraderTraitor naming.
Humanity Protocol just moved out of the headline evidence bucket. Lena’s view is that the incident itself is credible — a roughly $31M–$36M theft tied to compromised employee or private-key material, followed by rapid H-token movement and conversion into ETH — but the DPRK attribution is not strong enough on the public record to carry the argument.
That distinction matters for the roundtable because we are testing vendor claims, not just assembling a list of scary crypto incidents. Drift and KelpDAO/LayerZero can remain the stronger examples for probing whether a provider has meaningful DPRK-relevant detection and tracing coverage. Humanity should be treated more cautiously: useful as a provisional or negative-control case, perhaps in a footnote or sensitivity analysis, but not as a core proof point for “validated DPRK coverage.” The room should not let a real breach plus some public North Korea-associated reporting become stronger attribution than the evidence supports.
The defensible technical pattern Lena preserves is still important: phishing or malicious attachment, endpoint or laptop compromise, private-key exposure, unauthorized token movement, and fast liquidation. But that is a technique pattern, not by itself a Lazarus or DPRK validation. To upgrade Humanity, we would need harder corroboration: transaction-level wallet clustering, overlap with known laundering infrastructure, reused infrastructure or personas, or law-enforcement and sanctions confirmation.
That sets up the next step cleanly. If vendors claim strong DPRK coverage, we should not only ask whether they “saw” these incidents; we should ask what evidence they use to separate confirmed DPRK activity from lookalike key-compromise and laundering behavior. Viktor’s next job is to turn that into a practical claim test: the exact questions, artifacts, and chain-analysis proof we should demand before accepting a tracing vendor’s DPRK attribution or coverage numbers.
Viktor, turn your laundering-pattern answer into a vendor claim test. What exact questions and evidence should we demand from a tracing vendor claiming strong DPRK coverage — chain/bridge/mixer coverage, label latency, clustering method, confidence tiers, backtesting, false negatives — and what minimum in-house analytics are needed to challenge their answers?
Halil, I’d make the vendor prove coverage with evidence, not slogans. Ask for: (1) exact chain/protocol coverage for BTC, ETH, major EVMs, Solana if relevant, THORChain, LayerZero-style bridge flows, Tornado Cash, Wasabi CoinJoin, Umbra, DEX swaps, and known exchange deposit clusters; (2) label latency by category — OFAC SDN address, sanctioned mixer, direct exploit wallet, first-hop wallet, bridge egress wallet, DPRK-attributed cluster; (3) clustering method and confidence tier — direct on-chain link, co-spend/behavioral cluster, exchange/private label, OSINT, law-enforcement-derived, or attribution inference. They must separate “sanctioned exposure” from “DPRK attribution” from “laundering behavior.” Tornado Cash is a good control case because Treasury publicly tied it to laundering over $7B total, including over $455M stolen by Lazarus; KelpDAO is a good pattern case because reporting describes THORChain, Tornado Cash, Wasabi CoinJoin, Umbra, asset conversion, fragmented wallets, and only $1.7M left traceable.
For backtesting, give them a blind “golden set”: public OFAC-designated mixer/service exposure, public DPRK-linked theft flows, clean wallets with no known taint, and ambiguous mixer-adjacent wallets. Demand precision/recall by risk tier, examples of false negatives, and timestamps showing when their labels appeared after public events. Minimum in-house analytics should be enough to challenge the answer: ingest vendor scores, retain raw transaction lineage, independently trace first/second hops, detect bridge/mixer interactions, compare vendor labels against OFAC updates, and run periodic holdout tests. Do not try to rebuild their private graph; do build the controls to catch stale labels, overbroad clustering, and unexplained DPRK flags before they trigger freezes.
Viktor has turned the vendor conversation from “Do you cover DPRK?” into “Show us the audit trail.” The key shift is that a tracing vendor’s claim is not useful unless they can break it down by chain and protocol coverage, how quickly labels appear, how they cluster wallets, and what confidence level they assign to each conclusion. In other words, the room should not accept a single blended score for “North Korea exposure” when that score may actually combine sanctioned-service contact, laundering-pattern similarity, and inferred DPRK attribution.
Two controls stand out from Viktor’s answer. Tornado Cash is useful as a public benchmark because there is official sanctions material and Treasury language around its use in laundering, including Lazarus-linked funds. KelpDAO is useful for a different reason: it tests whether the vendor can follow a messy laundering pattern across THORChain, Tornado Cash, Wasabi CoinJoin, Umbra, swaps, fragmentation, and residual traceability. But even there, we should preserve the caveat: pattern recognition is not the same as identity proof. A vendor may be strong at reconstructing movement and still be weaker at proving who controlled the wallets.
The practical demand, then, is a blind backtest. Give vendors known sanctioned-service exposures, public DPRK-linked theft flows, and clean wallets, then require them to document misses, false positives, confidence tiers, and label latency. Just as important, require them to separate the source of each label: direct on-chain linkage, behavioral clustering, private exchange intelligence, OSINT, law-enforcement-derived information, or attribution inference. That is what would let us compare products rather than marketing language.
This leads naturally into James’s lane: even with good vendor data, defenders can usually verify mechanics and their own exposure better than they can verify the entire adversary identity graph. The next question is how to translate this into an architecture decision: what evidence should sit in the audit file, what should trigger controls, and where the ROI depends on the platform and workflow rather than attribution alone.
James, fold in Rafael/Sofia/Pierre's points: we can verify mechanics and our own exposure, not full identity graph; vendor attribution needs an audit file; full ROI depends on platform-specific E90 and incremental lift. Give me a 90-day implementation plan with phases, staffing, success metrics, and explicit go/no-go criteria for build-vs-vendor reliance.
Halil, I’d frame this as a 90-day control build, not a graph-attribution project. Rafael is right: we verify mechanics and our own exposure; Sofia is right: vendor attribution needs an audit file; Pierre is right: ROI is unknowable until we calculate platform-specific E90 — expected 90-day exposure — and the vendor’s incremental lift over our current controls.
Days 0–30 — establish the control harness. Staff it with one sanctions/compliance owner, one financial-crime analyst, one data/SIEM engineer, one wallet-risk product owner, IR on-call coverage, and vendor management. Build a golden test set: direct sanctioned wallet, known bad cluster, 1–2 hop exposure, mixer/bridge exposure, clean wallets, and stale/false-positive cases. Every vendor hit must generate an audit file: wallet, chain, tx hash, customer/account link, vendor label, confidence, source category, timestamp, analyst decision, and action taken. OFAC guidance supports risk-based sanctions controls and use of blockchain analytics; FinCEN requires SAR copies and supporting documentation to be retained for five years.
Days 31–60 — run parallel and tune. Plug vendor outputs into wallet scoring as separate factors: sanctions match, DPRK attribution confidence, proximity, typology, value/velocity, and customer risk. Do not bury it in one opaque score. Triage thresholds: direct SDN/sanctioned-wallet hit = hold and escalate within 1 hour; direct DPRK-cluster or exploit-proceeds exposure = hold pending compliance review; 1–2 hop or mixer/bridge exposure = same-day manual review; weak proximity-only = watchlist unless repeated. Success metrics: 95% of alerts have complete audit files, p95 triage under 4 hours for High and under 1 hour for Critical, false-positive override rate below 30% for High/Critical, and zero unreviewed Critical alerts at end of day.
Days 61–90 — decide build vs vendor reliance. Go with vendor reliance if the vendor passes at least 90% of golden-set cases, misses no direct sanctions test cases, provides explainable labels, and improves E90 loss/risk reduction enough to justify cost. Build internally only if the vendor repeatedly fails direct-hit tests, cannot explain labels, lacks chain coverage material to our flows, or creates alert volume the SOC cannot work. No-go for production blocking if audit files are incomplete, compliance cannot defend attribution, or business-impact data is still missing.
James has reframed the work in a useful way: this is not a 90-day attempt to prove a complete DPRK identity graph. It is a 90-day build-out of a control system that can test vendor claims, measure our own exposure, and create evidence we can defend later. That distinction matters because it keeps the platform from over-buying attribution certainty while still improving sanctions and financial-crime controls.
The practical shape is now clearer. In the first month, James wants a control harness: named owners across compliance, financial crime, data/SIEM, product, incident response, and vendor management; a golden test set covering sanctioned wallets, bad clusters, hop exposure, mixer or bridge exposure, clean wallets, and stale or false-positive cases; and a required audit file for every vendor hit. That audit file is the backbone here: wallet, chain, transaction hash, customer link, vendor label, confidence, source category, timestamp, analyst decision, and action taken. The room should note the caveat: this does not validate the vendor’s entire intelligence graph. It validates whether the vendor’s output is usable, explainable, and operationally tied to the platform’s own decisions.
The second phase James started to outline is parallel running and tuning: vendor outputs should not collapse into a black-box “DPRK score,” but should be fed into wallet risk as distinct factors that can be compared against current controls. That also preserves Pierre’s ROI concern. We cannot price the value of the tool in the abstract; we need platform-specific expected 90-day exposure, E90, and then measure incremental lift over what the platform already catches.
That naturally puts Sofia back at the center. If the platform is going to rely on “strong DPRK coverage,” the contract and audit file need to say exactly what that reliance means, what evidence the vendor must preserve, and where responsibility remains with the platform.
Sofia, convert your governance advice into a reliance checklist for the vendor contract and audit file. What must be in writing before the platform can rely on 'strong DPRK coverage' for sanctions/AML/incident response decisions, and what cannot be contractually outsourced even if the vendor provides labels?
Halil, my reliance checklist would start with the contract. Before using “strong DPRK coverage” for sanctions, AML, or incident-response decisions, the vendor must define in writing: covered blockchains, bridges, mixers, DeFi protocols, assets, and lookback periods; what “DPRK-linked” means; whether a label is based on sanctions-list matching, law-enforcement/public reporting, clustering, shared laundering infrastructure, or proprietary inference; confidence levels; update frequency; retroactive re-screening; and audit/export rights for transaction graphs, timestamps, hops, amounts, addresses, and analyst rationale. The platform should also require SLAs for label changes, false-positive/false-negative review, escalation support, and preservation of evidence sufficient for auditors and sanctions teams.
For the audit file, I would map each vendor capability to the platform’s own controls: OFAC’s virtual-currency guidance points to a risk-based sanctions compliance program with management commitment, risk assessment, internal controls, testing/auditing, and training, and specifically references sanctions-list screening and blockchain analytics as relevant controls. If the platform is a US-facing CVC exchanger or administrator, FinCEN guidance says money-transmitter obligations can include MSB registration, AML program, recordkeeping, and reporting duties, including SARs and CTRs. So the audit file needs management approval, documented risk appetite, screening rules, alert-disposition records, SAR/escalation criteria, periodic testing, and proof that vendor labels are reviewed rather than blindly accepted.
What cannot be outsourced is the legal judgment. The vendor may provide labels, clustering, and investigative evidence; the platform retains responsibility for sanctions risk acceptance, customer restriction or exit decisions, SAR/OFAC reporting decisions, incident materiality assessment, and any public or regulator-facing attribution claim. Red line: a black-box score alone is not enough for freezes, exits, SAR narratives, OFAC escalation, or board reporting—especially where the claim is only “shared laundering pipeline” rather than address-level evidence with confidence and provenance.
Sofia’s contribution tightens the governance side of the plan: “strong DPRK coverage” cannot remain a marketing phrase if the platform is going to rely on it for sanctions, AML, or incident-response decisions. It has to become a documented reliance basis. That means the contract and audit file need to say exactly what is covered — chains, bridges, mixers, DeFi protocols, assets, lookback periods — and exactly what a DPRK-linked label means.
The important distinction she drew is between different kinds of vendor knowledge. A sanctions-list match, a law-enforcement or public-reporting-derived label, a clustering judgment, shared laundering infrastructure, and proprietary inference are not the same thing. If the platform treats them as equivalent, it creates both operational and regulatory risk. So the checklist needs confidence levels, update cadence, retroactive re-screening, audit/export rights, evidence preservation, escalation support, and a process for false positives and false negatives. In other words, reliance is not just about whether the vendor has data; it is about whether the platform can later explain how that data was used, challenged, and retained.
The caveat is also important: Sofia is not saying a contract can transfer the platform’s compliance obligation to the analytics vendor. The vendor can provide coverage, labels, tooling, and supporting evidence, but the platform still owns the risk-based sanctions compliance program, internal controls, testing, training, management accountability, and decision logic. That is the boundary we need to preserve in the final synthesis.
So the discussion now lands in a more defensible place. We have a technical testing path from James, and Sofia has converted the governance layer into a reliance framework: define the claim, test the claim, document the claim, and never confuse vendor assurance with regulatory accountability.
TRM’s reported H1 2026 figure — about $643M in North Korea-linked crypto theft out of roughly $972M total losses — is strong enough to justify a DPRK-focused validation capability, but not a full in-house replacement for a blockchain tracing vendor. The panel’s consensus is to build a 90-day internal control harness: verify vendor labels, test coverage, preserve evidence, and connect alerts to wallet-risk scoring and freeze/escalation workflows. Drift and KelpDAO/LayerZero are suitable primary validation cases; Humanity Protocol should be treated as provisional or sensitivity analysis unless wallet clustering, laundering overlap, or official corroboration strengthens the DPRK attribution. Vendor coverage is sufficient only if it is explainable, testable, timely, and defensible in sanctions/AML governance files.
TRM’s $643M/roughly two-thirds H1 2026 figure is a credible risk signal, but attribution should remain source-bound: use “North Korea-linked according to TRM/reporting,” not “confirmed DPRK,” unless corroborated by wallet clustering, infrastructure/persona reuse, sanctions, law-enforcement, or multi-vendor evidence.
DPRK laundering behavior is distinctive enough for hypothesis-building and control testing — rapid conversion, bridge movement, fragmentation, mixer/CoinJoin exposure, and exchange deposit attempts — but not enough to attribute on its own.
The right build is not a second tracing platform; it is an internal overlay that can independently verify transaction mechanics, first/second-hop exposure, bridge/mixer interactions, vendor label latency, false positives, and the platform’s own observable exposure.
Humanity Protocol should not be used as a headline DPRK validation case on current public evidence; Drift and KelpDAO/LayerZero are stronger benchmark cases.
The business case depends on platform-specific freezeable exposure and incremental lift over vendor-only controls, not the total market theft run-rate.
Build a 90-day vendor validation harness: golden test set, weekly re-screening, alert audit files, label-latency checks, and explicit pass/fail criteria for direct sanctions hits, DPRK-linked clusters, exploit proceeds, bridge/mixer exposure, and clean negative controls.
Require the tracing vendor to document covered chains, bridges, mixers, assets, label provenance, confidence tiers, update frequency, retroactive re-screening, export rights, false-positive/false-negative review, and escalation SLAs before relying on “strong DPRK coverage.”
Integrate vendor outputs into wallet-risk scoring as separate explainable factors — sanctions match, DPRK attribution confidence, proximity, typology, velocity/value, and customer risk — rather than one opaque risk score.
Use Drift and KelpDAO/LayerZero as primary validation cases; keep Humanity Protocol in a provisional bucket pending stronger attribution evidence.
Reassess after 90 days: continue vendor reliance if golden-set pass rate, explainability, triage speed, and audit completeness meet thresholds; expand internal capability only if the vendor fails material coverage, attribution, or operational requirements.