No address-taking metamorphic or opcode scan exists, so no verdict is bound to an account

[thedavidmeister]

Unit

src/interface/IExtrospectV1.sol + src/lib/LibExtrospectMetamorphic.sol + src/lib/LibExtrospectBytecode.sol scanners.

Intent oracle

IExtrospectV1 mixes both shapes: checkCBORTrimmedBytecodeHash(address, bytes32) and checkNoSolidityCBORMetadata(address) read account.code themselves; checkNotMetamorphic(bytes), scanMetamorphicRisk(bytes), scanEVMOpcodesPresentInBytecode(bytes) and scanEVMOpcodesReachableInBytecode(bytes) do not. LibExtrospectMetamorphic's title claims "Detection and guarding against metamorphic contract risk", and README.md still documents the removed scanEVMOpcodesReachableInAccount / scanEVMOpcodesPresentInAccount. The Protofire audit refers to scanEVMOpcodesReachableInAccount throughout.

Violated property

There is no API by which a caller obtains a metamorphic or opcode verdict bound to an address. Every caller must fetch .code themselves, so the step tying "these bytes are clean" to "this address is safe" sits outside the library, unaudited and untested. Extrospect.checkNotMetamorphic(bytes) proves nothing about any deployed account — the caller supplies the bytes — and passing a truncated or unrelated byte string yields a clean verdict with no error.

Combined with the empty-bytes issue, Extrospect.checkNotMetamorphic(hex"") is a passing external call that asserts nothing about anything.

Verified repro

Not executed as a defect — structural. Read src/interface/IExtrospectV1.sol against src/lib/LibExtrospectMetamorphic.sol: two address-taking checks, four bytes-taking checks, no address-taking metamorphic or opcode entry point. Confirmed at 28017b6.

Triage

Severity: low-medium (design / hazard surface, not a wrong answer). The asymmetry is easy to misuse and the docs actively describe the missing half as if it shipped, which is what turns it from a scope choice into a hazard. Fix is additive. See the separate stale-docs issue for the README/audit references to the removed account-taking functions.

---

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 current main (32f7325), then stopped

Reproduced, all three parts.

Structural claim — confirmed. IExtrospectV1 has four address-taking members (checkCBORTrimmedBytecodeHash, checkNoSolidityCBORMetadata, isBeaconImplementationBytecode, isBeaconOwner) and eight bytes-taking ones. None of the four take an address and answer a metamorphic or opcode question. (The issue says "two address-taking checks, four bytes-taking checks"; the real counts are 4 and 8 — the beacon predicates landed after the issue was written. The claim itself stands: there is no address-taking metamorphic or opcode entry point.)

Executable claim — confirmed. Against a fresh clone at 32f7325, nix develop -c forge test --match-path 'test/triage/*':

Ran 3 tests for test/triage/Issue83.t.sol:Issue83Test
[PASS] testEmptyBytesPass() (gas: 10232)
[PASS] testNoAddressTakingScanSelector() (gas: 371)
[PASS] testUnrelatedBytesCleanVerdict() (gas: 84178)

testUnrelatedBytesCleanVerdict deploys HasSelfdestruct, shows checkNotMetamorphic(risky.code) reverts, then shows checkNotMetamorphic(hex"00") and checkNotMetamorphic(hex"") both return cleanly — neither call names risky, and nothing in the library ties the clean answer to any account.

