checkNoSolidityCBORMetadata reports "no metadata" for an address with no code

[thedavidmeister]

Unit

src/lib/LibExtrospectBytecode.sol — checkNoSolidityCBORMetadata.

Intent oracle

NatSpec's stated purpose: "…as a defense against the metamorphic metadata attack" — i.e. against an address whose code can change.

Violated property

The gate answers "safe" about an address that has no code today: an EOA, a self-destructed account, or an undeployed CREATE2 slot an attacker controls. That is precisely the case the metamorphic threat model is about, and it is the one input for which "no metadata present" carries no information at all.

Contrast the sibling: checkCBORTrimmedBytecodeHash reverts MetadataNotTrimmed on an empty account. The two account-taking checks answer the empty case in opposite directions and neither NatSpec mentions it.

Verified repro

repro-tests/TriageBytecode.t.sol :: testT7_CodelessPassesNoMetadata — PASSES at 28017b6:

assertEq(address(0x1234).code.length, 0);
LibExtrospectBytecode.checkNoSolidityCBORMetadata(address(0x1234));   // returns cleanly

Triage

Severity: medium-high by value-at-risk; low by depth. This is an intent question, not a coding error: test/src/lib/LibExtrospectBytecode.checkNoSolidityCBORMetadata.t.sol::testCheckNoMetadataEmptyAccount asserts the pass as intended, so the suite entrenches it. The ruling needed is whether an empty account should revert, or whether the caller's code.length != 0 obligation should be stated. Same shape as the separate checkNotMetamorphic(hex"") issue.

---

Provenance

Adversarial mutation-test campaign on rainlanguage/rain.extrospection @ 28017b6, triage pass.
Repros in this issue were re-executed by the triage agent against a fresh clone at 28017b6
(nix develop -c forge test, baseline 304 passed / 0 failed) unless the issue says otherwise.

Triage repro sources: /home/gildlab/artifacts/2026-08-18-extrospection-amt/triage/repro-tests/
(TriageBytecode.t.sol, TriageProxy.t.sol, TriageEtch.t.sol) — drop into test/triage/ of a
clone at 28017b6 and run nix develop -c forge test --match-path 'test/triage/*'.

[thedavidmeister]

Verified against main @ 32f7325

The claim reproduces exactly. Fresh clone at main HEAD, nix develop -c forge test:

• LibExtrospectBytecode.checkNoSolidityCBORMetadata(address(0x1234)) — code.length == 0 asserted first — returns cleanly.
• Extrospect.checkNoSolidityCBORMetadata(address(0x1234)) — same at the external boundary.
• An address etched to code and then etched back to hex"" (the self-destructed / never-occupied CREATE2 shape) also passes.
• The stated contrast holds: checkCBORTrimmedBytecodeHash(address(0x1234), 0) reverts MetadataNotTrimmed on the same codeless address.

