Ithaca account

[Dargon789]

Summary by Sourcery

Add Merkle tree–based signature support to IthacaAccount and update tests and benchmarks for the extended wrapped-signature format.

New Features:

• Support verifying Merkle tree–based signatures that authorize digests via a signed Merkle root in IthacaAccount.
• Add a benchmark for ERC20 transfers via the Porto orchestrator using passkey-based signatures.

Enhancements:

• Extend the wrapped-signature format with an additional flag to distinguish Merkle-based signatures while preserving existing behaviors.
• Simplify EIP-712 domain usage in tests by only relying on the verifying contract field.
• Bump the IthacaAccount EIP-712 version string from 0.5.10 to 0.5.11.

Tests:

• Add fuzz tests covering valid, invalid, and tampered Merkle signature verification paths.
• Update helper signing utilities and orchestrator/simulation tests to use the new wrapped-signature layout.

Chores:

• Add IDE project configuration files under the .idea directory.

[sourcery-ai]

Reviewer's Guide

Adds Merkle tree–based signature support to IthacaAccount (including a merkle flag in wrapped signatures), updates tests and benchmarks to the new signature encoding, and introduces fuzz tests for Merkle signatures, along with minor EIP-712 domain and version updates plus some IDE config files.

Sequence diagram for merkle-based wrapped signature verification

sequenceDiagram
    actor ExternalCaller
    participant IthacaAccount
    participant MerkleProofLib

    ExternalCaller->>IthacaAccount: unwrapAndValidateSignature(digest, wrappedSig)
    alt signature_length == 65
        IthacaAccount-->>ExternalCaller: isValid = (ECDSA.recoverCalldata == this), keyHash = 0
    else wrapped_signature
        IthacaAccount->>IthacaAccount: parse keyHash, prehashFlag, merkleFlag from wrappedSig
        alt prehashFlag != 0
            IthacaAccount->>IthacaAccount: digest = EfficientHashLib.sha2(digest)
        end
        alt merkleFlag != 0
            IthacaAccount->>IthacaAccount: _verifyMerkleSig(digest, merkleSigPayload)
            IthacaAccount->>MerkleProofLib: verifyCalldata(proof, root, digest)
            alt MerkleProofLib returns true
                IthacaAccount->>IthacaAccount: unwrapAndValidateSignature(root, rootSig)
                IthacaAccount-->>ExternalCaller: isValid, keyHash (from rootSig validation)
            else MerkleProofLib returns false
                IthacaAccount-->>ExternalCaller: isValid = false, keyHash = 0
            end
        else merkleFlag == 0
            IthacaAccount->>IthacaAccount: getKey(keyHash) and validate
            IthacaAccount-->>ExternalCaller: isValid, keyHash
        end
    end

Loading

Class diagram for updated IthacaAccount merkle-aware signature validation

classDiagram
    class IthacaAccount {
        +unwrapAndValidateSignature(bytes32 digest, bytes signature) bool isValid, bytes32 keyHash
        -_verifyMerkleSig(bytes32 digest, bytes signature) bool isValid, bytes32 keyHash
        +eip712DomainDetails() string name, string version
    }

    class MerkleProofLib {
        +verifyCalldata(bytes32[] proof, bytes32 root, bytes32 leaf) bool
    }

    class LibBytes {
        +loadCalldata(bytes data, uint256 index) bytes32
        +truncatedCalldata(bytes data, uint256 newLength) bytes
    }

    class EfficientHashLib {
        +sha2(bytes32 digest) bytes32
    }

    class ECDSA {
        +recoverCalldata(bytes32 digest, bytes signature) address
    }

    IthacaAccount ..> MerkleProofLib : uses
    IthacaAccount ..> LibBytes : uses
    IthacaAccount ..> EfficientHashLib : uses
    IthacaAccount ..> ECDSA : uses

Loading

File-Level Changes