Baseline for the run: 311 passed / 3 failed, the 3 being test/src/lib/LibExtrospectBytecode.checkCBORTrimmedBytecodeHash.t.sol failing on absent ARBITRUM_RPC_URL (#85). Excluding that file: 311 passed / 0 failed.

History, for the record. The address-taking functions the README still describes were never implemented. scanEVMOpcodesPresentInAccount / scanEVMOpcodesReachableInAccount (IExtrospectBytecodeV2) and scanMetamorphicRisk(address) (IExtrospectMetamorphicV1) existed only as interface declarations with no concrete or library implementation behind them, and were deleted at 67eca86 as "unused downstream abstractions". So this is not a regression to revert — it is a new API to design.

---

Why I am not implementing it

Every version of "add an address-taking scan" makes the library issue an address-bound safety verdict it has never issued. Today the library answers "do these bytes contain reachable metamorphic opcodes"; the caller owns the leap to "this address is safe". Shipping that leap means choosing what the library concludes about the three classes of address whose code can change — which is the ruling, not the implementation. Handing that back.

Option A — leave the surface bytes-only

• Newly accepts: nothing. Newly rejects: nothing.
• Affects: nobody. The .code fetch stays the caller's, visibly.
• Cost: none. No interface change, no redeploy.
• The hazard the issue names survives: checkNotMetamorphic(hex"") stays a passing external call that asserts nothing. Under A that is the caller's problem by construction rather than a gap in the library.
• The doc half of A already has homes: README and CLAUDE.md document an interface surface that no longer exists, and two opcode bitmaps have no consumer #88 (README/CLAUDE.md describe the removed account-taking surface) and IExtrospectV1 carries no @param/@return NatSpec and documents no failure modes #89 (IExtrospectV1 has no @param/@return and documents no failure modes). Nothing for No address-taking metamorphic or opcode scan exists, so no verdict is bound to an account #83 to add.

Option B — thin wrappers: checkNotMetamorphic(address) = checkNotMetamorphic(account.code)

• Newly accepts (issues a clean address-bound verdict where none existed):
  • every account with no code — EOAs, self-destructed accounts, not-yet-deployed CREATE2 targets (checkNotMetamorphic reports an account with no code as NOT metamorphic #55);
  • every EIP-7702 delegated EOA, whose delegate is swappable by one EOA transaction (EIP-7702 delegated accounts are reported as NOT metamorphic #54, An EIP-7702 delegated EOA passes both beacon predicates, and the verdict is revocable by one EOA transaction #79);
  • every proxy whose own runtime is clean but whose implementation is arbitrary and swappable (isERC1167Proxy returns (false, address(0)) for working delegating proxies, including EIP-1167 vanity clones #68, The beacon predicates never yield the implementation address, so the repo's own metamorphic and EOF checks cannot be composed onto it #82).
• Newly rejects: nothing — nothing address-bound was answered before.
• Affects: everyone who reads "address X is not metamorphic" as "X's code cannot change". Those three classes are exactly the addresses whose code can change, so the thin wrapper issues its most reassuring verdict on its most dangerous inputs. testCheckNotMetamorphicEmpty and testScanMetamorphicRiskEmpty would then pin those answers as intended behaviour.

Option C — B, plus revert when account.code.length == 0

• Newly rejects vs B: EOAs, self-destructed accounts, counterfactual CREATE2 addresses.
• Still newly accepts: 7702 delegated accounts and proxies.
• Affects: this is checkNotMetamorphic reports an account with no code as NOT metamorphic #55's ruling arriving through No address-taking metamorphic or opcode scan exists, so no verdict is bound to an account #83's door — C cannot be chosen without deciding checkNotMetamorphic reports an account with no code as NOT metamorphic #55. And unless checkNotMetamorphic reports an account with no code as NOT metamorphic #55 is also ruled on the bytes side, checkNotMetamorphic(hex"") keeps passing while checkNotMetamorphic(address-with-no-code) reverts: the library would answer the empty case in two directions at once, which is the same split checkNotMetamorphic reports an account with no code as NOT metamorphic #55 already flags between checkNotMetamorphic and checkCBORTrimmedBytecodeHash.

Option D — resolve delegation and proxying, then scan the implementation

• The only version that actually delivers "this address is safe to trust", and the largest: it decides what counts as a genuine proxy (isERC1167Proxy returns (false, address(0)) for working delegating proxies, including EIP-1167 vanity clones #68, isERC1167Proxy accepts a clone whose implementation has no code, and (true, address(0)) is indistinguishable from (false, address(0)) #69), what counts as a beacon (The ripemd160 precompile at 0x03 is accepted as a valid beacon and as an owner match #74–An EIP-7702 delegated EOA passes both beacon predicates, and the verdict is revocable by one EOA transaction #79), and whether a revocable 7702 delegation is metamorphic by construction (EIP-7702 delegated accounts are reported as NOT metamorphic #54, An EIP-7702 delegated EOA passes both beacon predicates, and the verdict is revocable by one EOA transaction #79). The beacon predicates never yield the implementation address, so the repo's own metamorphic and EOF checks cannot be composed onto it #82 exists precisely because the beacon predicates never yield the implementation address, so this composition is not possible today at all.
• Newly accepts / rejects: the direction is the ruling — either proxies and delegated accounts become metamorphic-by-construction (rejecting a large population of live, legitimately-upgradeable contracts), or they are accepted conditionally on the resolved implementation being clean (accepting an answer that one upgradeTo invalidates).

Cost attached to B, C and D alike

IExtrospectV1 is published and the concrete Extrospect is pinned three ways. Adding any function changes type(Extrospect).creationCode, so EXTROSPECT_CREATION_BYTECODE_V1, EXTROSPECT_RUNTIME_CODEHASH_V1 and EXTROSPECT_ZOLTU_ADDRESS_V1 all move and the contract redeploys at a new deterministic address — testExtrospectCreationBytecode, testExtrospectZoltuAddress and testExtrospectRuntimeCodehash fail loud, by design. rain.deploy consumers verifying the old codehash break. Whether that is a V1 edit or an IExtrospectV2 is part of whichever of B/C/D is chosen, and it interacts with #44 (per-release deploy snapshots) and #46 (splitting the deploy half out).

---

No part of #83 is verdict-neutral, so nothing was implemented and no PR was opened. The repro test above was written under my scratch clone only and is not proposed for the tree.

[thedavidmeister]

RULING (thedavidmeister, 2026-08-19): the remaining opcode-scan half takes the same boundary rule as the metamorphic pair — address-taking scanEVMOpcodesPresentInBytecode(address) / scanEVMOpcodesReachableInBytecode(address) entry points REVERT on a codeless account (CodelessAccount(address), per the E+D class from #55) before delegating to the bytes functions. Library-only: IExtrospectV1 stays untouched, same as PR #136. The interface question is ruled separately — a new interface for a new deploy is tracked in its own issue.