Baseline before any change: 304 passed / 0 failed, excluding ExtrospectConstantsTest (pins deployed bytecode, so it fails under every source mutation and reports KILLED for every mutant) and test/src/lib/LibExtrospectBytecode.checkCBORTrimmedBytecodeHash.t.sol (3 of its 7 tests need ARBITRUM_RPC_URL, absent here — #85).

One correction to the framing

The issue reads the two account-taking checks as having "answered the empty case in opposite directions". They diverge, but neither of them decided anything about a codeless account. The split is structural and it is the same one #55 names:

• checkCBORTrimmedBytecodeHash is a presence check. It requires metadata to be found and trimmed. Empty bytecode is 0 bytes, tryTrimSolidityCBORMetadata needs >= 53, so it reverts MetadataNotTrimmed. Nothing about "no code" was asserted — the function simply could not find what it needs.
• checkNoSolidityCBORMetadata is an absence check. It passes vacuously, on exactly the same didTrim == false that made the sibling revert. One boolean, two opposite verdicts, because the two functions want opposite answers from it.

So the ruling wanted is not "what should checkNoSolidityCBORMetadata do about a codeless account". It is what should an absence check conclude about an account with no code — the identical question open on #55 for checkNotMetamorphic. The difference is that checkNoSolidityCBORMetadata already takes an address, so it can enforce a code.length guard today with no API change, where checkNotMetamorphic takes bytes and cannot tell a codeless account from a zero-length value.

Open, changes no verdict: #105

NatSpec now states the codeless-account behaviour at both account-taking checks, and the three tests that pin the codeless verdict (library, concrete, and the sibling's revert) now assert code.length == 0 as an explicit precondition rather than trusting address(0xdead) to stay empty. Every input that passed before passes now with identical returndata. src/ changed in comments only, so ExtrospectConstantsTest still passes and EXTROSPECT_CREATION_BYTECODE_V1 / EXTROSPECT_ZOLTU_ADDRESS_V1 / EXTROSPECT_RUNTIME_CODEHASH_V1 are untouched.

The verdict decision — yours

Every option below is stated as: what it newly accepts, what it newly rejects, who that affects.

Static enumeration of what is at stake in this repo, by grep over every call site of either function: exactly three call sites pass a codeless address today, and all three are tests — LibExtrospectBytecode.checkNoSolidityCBORMetadata.t.sol::testCheckNoMetadataEmptyAccount, Extrospect.checkNoSolidityCBORMetadata.t.sol::testCheckNoSolidityCBORMetadataEquivalencePass, and LibExtrospectBytecode.checkCBORTrimmedBytecodeHash.t.sol::testCheckCBORTrimmedBytecodeHashEmptyAccount. No src/ call site passes a codeless address. The blast radius of any option below is therefore entirely downstream and entirely unknown to this repo.

A. Status quo, now documented (what the PR above leaves in place)

• Newly rejects: nothing. Newly accepts: nothing.
• Who: no call site changes. The code.length != 0 obligation stays with the caller and is now stated in NatSpec at the point of use.
• Cost: a caller who reads checkNoSolidityCBORMetadata(account) as "this account is defended against the metamorphic metadata attack" is still wrong for an EOA, an unoccupied CREATE2 target, and a self-destructed account — and a NatSpec sentence is the only thing standing between them and that reading. That is precisely the population the threat model is about, since an unoccupied CREATE2 target is the metamorphic primitive.

B. checkNoSolidityCBORMetadata reverts on a codeless account

Sub-choice: reuse UnexpectedMetadata (dishonest — no metadata was found) or add a new error, e.g. AccountHasNoCode(address). The new error is the honest one and costs a new selector on the IExtrospectV1 revert surface.

• Newly rejects: every call whose target has no code — EOA, unoccupied CREATE2 target, self-destructed account, and any legitimate pre-deployment check (a factory validating a counterfactual address before the deploy lands, a registry pre-authorising an address).
• Newly accepts: nothing.
• Who: downstream onchain callers that today use this as a cheap bytecode predicate on an address that may not be deployed yet start reverting — none in this repo, unknown outside it. Repo-internal: the two tests named above that assert the pass must be rewritten. testCheckNoMetadataPassesFuzz already does vm.assume(code.length > 0) and is unaffected.
• Makes the pair symmetric in the strict direction: both account-taking checks then reject a codeless account.
• Cost: src/ behaviour changes ⇒ Extrospect bytecode changes ⇒ all three pinned deploy constants move, ExtrospectConstantsTest must be re-pinned, the Extrospect already deployed at EXTROSPECT_ZOLTU_ADDRESS_V1 is superseded, and any consumer pinning that address or codehash has to move with it. IExtrospectV1 gains a behaviour change with no signature change — a silent semantic break for anyone bound to the existing deployment.

C. Make the pair symmetric the other way — checkCBORTrimmedBytecodeHash stops rejecting a codeless account

Stated for completeness because the asymmetry is the reported defect and symmetry is reachable from either end.

• Newly accepts: a codeless account when the caller passed expected == keccak256(""), i.e. a caller explicitly asserting "this address has no code". Every other expected still reverts, but with BytecodeHashMismatch instead of MetadataNotTrimmed.
• Newly rejects: nothing.
• Who: testCheckCBORTrimmedBytecodeHashEmptyAccount changes. Same redeploy cost as B.
• This weakens the one check that is currently strict, and swaps a precise error for a vague one. Wrong direction if the threat model is "an address whose code can change".

D. Add an explicit code-presence check and leave both verdicts alone

e.g. checkHasCode(address), composed by callers that need "deployed and no metadata".

• Newly rejects: nothing from the existing functions. Newly accepts: nothing.
• Who: callers who want the guard opt in and say so at the call site; callers using the function as a pure bytecode predicate keep a total function.
• Cost: a new function on IExtrospectV1 — either a V2 interface or a breaking change to V1 — plus the same redeploy cost as B. And it is opt-in, so a caller who never realised they needed the guard still does not get it. That is the whole failure mode this issue reports.

E. Rule the class, not the function

Whichever of A/B/D is chosen, apply the same answer to every absence check rather than to this one. Verified on main, the absence checks that pass a codeless account or empty bytecode today are:

entry point	takes	codeless / empty answer today
checkNoSolidityCBORMetadata	address	passes
checkNotMetamorphic	bytes	passes (#55)
checkNotEOFBytecode	bytes	passes
isEOFBytecode	bytes	false
isERC1167Proxy	bytes	(false, address(0)) (#69)
isBeaconImplementationBytecode	address (the beacon; the implementation it names is the codeless one)	keccak256(impl.code) is keccak256(""), so it returns true against that expected hash (#78)

• Newly rejects / accepts: whatever B or D specifies, at every row rather than one.
• Who: the address-taking rows (checkNoSolidityCBORMetadata, isBeaconImplementationBytecode) can enforce a code.length guard with no API change. The bytes-taking rows structurally cannot distinguish a codeless account from a zero-length value and need the address-boundary work checkNotMetamorphic reports an account with no code as NOT metamorphic #55 option D describes.
• Cost: one redeploy covering the whole class instead of one redeploy per issue ruled separately. Ruling checkNoSolidityCBORMetadata reports "no metadata" for an address with no code #61 alone leaves checkNotMetamorphic reports an account with no code as NOT metamorphic #55, isERC1167Proxy accepts a clone whose implementation has no code, and (true, address(0)) is indistinguishable from (false, address(0)) #69 and isBeaconImplementationBytecode matches keccak256("") against any codeless implementation, including a counterfactual CREATE2 address #78 answering the same question, and leaves checkNoSolidityCBORMetadata and checkNotMetamorphic — the two halves of "is this contract safe to trust" — disagreeing about whether the account needs to exist.

A documents. B fixes it where reported and pays a full redeploy for one function. C is the wrong direction. D is opt-in and so misses the caller who did not know to opt in. E is the only one that leaves no absence check answering the question the other way, and amortises the single unavoidable redeploy across every issue in the family. That is the trade-off; the ruling is yours.

[thedavidmeister]

Closing per ruling (thedavidmeister, 2026-08-19): resolved by ruling E+D on #55 as implemented in PR #136 (merged to main today). checkNoSolidityCBORMetadata(address) now reverts CodelessAccount(address) on a codeless account — this issue's exact repro inverted — and the entrenching testCheckNoMetadataEmptyAccount was replaced by testCheckNoMetadataRevertsOnCodelessAccount, which pins the revert and its address payload (guard covered by the mutation evidence in #136's QA block). The divergence with checkCBORTrimmedBytecodeHash is resolved directionally: both account-taking CBOR checks now refuse a codeless account. The doc-only alternative was PR #105, closed superseded by the ruling.