✦ Wallet defense
Perpblock signs nothing dangerous.
Five coordinated defenses for the attacks that actually drained wallets in 2024-25: drainer signatures, three flavors of address poisoning, fake wallet extensions, and session-key abuse. Built into the signing flow. On by default.
Transaction simulation
Approval scanner
Address poisoning defense
Wallet authenticity check
Session-key hardening
✦ The problem
The dominant 2024-25 attack wasn't an exchange hack.
It was a signature you gave voluntarily. Permit2 unlimited approvals. setApprovalForAll grants. Transaction-history poisoning that planted a fake recipient in your wallet's display. Drainer telemetry from MetaMask, ScamSniffer, and Wallet Guard tracks $20K-$200K losses per victim, with reported losses across the category in the hundreds of millions per year.
MetaMask added basic simulation in late 2024 — optional, often disabled, doesn't cover every signature type. Most platforms hand you a transaction modal that says "Approve" with no explanation of what you're approving. We took the opposite view: defending the signing surface is the platform's job, not the wallet vendor's.
Five defenses. Coordinated. On by default.
✦ Defense 1
See what happens before it happens.
Every transaction and every EIP-712 signature you're about to sign through Perpblock gets simulated against live chain state first. You see in plain English what will happen, in dollars.
A danger classifier runs on every simulation. Unlimited approval — dangerous. Recipient outside your address book — caution. Net assets going out without value coming in — dangerous. Dangerous results block the signing flow with an explicit warning that requires a confirmed override.
Simulations run via Tenderly and Alchemy with cross-validation. When both providers are unreachable, simulation defaults to "caution" rather than "safe." The platform doesn't pretend it knows what you don't.
You see the trade in your wallet's language and ours. If they don't match, you don't sign.
0x3Fc9...8b2d (unknown contract)
MAX_UINT256 · 187 days ago
Uniswap V3 Router (verified)
MAX_UINT256 · 92 days ago
0x7a4c...f3e1 (unknown contract)
setApprovalForAll · 341 days ago
Aave V3 Pool (verified)
10,000.00 · 14 days ago
✦ Defense 2
Old approvals are the slow leak.
The drainer signature you gave six months ago is still active. The Permit2 allowance you forgot about. The setApprovalForAll on that NFT collection you tried once. Old approvals are the dominant standing exposure in self-custody — a clean wallet today is a drained wallet tomorrow because an old approval got exploited by a new contract.
After you connect a wallet, and every Sunday morning, the scanner checks every wallet you've connected for outstanding ERC-20 approvals (especially MAX_UINT256), Permit2 allowances, and ERC-721/1155 setApprovalForAll grants — across every chain. Each finding gets a risk score. One-click revoke generates the revocation transaction through the same defended signing flow.
You don't have to remember every approval you ever signed. We do.
✦ Defense 3
All three flavors defended.
Address poisoning isn't one attack — it's three. Each needs a different defense. A naive defense (warn on every new recipient) creates warning fatigue and stops working in week one. A real defense surfaces only the dangerous case while staying quiet for normal use.
History poisoning
Attacker sends 0-value transaction from a vanity address matching first-4 and last-4 hex characters of an address you've sent to before. You copy from history and send to the attacker.
Defense
Our detector flags any recipient that matches an address-book entry's first-4/last-4 but differs in the middle 34 characters. Confirmation modal forces full address review.
Clipboard malware
A browser extension or OS-level keylogger watches for Ethereum-format addresses on the clipboard and swaps them for attacker-controlled ones at paste time.
Defense
Our signing modal always shows the recipient's full 42-character address with the matching address-book nickname. If no nickname, the modal says "NEW recipient" with a unique visual identicon.
ENS and token spoofing
Homoglyph attacks on ENS names — visually identical Cyrillic characters. Token contracts labeled "USDC" but not Circle's verified contract.
Defense
We warn on any non-ASCII character in an ENS name. Token addresses checked against curated registry (CoinGecko + CoinMarketCap + chain-native verified contracts) and rendered as "USDC (verified)" or "USDC (UNVERIFIED)".
The address book is the precondition. The detectors do the work. Normal use stays quiet.
✦ Defense 4
Fingerprint at connect time.
BeSpoke wallets and other clones routinely fake the isMetaMask flag in window.ethereum. They look identical at the API level. They exfiltrate your seed phrase on first use.
When you connect a wallet, we fingerprint the provider against a known-good registry: MetaMask, Phantom, Rabby, Coinbase Wallet, Frame, Safe. A clone gets flagged with an explicit warning before the connection completes. You acknowledge the warning or you don't connect.
The fingerprint runs once at connect time. Cached after. Zero ongoing friction.
MetaMask
14/14 checks passed
Rabby
14/14 checks passed
Unknown extension
3/14 checks passed
Runs once at connect time · zero ongoing friction
✦ Defense 5
Constraints before convenience.
Auto-approve mode is a UX win and a security trap. Most implementations issue blanket session keys with approve(MAX_UINT256) permissions, and the key is good for whatever contract gets it. If the key is compromised, the wallet is drained.
When this feature ships: every session key scoped from day one. Maximum amount per transaction. Maximum cumulative amount per session. Maximum duration. Allowed target contracts — only the DEX aggregators we've explicitly approved. Never blanket MAX_UINT. Revocable instantly. Expires automatically.
STATUS: Not yet shipped. Shipping with auto-approve mode — Wave 3.
Convenience without constraints is the same as no defense at all.
✦ Threat model
What we're defending against.
Addressed
Drainer signatures — EIP-2612 Permit, Permit2, EIP-3009, setApprovalForAll, malicious EIP-712 messages.
Address-substitution attacks — history poisoning, clipboard malware, ENS and token spoofing.
Wallet supply-chain attacks — fake browser extensions impersonating known wallets.
Old-approval exploitation — drainer contracts using approvals granted to unrelated contracts.
Session-key abuse — compromised session keys used to drain wallets in auto-approve flows.
Not addressed
Seed-phrase compromise. We never see your seed. If your seed is compromised outside Perpblock, our defenses don't apply.
Custodial-platform failure. Different threat class. Different defenses.
Smart-contract exploits in protocols we route to. Protocol-level exploits are upstream of our control.
Out-of-band social engineering. Our anti-phishing policy covers our channels, not other platforms.
We defend what we can defend. We don't claim more.
✦ Timeline
What's live, what's next.
Live today
API-vault hardening — AES-256-GCM, salted per-key
Read-only API scope enforcement
On-chain anchoring of every trade
Wave 1 — next 60 days
Wallet authenticity check
Public anti-phishing policy and channel registry
Wave 2 — 60-180 days
Transaction simulation before signing
Approval scanner with one-click revoke
Address book and three-variant poisoning defense
Wave 3 — with auto-approve mode
Scoped session-key hardening
✦ Common questions
What technical users ask.
✦ Get started
Defend the signing surface.
Most platforms protect the venue. We protect the surface where the attacks actually happen.
Non-custodial. Defense on by default. Cancel anytime.