Change	Details	Files
Add Merkle-based wrapped signature verification path in IthacaAccount and extend wrapped signature encoding	Introduce _verifyMerkleSig that decodes proof/root/rootSig from calldata using inline assembly and verifies Merkle proofs via MerkleProofLib.verifyCalldata Extend unwrapAndValidateSignature to handle an extra merkle flag byte, branch into Merkle verification path, and adjust offset math for keyHash/prehash extraction Update wrapped signature format documentation to include prehash and merkle flags and bump EIP-712 version string from 0.5.10 to 0.5.11	src/IthacaAccount.sol
Update test helpers and tests to the new wrapped signature format and add fuzz coverage for Merkle signatures	Update _p256Sig, _secp256k1Sig, _multiSig, and various synthetic signatures in tests to append an extra merkle flag byte (currently 0) after the prehash flag Add testMerkleSignature fuzz test that builds random Merkle trees, checks successful verification, and asserts failures for invalid digest, tampered proof, and wrong root using the new merkle flag path Simplify eip712Domain destructuring in Account tests to ignore unused name/version fields and keep only verifyingContract	test/Base.t.sol test/Account.t.sol test/Orchestrator.t.sol test/SimulateExecute.t.sol
Add benchmark case for passkey-based ERC20 transfer via Orchestrator	Create testERC20TransferViaPortoOrchestratorWithPasskey which configures a passkey on a DelegatedEOA, sets permissions and spend limits, signs an Intent with the passkey, and benchmarks Orchestrator execution Aligns benchmark setup with existing ERC20 transfer benchmarks including gas metering pauses and balance assertions	test/Benchmark.t.sol
Add IDE project configuration files	Check in IntelliJ/IDEA project metadata including module file, VCS, markdown, code style, and cache configuration Configure IDE-specific .gitignore within .idea	.idea/.gitignore .idea/account.iml .idea/caches/deviceStreaming.xml .idea/codeStyles/Project.xml .idea/codeStyles/codeStyleConfig.xml .idea/copilot.data.migration.ask2agent.xml .idea/markdown.xml .idea/modules.xml .idea/vcs.xml

Possibly linked issues

• Chore bump contract versions due to bytecode changes  #60: The PR implements the issue’s Merkle signature support, wrapped-signature merkle flag, test updates, and version bump.
• Fix tests account #30: The PR adds _verifyMerkleSig, Merkle flag handling, test updates, and benchmarks exactly as outlined in the issue.
• Legion rouge #41: The PR adds _verifyMerkleSig, MerkleProofLib usage, new wrapped-signature encoding, tests, and bumps IthacaAccount to 0.5.11.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[sourcery-ai]

Hey - I've found 3 issues, and left some high level feedback:

• The recursive use of unwrapAndValidateSignature from _verifyMerkleSig can lead to unbounded recursion if an attacker sets the merkle flag in rootSig; consider explicitly rejecting or ignoring merkle-enabled wrapped signatures when verifying the root to avoid potential DoS or deep nesting.
• The manual calldata decoding in _verifyMerkleSig relies on the exact abi.encode(bytes32[] proof, bytes32 root, bytes rootSig) layout; adding a brief comment documenting the expected calldata layout (offsets and lengths) or factoring the decoding into a small helper would make this less brittle and easier to maintain.
• The .idea directory and related IDE configuration files appear to have been committed; these should generally be removed from version control and added to .gitignore to avoid noise and local-environment-specific artifacts in the repo.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The recursive use of `unwrapAndValidateSignature` from `_verifyMerkleSig` can lead to unbounded recursion if an attacker sets the merkle flag in `rootSig`; consider explicitly rejecting or ignoring merkle-enabled wrapped signatures when verifying the root to avoid potential DoS or deep nesting.
- The manual calldata decoding in `_verifyMerkleSig` relies on the exact `abi.encode(bytes32[] proof, bytes32 root, bytes rootSig)` layout; adding a brief comment documenting the expected calldata layout (offsets and lengths) or factoring the decoding into a small helper would make this less brittle and easier to maintain.
- The `.idea` directory and related IDE configuration files appear to have been committed; these should generally be removed from version control and added to `.gitignore` to avoid noise and local-environment-specific artifacts in the repo.

## Individual Comments

### Comment 1
<location path="src/IthacaAccount.sol" line_range="525" />
<code_context>
     /// @dev Returns if the signature is valid, along with its `keyHash`.
     /// The `signature` is a wrapped signature, given by
-    /// `abi.encodePacked(bytes(innerSignature), bytes32(keyHash), bool(prehash))`.
+    /// `abi.encode(bytes(innerSignature), bytes32(keyHash), bool(prehash), bool(merkle))`.
     function unwrapAndValidateSignature(bytes32 digest, bytes calldata signature)
         public
