fix expectedhash in trimsoliditycbormetadata

[thedavidmeister]

Motivation

Solution

Checks

By submitting this for review, I'm confirming I've done the following:

• made this PR as small as possible
• unit-tested any new functionality
• linked any relevant issues or PRs
• included screenshots (if this involves a front-end change)

Summary by CodeRabbit

• Bug Fixes
  • Fixed bytecode metadata handling for improved processing accuracy.
  • Extended operation support in the interpreter layer.

[coderabbitai]

Walkthrough

The pull request updates two contract files: adding EVM_LOG3 to the NON_STATIC_OPS constant in IExtrospectInterpreterV1.sol, and updating a Solidity CBOR metadata hash value in LibExtrospectBytecode.sol. Both are minimal changes to constants and configuration values.

Changes

Cohort / File(s)	Summary
Non-static Operations Configuration src/interface/IExtrospectInterpreterV1.sol	Added (1 << uint256(EVM_OP_LOG3)) shift operation to the NON_STATIC_OPS constant, extending the set of non-static EVM operations to include LOG3 alongside existing operations.
Metadata Hash Update src/lib/LibExtrospectBytecode.sol	Updated the expected Solidity CBOR metadata hash in the trimSolidityCBORMetadata function from 0xe55864b80a56accebaca64500e23598f6acfb743a5475323f0b7f2d0d268c62 to 0x0e55864b80a56accebaca64500e23598f6acfb743a5475323f0b7f2d0d268c62.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly describes the main change: fixing an expectedHash value in the trimSolidityCBORMetadata function, which aligns with the actual code modification shown in the raw summary.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 2026-02-03-I01

Important

Action Needed: IP Allowlist Update

If your organization protects your Git platform with IP whitelisting, please add the new CodeRabbit IP address to your allowlist:

• ✨ 136.113.208.247/32 (new)
• 34.170.211.100/32
• 35.222.179.152/32

Reviews will stop working after February 8, 2026 if the new IP is not added to your allowlist.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/lib/LibExtrospectBytecode.sol`:
- Line 58: The hardcoded expectedHash value in LibExtrospectBytecode.sol may be
off by a nibble; add a verification path and proof: update the code around
trimSolidityCBORMetadata and checkCBORTrimmedBytecodeHash to include a
deterministic derivation comment or a helper function that computes the expected
CBOR hash from the CBOR suffix (and replace the bytes32(uint256(...)) literal
with an explicit 0x-prefixed hex literal to preserve the leading zero), and add
a small regression test that runs trimSolidityCBORMetadata on known-good
bytecode and asserts the returned hash matches the derived value to prevent
silent failures.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Add a verification path for the updated expected CBOR hash.

This one‑nibble change can silently make trimSolidityCBORMetadata fail and cause checkCBORTrimmedBytecodeHash to revert even for valid bytecode. Please add a small regression test or a documented derivation for the expected hash so the change is provably correct. Also consider using a hex literal to make the leading zero explicit.

💡 Optional clarity tweak for the literal

-            bytes32 expectedHash = bytes32(uint256(0x0e55864b80a56accebaca64500e23598f6acfb743a5475323f0b7f2d0d268c62));
+            bytes32 expectedHash = hex"0e55864b80a56accebaca64500e23598f6acfb743a5475323f0b7f2d0d268c62";

🤖 Prompt for AI Agents

In `@src/lib/LibExtrospectBytecode.sol` at line 58, The hardcoded expectedHash
value in LibExtrospectBytecode.sol may be off by a nibble; add a verification
path and proof: update the code around trimSolidityCBORMetadata and
checkCBORTrimmedBytecodeHash to include a deterministic derivation comment or a
helper function that computes the expected CBOR hash from the CBOR suffix (and
replace the bytes32(uint256(...)) literal with an explicit 0x-prefixed hex
literal to preserve the leading zero), and add a small regression test that runs
trimSolidityCBORMetadata on known-good bytecode and asserts the returned hash
matches the derived value to prevent silent failures.