A sanctions list only names the wallets it already knows, and stolen money keeps moving through new ones. Lazarus Scan checks the wallet you're about to pay: how many transfers stand between it and a known Lazarus Group address. A policy decides what counts, and Newton Protocol operators enforce exactly that policy and sign the result, so every step of it can be verified.
Lazarus Scan is a working demo running on testnet, and this article walks through how it works.
Who Lazarus is
Lazarus Group is North Korea's state hacking operation, under US sanctions since 2019. What it steals helps fund the country's weapons programs, and in 2025 it took more crypto than every other attacker combined.
- $1.5bn taken from Bybit in February 2025, the largest crypto theft on record
- $2.02bn stolen in 2025, a record year
- $6.75bn stolen in total, by the lower-bound estimate
A list checks one address
Stolen funds move fast through fresh wallets that no list has named yet. After Bybit, the FBI asked exchanges and DeFi services to block transactions "with or derived from" the laundering addresses.
A list check compares one address against a set. But the money travelled along a path, so the wallet you're about to pay can pass cleanly while sitting one transfer away from a listed one.
Check the wallet before you pay it
Every outgoing transfer is a decision about who you're paying: a vendor, a contributor, an address a customer typed in. That wallet can pass every list check and still sit one or two transfers from Lazarus. Pay it and your funds go down a laundering path, and that wallet ends up in your own history, where it comes back in an audit or a regulator's question.
The check and the enforcement are different jobs
The demo runs in two steps, and they're kept apart on purpose.
The check is the policy. A policy is a rule plus the data it reads. Here the data is a wallet scanner built on a list of known Lazarus addresses, and the rule is how many hops count. Anyone can write a policy, with their own data and their own rule.
The enforcement is done by Newton. Newton Protocol operators run the chosen policy on the wallet, a quorum of them signs the result, and that signed attestation is public on Newton Explorer. They don't judge the wallet themselves. They make sure the result you get is the one the policy gave.
So a result is only as good as its policy and its data. The limits further down belong to the data, the same ones every onchain tracing tool has. They aren't limits of the protocol.
That split is what makes the result worth trusting. Without it, you'd have to trust whoever ran the scan. With it, a quorum of operators signs the result where anyone can verify it, and you can change the rule or the data without changing who enforces it.
Hops are your risk appetite
Distance is counted in hops, and one hop is one transfer. Policy A flags Lazarus addresses and wallets one transfer away. Policy B goes up to two, Policy C up to three. The same payment can pass or fail on that choice alone.
A wallet that passes is never shown as clean when it isn't. If the scanner found a link outside the policy's reach, the result says so in yellow, with the full path, so you can decide whether to pay anyway.
How far each policy reaches
The first two hops are mapped ahead of time, so every wallet in them is known before a check runs. The third hop is read live from the wallet you're paying, which is why it has no fixed count: it covers any wallet whose own transfers touch one of the 11,078 mapped wallets.
Newton enforces whatever the policy says
The picker has a fourth option, in yellow: Policy D, which allows every wallet. It's a real policy, deployed on Sepolia like the other three. It's there to make one point.
Run a known Lazarus address under Policy D and it comes back Compliant, signed by the same operators that block it under Policies A to C. The scanner still finds it, and the page still shows it on the list. The operators did their job: they enforced the policy they were given.
Newton makes sure the policy ran as written and its result wasn't changed. Picking the right policy is up to whoever relies on it.
The evaluation result: Compliant or Non-compliant, labelled with the policy that gave it. The line under it says what the data found.
The path: every wallet between this one and the Lazarus address, and the transfer linking each pair. Each step opens on Etherscan, and the Lazarus label opens on Arkham.
The attestation: signed by Newton Protocol operators. The attestation opens on Newton Explorer, where anyone can see the task and the quorum that signed it. The page also checks the attestation against its own screening under the same policy, and shows a warning if the two ever disagree.
From a list to a signed result
Each check reads a little live data against a map built ahead of time, then hands the result to Newton Protocol operators. Steps 1 to 5 are the policy's data. Step 6 is where Newton takes over.
- The list: 3,597 Ethereum addresses that Arkham attributes to the Lazarus Group, pulled on 7 September 2026.
- The map: the two hops around the list were mapped ahead of time from public transfer data: 3,644 wallets one hop out and 3,837 two hops out. That keeps a check to three calls instead of hundreds.
- The live hop: the wallet you're paying has its own transfers read at the moment of the check, which takes the scan out to the third hop.
- Services end a path: exchanges, bridges and mixers can end a path but never sit in the middle of one. Otherwise everyone who used the same exchange would count as connected.
- A floor against dust: transfers under $300 don't count, valued at the price on the day they happened, so nobody can taint a wallet by sending it a few cents.
- The signed result: each policy has its own client on Sepolia. For Policies A to C, operators read the scanner through a WebAssembly oracle, reach a quorum and sign the result.
The list comes from Arkham
Deciding which wallets belong to Lazarus is the hard part, and Arkham did it. The demo's address list was pulled from the Lazarus Group entity on Arkham Intel through Arkham's API. That entity returned more than 15,800 distinct addresses across 17 chains, 3,597 of them on Ethereum. Arkham's labels also supplied 52,659 exchange, bridge and mixer addresses, which the scanner treats as the end of a path.
Every Lazarus address in a result links to its label on Arkham, so the attribution can be checked too. The demo pulled the list once. A production setup can keep it live through the same API: re-pulling the entity picks up newly attributed wallets, the transfer and counterparty endpoints follow stolen funds as they move, and Arkham Intel can alert you whenever a known Lazarus wallet moves funds. Thanks to the Arkham team for the attribution that makes a check like this possible.
Lazarus Group on Arkham:
https://intel.arkm.com/explorer/entity/lazarus-group
Arkham API docs:
https://docs.intel.arkm.com/
What it doesn't do
These come from the policy's data and from the demo itself, not from Newton.
- A dated list: the address list was pulled on 7 September 2026 and the map built on 10 September. Neither is refreshed in this demo, though Arkham's API can keep the list current.
- A prebuilt map: the two hops around the list are mapped ahead of time, so a wallet that touched the list after that is only found through the live hop.
- Three hops and no further: past three hops the check says nothing. A wallet with no link found has no path under these rules, which is a narrower claim than calling it clean.
- Ethereum only: the scanner reads Ethereum transfers. Money that crosses a bridge to another chain leaves its view.
- Outgoing payments only: the check screens the wallet you're paying. It doesn't screen who sends money to you.
- On testnet: the transfer data is public Ethereum data from Etherscan. The policies live on Sepolia and the attestations on the Newton testnet. Moving to mainnet means deploying the same policies there.
See it decide
Pick a policy, pick a wallet, and watch Newton Protocol operators sign the result.