DEV Community: XenoVenom

How I Built a Zero-Database Address Poisoning Detector for Crypto Wallets

XenoVenom — Tue, 27 Oct 2026 20:24:40 +0000

Detecting the silent scam that tricks users into sending funds to the wrong address — without storing any data.

The Silent Killer of Crypto

Address Poisoning is one of the most psychologically deceptive scams in Web3. It doesn't exploit smart contracts. It doesn't use malicious code. It exploits human habit.

Here's how it works:

You send 100 USDC to your friend at 0x1234...5678
A scammer bot monitors the mempool and sees this transaction
The scammer sends a 0-value transaction FROM an address that looks almost identical: 0x1234...5679
Both transactions now appear in your MetaMask activity history
Next time you want to send funds to your friend, you copy the address from your history
You accidentally copy the scammer's address (because it looks 99% identical)
You send your funds to the scammer

The scary part? No security tool catches this. The transaction is technically valid. The address is real. The wallet sends it. The funds are gone.

Why Traditional Tools Miss It

Most crypto security extensions rely on blacklists — databases of known scam addresses. But address poisoning doesn't use "known scam addresses." It uses freshly generated wallets that:

Have no transaction history
Aren't on any blacklist
Look identical to legitimate addresses
Change with every attack

A blacklist-based tool sees the transaction and says: "This address isn't on our bad list. Looks safe!"
But it's not safe. It's a trap.

The Solution: Local History + Heuristic Matching

I realized the answer wasn't a better database — it was a better pattern.
Instead of checking if an address is "known bad," we check if it looks suspiciously similar to one the user has interacted with before.

Here's the architecture:

Track every address the user successfully interacts with (stored locally)
Compare new transaction targets against this local history
Detect if a new address shares the first 6 and last 4 characters with a known address
Block the transaction with a visual warning

No database. No API calls. No tracking. 100% local.

The Technical Implementation

Step 1: The History Bridge
Because the core interception engine runs in the browser's MAIN world (to hook into window.ethereum), it can't access Chrome's storage API directly. So I created a bridge — a content script that listens for messages from the engine and handles storage.

// contents/history-bridge.ts
window.addEventListener("message", async (event) => {
  // Check if an address is potentially poisoned
  if (event.data.type === "SAFESIGN_CHECK_POISON") {
    const checkAddress = event.data.payload.toLowerCase()

    // Fetch previously interacted addresses from local storage
    const result = await chrome.storage.local.get("safesign_history")
    const history: string[] = result.safesign_history || []

    let isPoison = false
    let matchedSafeAddress = ""

    for (const safeAddr of history) {
      if (safeAddr === checkAddress) {
        // Exact match = definitely safe
        isPoison = false
        break
      }

      // Heuristic: Check first 6 and last 4 characters
      if (safeAddr.length >= 10 && checkAddress.length >= 10) {
        const safeStart = safeAddr.slice(0, 8) // "0x" + 6 chars
        const safeEnd = safeAddr.slice(-4)
        const checkStart = checkAddress.slice(0, 8)
        const checkEnd = checkAddress.slice(-4)

        if (safeStart === checkStart && safeEnd === checkEnd) {
          // Similar but NOT exact = poison!
          isPoison = true
          matchedSafeAddress = safeAddr
          break
        }
      }
    }

    // Send result back to the engine
    window.postMessage({ 
      type: "SAFESIGN_POISON_RESULT", 
      payload: { isPoison, matchedSafeAddress, checkAddress } 
    }, "*")
  }

  // Add safe addresses to history after successful transactions
  if (event.data.type === "SAFESIGN_ADD_HISTORY") {
    const newAddress = event.data.payload.toLowerCase()
    const result = await chrome.storage.local.get("safesign_history")
    const history: string[] = result.safesign_history || []
    if (!history.includes(newAddress)) {
      history.push(newAddress)
      // Cap at 100 addresses to save space
      if (history.length > 100) history.shift()
      await chrome.storage.local.set({ safesign_history: history })
    }
  }
})

Step 2: The Detection Engine
In the main interception engine, before any transaction passes through to wallet, we ask the bridge to check the destination address:

// contents/ethereum-listener.ts
if (args.method === "eth_sendTransaction") {
  const toAddress = txParams?.to?.toLowerCase()
  const fromAddress = txParams?.from?.toLowerCase()

  // Address Poisoning Check
  if (toAddress && fromAddress) {
    const poisonCheck = await checkAddressPoisoning(toAddress)

    if (poisonCheck.isPoison) {
      // BLOCK: Show the Red Warning UI
      window.postMessage({ 
        type: "SAFESIGN_ALERT", 
        payload: { 
          dangerType: "POISONED_ADDRESS", 
          scamAddress: toAddress,
          rawData: `Similar to: ${poisonCheck.matchedSafeAddress}` 
        } 
      }, "*")
      throw new Error("SafeSign: Blocked Address Poisoning")
    }
  }

  // ... other security checks (blacklist, approvals, permits, etc.)

  // If all checks pass, add to history
  if (toAddress) {
    window.postMessage({ 
      type: "SAFESIGN_ADD_HISTORY", 
      payload: toAddress 
    }, "*")
  }
}

The checkAddressPoisoning helper uses a Promise-based message pattern to communicate with the bridge:

const checkAddressPoisoning = (address: string) => {
  return new Promise<{ isPoison: boolean, matchedSafeAddress: string }>((resolve) => {
    const handleMessage = (event: MessageEvent) => {
      if (event.data.type === "SAFESIGN_POISON_RESULT") {
        window.removeEventListener("message", handleMessage)
        resolve(event.data.payload)
      }
    }
    window.addEventListener("message", handleMessage)
    window.postMessage({ type: "SAFESIGN_CHECK_POISON", payload: address }, "*")
  })
}

The Heuristic: Why 6 and 4?

You might wonder: why check the first 6 and last 4 characters?

Ethereum addresses look like this: 0x + 40 hex characters.
Scammers typically create vanity addresses that match:

First 4-6 characters (what users visually scan)
Last 4 characters (what users visually scan)

By checking 6 + 4, we catch:

✅ The most common poisoning pattern
✅ False positives are rare (1 in 4 billion chance of accidental match)
✅ It's fast (simple string comparison)

Could we check more characters? Yes, but:

More characters = more false negatives (scammers might only match 4+4)
The 6+4 heuristic is the sweet spot between safety and accuracy

The Privacy Architecture

This was the most important design decision: zero data leaves the browser.

