Today we are introducing Transaction Screening, a new security surface on DFNS. Before a transfer is signed on the dashboard, the destination now passes through a screening step built to catch what human eyes cannot. The first check is live today: lookalike detection, protection against address poisoning, one of the most effective scams in digital assets. We also add a warning if this is the first time transacting with an address (even if it isn’t a lookalike).
More checks will follow on the same surface, some built by DFNS, some drawing on the best threat intelligence in the industry. One screening point, growing coverage, in front of every transfer.
The attack: poisoning your transaction history
Blockchain addresses are not human-readable, so interfaces truncate them. A wallet, an explorer, a dashboard shows the first few characters, an ellipsis, and the last few. Every major interface does it:
| Interface | What you actually see |
|---|---|
| MetaMask | 0x8095c…f05d7 |
| Etherscan | 0xD0A5ca4f…7b761064B |
| Solscan | AVEFn…BAda5 |
| DFNS Dashboard | 0xc2a7…f401…82cf |
And in practice, that is how people send money: copy an address from transaction history, paste, transfer.
Address poisoning exploits exactly that habit. An attacker generates an address whose visible ends match one of your real counterparties, computationally expensive, but feasible, then plants it in your history by sending you dust: a tiny amount of real crypto, or a fake token dressed as a real one. The next time you copy “that” address from your history, you may copy the impostor. The middle characters, the only ones that differ, are the ones the interface hides. An attacker only needs to forge the characters you can see. Funds sent are funds gone.
The scale is documented. Researchers at Carnegie Mellon University measured address poisoning across Ethereum and BSC over two years and found 270 million attack attempts targeting 17 million victims, thirteen times more than previously reported, with 6,633 successful incidents draining at least $83.8 million, one of the largest phishing operations ever observed onchain. And the victims are not random. The study found attackers profile their targets, preferentially hunting wallets with higher balances, more activity, and larger transfers, typically striking within twenty minutes of a victim’s original payment. The wallets attackers want most, in other words, look exactly like institutional wallets.
The first check: lookalike detection
The defense borrows the attacker’s own constraint. Our detection adapts the prefix and suffix collision method from Blockchain Address Poisoning, the Carnegie Mellon study above, whose detector achieved 100% precision with 97.2% recall against those 270 million real attacks: every flagged address was genuinely malicious, and almost none slipped through. Rather than computing edit distances across the entire address, we compare only the leading and trailing characters, the same characters wallet interfaces and block explorers actually display. Because the attacker must forge exactly the visible portions, a collision in that narrow window is statistically improbable under normal use, and is itself the signal.
Detection fires on any of three patterns:
| Mode | Fires when | Catches |
|---|---|---|
| Two-sided | First 3 and last 3 visible characters match | The classic poisoning attack, forged at both ends |
| Deep prefix | First 4 characters match | One-sided prefix forgeries |
| Deep suffix | Last 4 characters match | One-sided suffix forgeries |
All three modes also test single-character transpositions, catching the forger who swaps two adjacent characters to slip past both your eyes and a naive exact-match filter. And matching ignores the constant prefixes some networks impose, the 0x on EVM addresses, Tron’s T, Stellar’s G, so no attacker gets free matched characters.
Crucially, screening is scoped to the individual wallet, not your whole organization. That is what keeps the math honest. Here is what our production data shows about unique destination addresses per wallet:
| Network | Median | p99 | p99.9 |
|---|---|---|---|
| Polygon | 1 | 2 | 3 |
| Ethereum | 1 | 16 | 233 |
| Solana | 1 | 16 | 190 |
| Tron | 1 | 13 | 246 |
| Stellar | 1 | 2 | 5 |
| Base | 1 | 9 | 752 |
| Bitcoin | 1 | 25 | 269 |
The median wallet pays one address. Ninety-nine percent pay fewer than twenty-five. A visible-window collision inside one wallet’s history is a genuine anomaly, not a statistical inevitability.
A warning, not a wall
Transaction Screening warns, but does not block. That is deliberate. A false positive costs you one click to review and dismiss. A missed poisoning attack costs real funds. That asymmetry argues for warning generously, and the numbers make generous warnings cheap. Here is the false-warning rate on a transfer to a never-before-seen address:
| Chain family | Alphabet size | At p99 | At p99.9 |
|---|---|---|---|
| EVM (hex) | 16 | 0.20% | 8.8% |
| Solana, Tron (Base58) | 35 | 0.009% | 0.13% |
| Stellar (Base32) | 32 | 0.002% | 0.004% |
For 99% of wallets, the worst case is about one warning per five hundred transfers to a new address, on EVM, and far lower everywhere else. The tail is real and we are publishing it anyway: the 0.1% of wallets at that extreme are almost always programmatic, payment processors and sweepers that do not copy-paste from history, and for them a warning costs a click. The check runs only when you send to an address the wallet has never paid before, so repeat destinations, the bulk of real volume, flow untouched, and programmatic integrations are unaffected.
Screening also complements, rather than replaces, the strongest tools you already have. Destinations in your Address Book, and transfers governed by allowlist policies in the Policy Engine, sidestep the copy-paste attack surface entirely. Transaction Screening is the safety net under everyone who doesn’t use them for every transfer, which, honestly, is everyone.
One surface, growing coverage
Transaction Screening is built as a surface, not a single feature: an extensible checkpoint in front of every transfer on the dashboard, designed to host more checks over time. The coverage will grow two ways.
Some checks we will build ourselves, where the signal lives in data DFNS already holds. On the roadmap: flagging the inbound dusting transactions that plant lookalikes in the first place, scrutiny of fake-token transfers and suspiciously tiny amounts, and cross-chain detection at the key level, catching the attacker who observes your Ethereum payments and poisons your Polygon wallet with the same forged address.
Others we will bring in from the companies that do this best. DFNS already orchestrates best-in-class intelligence in the execution path, transactions are screened through Chainalysis, Elliptic, and Notabene before signing, and Transaction Screening extends the same philosophy to onchain threat intelligence, with providers like Blockaid and Hypernative representing the class of simulation and threat-detection signals the surface is built to host.
The division of labor is the point. Intelligence can come from anywhere, the best feed should win. Enforcement lives in one place: below the API, at the platform that signs, where the Policy Engine already governs every movement. A warning is only worth what the layer underneath it can do about it. On DFNS, that layer is the product.
Availability
Transaction Screening with lookalike detection is live for dashboard transfers, screening destinations across the networks where these attacks occur, including Ethereum, Polygon, Base, BSC, Arbitrum, Avalanche and other EVM chains, plus Solana, Tron, Stellar, Bitcoin, the XRP Ledger, TON, and ION. The screening endpoint will be exposed through the API once it stabilizes, so programmatic flows can consume the same signal. Copy, paste, verify has always been the advice. Now the platform does the verifying with you.
Get started
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Talk to our team: sales@dfns.co