</code_context>
<issue_to_address>
**issue (bug_risk):** Signature encoding comment likely mismatches the actual layout used by the parsing logic.

The parser still assumes a fixed 0x22-byte trailer (`32 bytes keyHash + 1 prehash + 1 merkle`) and slices with `signature.length - 0x22` using `LibBytes.loadCalldata`. That only matches a tightly packed layout (e.g. `abi.encodePacked(inner, keyHash, prehash, merkle)`), not `abi.encode` with 32-byte–padded bools that won’t sit in the last 2 bytes. Either update the extraction indices to match `abi.encode`, or keep the packed layout and update the docstring so callers don’t encode signatures incorrectly.
</issue_to_address>

### Comment 2
<location path="src/IthacaAccount.sol" line_range="542-549" />
<code_context>
+        bool merkle;
         unchecked {
-            uint256 n = signature.length - 0x21;
+            uint256 n = signature.length - 0x22;
             keyHash = LibBytes.loadCalldata(signature, n);
             signature = LibBytes.truncatedCalldata(signature, n);
             // Do the prehash if last byte is non-zero.
             if (uint256(LibBytes.loadCalldata(signature, n + 1)) & 0xff != 0) {
                 digest = EfficientHashLib.sha2(digest); // `sha256(abi.encode(digest))`.
             }
+            merkle = uint256(LibBytes.loadCalldata(signature, n + 2)) & 0xff != 0;
+        }
+
</code_context>
<issue_to_address>
**suggestion (bug_risk):** No explicit length checks before subtracting 0x22 can underflow for malformed or short signatures.

This implicitly assumes `signature.length >= 0x22`. If `signature.length < 0x22` (malformed or adversarial input), `n` underflows in the `unchecked` block, becomes a huge value, and `LibBytes.loadCalldata`/`truncatedCalldata` then use nonsensical offsets. Consider adding a minimal length check before entering the `unchecked` block (revert or return `false`) to harden this against bad calldata without affecting the normal path.

Suggested implementation:

```
        // Minimal length check to avoid underflow when computing `n = signature.length - 0x22`.
        // If `signature.length < 0x22`, `n` would underflow inside the `unchecked` block.
        if (signature.length < 0x22) {
            revert("IthacaAccount: invalid merkle signature length");
        }

        bool merkle;
        unchecked {

```

If your codebase prefers custom errors or reusable validation functions, you may want to:
1. Replace the string revert with a custom error, e.g. `error InvalidSignatureLength();` declared at the top of the file, and use `revert InvalidSignatureLength();` here.
2. Ensure any callers/tests that rely on this function are updated to expect a revert on malformed/short signatures instead of undefined behavior.
</issue_to_address>

### Comment 3
<location path="src/IthacaAccount.sol" line_range="493-502" />
<code_context>
+    function _verifyMerkleSig(bytes32 digest, bytes calldata signature)
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Assembly decoding of the Merkle signature does not guard against inconsistent or truncated ABI-encoding.

This assembly decoding assumes a correctly formed `abi.encode(bytes32[] proof, bytes32 root, bytes rootSig)` payload, but never checks that `proofOffset` and `rootSigOffset` stay within `signature.offset + signature.length`. With a short or malformed `signature`, the derived `proof.length` / `rootSig.length` can become garbage and cause `MerkleProofLib.verifyCalldata` / `unwrapAndValidateSignature` to read arbitrary calldata. Please add a cheap length precondition and bounds checks on the computed offsets before using the decoded lengths.
</issue_to_address>

Fix all in Cursor

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[gemini-code-assist]

Code Review

This pull request introduces Merkle tree-based signature verification to the IthacaAccount contract, allowing for more flexible authorization structures. The implementation includes a new internal verification function using assembly and updates the signature format to include a Merkle flag, with corresponding updates to the test suite and benchmarks. Feedback focuses on critical safety improvements in the signature parsing logic, specifically addressing potential underflows and out-of-bounds reads caused by missing length checks and the improper sequencing of calldata truncation. Additionally, several IDE-specific cache files were committed and should be removed to maintain repository hygiene.