✅ No backend server
✅ No API calls
✅ No analytics
✅ No tracking
✅ History capped at 100 addresses (~4.2 KB)
✅ Stored in chrome.storage.local (user's hard drive, not cloud)

The UX Decision: Why a Red Warning?

When the detector triggers, SafeSign doesn't just silently block the transaction. It shows the Time-Travel UI with a specific message:
"ADDRESS POISONING DETECTED"
This address looks almost identical to one you have used before, but it is a fake. Sending funds here will lose them forever.

Why not a passive notification? Because:

Users need to understand WHY — otherwise they'll just retry with the same poisoned address
Visual storytelling beats technical jargon — "looks almost identical" is something anyone understands
The Red UI creates a moment of pause — users stop and think before acting

What This Catches (And What It Doesn't)

✅ Catches:

Classic address poisoning (similar start + end)
Vanity address spoofing
Zero-value token transfers that pollute transaction history

❌ Doesn't Catch (Yet):

Addresses that only match 4+3 characters (too aggressive to block)
Addresses with no prior history to compare against
Cross-chain poisoning (Solana, etc.) — coming in v2.0

The Bigger Picture

Address Poisoning is just one of the scams SafeSign blocks. But it represents something bigger: the philosophy of proactive, local-first security.
Instead of:

❌ Waiting for someone to report a scam address
❌ Maintaining a massive database
❌ Sending user data to a server for analysis

We:

✅ Analyze patterns locally
✅ Protect privacy by design
✅ Catch zero-day scams that no database knows about

This is the future of crypto security — not bigger databases, but smarter heuristics.

Try It

SafeSign is 100% free and open-source. If you want to protect yourself from address poisoning (and 6 other scam types), install it today.

🔗 Chrome Web Store: SafeSign Visualizer
💻 GitHub: XenoVenom/safesign-visualizer
🌐 Landing Page: https://safesignvisualizer.vercel.app/

This is Devlog #2 in a series about building SafeSign. In the next devlog, I'll break down how I intercept gasless EIP-2612 Permit signatures before wallet opens.

Why I Built SafeSign: The Panic UI Problem in Crypto Security

XenoVenom — Thu, 22 Oct 2026 16:53:04 +0000

How watching friends get scammed led me to rethink crypto security from the ground up.

The Problem

If you spend enough time in Web3, you eventually see a friend get their wallet drained. It's devastating. One minute they're excited about a new DeFi opportunity, the next they're staring at a $0 balance and a transaction they don't remember authorizing.

I've been there. Multiple times. Watching friends lose money to scams I could see coming—but couldn't explain to them in time.

The most frustrating part wasn't the loss itself. It was the UI.

The Flaw: Hex Codes Cause Alert Fatigue

When a user encounters a malicious smart contract, most existing security tools show them something like this:

⚠️ MALICIOUS TRANSACTION DETECTED
Risk: HIGH
Function: 0x095ea7b3
Data: 0x095ea7b3000000000000000000000000deadbeef...

To a developer, this means: "Unlimited approval to a suspicious address."

To a normal user, this means: "I have no idea what this says. I'll just click Ignore."

And that's exactly what happens. Users experience alert fatigue. They see scary-looking warnings they don't understand, and eventually they start ignoring them entirely. Or worse—they disable the security tool altogether because it "keeps interrupting them."
This is the dirty secret of crypto security tools: they're built by security engineers, for security engineers.
The mass market—the regular people these tools claim to protect—can't use them effectively.

The "False Sense of Security" Problem

There's a second, deeper flaw: blacklist dependency.
Most existing tools check transactions against a database of known bad addresses. If the address isn't on the list, the tool says "Safe."
But scammers create new addresses every single minute. A brand-new scammer address won't be on any blacklist yet. The tool says "Safe"—and the user gets drained anyway.
This creates a false sense of security. Users trust the tool, the tool gives them a green light, and they lose everything.
The system is reactive, not proactive. It waits for someone to lose money, then adds the address to a list. That's not protection—that's a obituary.

The Solution: Visual Storytelling

I realized the answer wasn't a better database—it was a better language.
Instead of showing users hex codes and function signatures, what if we showed them the consequence?

Instead of:
Error: 0x095ea7b3...

Show them:

Now: You click Sign.
+2 Seconds: Site gets Unlimited Access.
+10 Seconds: Wallet Drained. Balance: $0.

This is the "Time-Travel UI" concept. It doesn't ask users to understand bytecode. It shows them what happens next.
When a user sees a visual timeline of their wallet being drained, they don't need to understand setApprovalForAll or approve(spender, MAX_UINT). They understand "drained." They understand "$0." They understand "don't click."
Visual storytelling beats technical jargon. Every time.

The Philosophy: Security as a Public Good

As I built SafeSign, I made three core decisions that shape everything:
1. Proactive, Not Reactive
SafeSign doesn't just check blacklists. It analyzes the logic of the transaction. If a contract asks for unlimited approval, SafeSign blocks it—even if the address is brand new and not on any list. It catches zero-day scams by understanding what the code does, not just who submitted it.

2. Privacy-First, Always
No data collection. No tracking. No backend. Every analysis happens locally in the browser. Your wallet history, your transaction data, your browsing habits—none of it leaves your machine. Security tools shouldn't require you to surrender your privacy to be protected.

3. Open-Source, Transparent
The entire codebase is on GitHub. Anyone can read every line. Anyone can verify there's no malicious behavior. Anyone can fork it, improve it, or audit it. In crypto, the rule is "don't trust, verify." I take that literally.

What SafeSign Actually Does

Since launching, SafeSign has grown into a comprehensive security layer:

Unlimited Approval Blocks (ERC-20 token drains)
NFT Collection Drain Blocks (setApprovalForAll)
Gasless Permit Drain Blocks (EIP-2612 fake login scams)
Address Poisoning Detection (local, zero-database)
Proactive Anti-Phishing (known scam sites blocked entirely)
SIWE Domain Spoof Detection (catches fake "Sign-In With Ethereum")
Auto-Pause on Localhost (developer-friendly)
Visual Time-Travel UI (the core differentiator) All free. All open-source. All local.

The Mission

If you want to protect your wallet (or just want to see the Time-Travel UI in action), SafeSign is free on the Chrome Web Store.

The code is on GitHub. Read it. Fork it. Improve it.

Security should be a public good.

🔗 Links:
Chrome Web Store
GitHub
Twitter/X

This is the first in a series of devlogs about building SafeSign. Next time, I'll break down the technical architecture of how I intercept window.ethereum requests before wallet opens.

How I built a Chrome Extension to intercept Crypto Wallet Drains (EIP-2612 & ERC-20)

XenoVenom — Mon, 31 Aug 2026 19:03:51 +0000

If you spend enough time in Web3, you eventually see a friend get their wallet drained. The most frustrating part isn't just the loss of funds; it's the UI.

When a user encounters a malicious smart contract, standard security tools often throw hex codes at them:

⚠️ Error: 0x095ea7b3...

Normal users panic, don't understand the alert, and click "Ignore" anyway. Or worse, they get "alert fatigue" and turn the tool off completely.

I wanted to solve this "False Sense of Security" problem. So, I built SafeSign Visualizer—an open-source Chrome extension that intercepts malicious transactions before MetaMask opens, and translates them into a "Visual Time-Travel UI" that anyone can understand.

In this post, I'll walk through the core architecture of how to intercept and decode Web3 scams using Plasmo and React.

🧠 The Architecture: The "Man-in-the-Middle" Shield
Chrome Extensions live in an "Isolated World." They cannot see the window.ethereum object that MetaMask injects into a webpage.

To intercept a transaction, we must inject a script into the MAIN world of the page before MetaMask loads, and overwrite the window.ethereum.request function with a Proxy.

Using Plasmo, this is incredibly clean. We create a content script that runs at document_start:

import type { PlasmoCSConfig } from "plasmo"export const config: PlasmoCSConfig = { matches: [""], run_at: "document_start", world: "MAIN" // This is the magic key}const intercept = () => { if (window.ethereum) { const originalRequest = window.ethereum.request // Overwrite the request function window.ethereum.request = async (args) => { // 1. Analyze the transaction // 2. If bad -> throw error (stops MetaMask) // 3. If good -> return originalRequest(...) } } else { setTimeout(intercept, 50) // Wait for wallet to load }}intercept()

🛡️ Decoding the Scams (Heuristics)
Once we intercept the request, we need to analyze the args.params[0].data to see what the smart contract is actually trying to do.

The Unlimited Token Approval (ERC-20) The most common drain. A site asks you to swap, but the hidden code calls the approve function (0x095ea7b3) with the maximum possible integer (ffffffff...).

if (args.method === "eth_sendTransaction") {
  const data = args.params?.[0]?.data

  if (data.startsWith("0x095ea7b3")) {
    // Extract the amount (last 32 bytes)
    const amountHex = data.slice(74)
    const maxUint = "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"

    if (amountHex === maxUint) {
       // BLOCK! Scammer is asking for infinite access.
    }
  }
}

The "Invisible" Gasless Drain (EIP-2612) This is the most dangerous scam right now. Scammers use a fake "Sign-In With Ethereum" button. It costs no gas, so users think it's harmless. But hidden in the eth_signTypedData_v4 payload is a Permit signature.

By signing it, the user gives the scammer a legal off-chain permission slip to drain their USDT later.

To stop this, we parse the JSON payload of the signature request:

if (args.method === "eth_signTypedData_v4") {
  const typedData = JSON.parse(args.params[1])

  const isPermit = typedData?.primaryType === "Permit"
  const hasPermitFields = typedData?.message?.spender && typedData?.message?.value

  if (isPermit || hasPermitFields) {
     // BLOCK! This is a gasless permit drain.
  }
}

🎨 Visual Storytelling (The UI)
When a scam is detected, we throw an error to stop MetaMask from opening, and we send a window.postMessage to our React Content Script UI to mount a full-screen overlay.

Instead of technical jargon, we show a timeline of the consequence:

Now: You click sign.
+2 Seconds: Site gets Unlimited Access.
+10 Seconds: Wallet Drained.
This "Visual Storytelling" approach ensures that non-technical users actually understand why they shouldn't click sign, rather than just ignoring a red warning box.

🚀 Open Source
I built SafeSign to be 100% free, open-source, and privacy-first. There is no backend, no tracking, and no data collection. All analysis happens locally in the browser.

If you want to look at the exact code, borrow the interception logic for your own dApp, or install it to protect your own wallet, you can find it here:

💻 GitHub Repository
🌐 Chrome Web Store
I'd love to hear your feedback on the architecture or any ideas you have for improving the heuristics!