Legion

[Dargon789]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
legion	Ready	Preview, Comment	May 6, 2026 3:13pm

[sourcery-ai]

Sorry @Dargon789, your pull request is larger than the review limit of 150000 diff characters

[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.

[gemini-code-assist]

Code Review

This pull request introduces multi-chain deployment support, merkle signature verification in IthacaAccount.sol, and updates to the escrow refund logic. The review identifies a critical bug in signature flag parsing, a security risk regarding a committed private key in .env.example, concerns about the intent behind the escrow logic changes, and recommendations for ensuring build reproducibility in foundry.toml.

I am having trouble creating individual review comments. Click here to see my feedback.

src/IthacaAccount.sol (551-554)

The logic for reading the prehash and merkle flags from the signature appears to be incorrect. The offsets n + 1 and n + 2 point to bytes within the keyHash, not the flags that follow it. The prehash flag is at offset n + 32 and the merkle flag is at n + 33 relative to the start of the signature data.

This will cause signature validation to behave incorrectly.

You can use LibBytes.loadBytes1 to correctly read the single-byte flags.

            // Do the prehash if the flag is non-zero.
            if (uint8(LibBytes.loadBytes1(signature, n + 32)) != 0) {
                digest = EfficientHashLib.sha2(digest); // `sha256(abi.encode(digest))`.
            }
            merkle = uint8(LibBytes.loadBytes1(signature, n + 33)) != 0;

.env.example (8)

Committing a default private key, even a well-known test key, is a security risk. A developer might accidentally use this key in a production-like environment or commit a .env file based on this example without changing it. It's safer to leave the value blank or use a placeholder like YOUR_PRIVATE_KEY to force the user to provide their own key.

PRIVATE_KEY=

src/Escrow.sol (135-140)

This change introduces a significant alteration to the escrow logic by allowing the recipient to trigger a full refund for both parties at any time (msg.sender == _escrow.recipient). Previously, refunds were only possible after the refundTimestamp. This change could undermine the purpose of the escrow, which is typically to lock funds until a condition is met or a timeout occurs. If a depositor expects funds to be locked, this early refund capability by the recipient could lead to unexpected behavior and potential loss of trust in the escrow's guarantee. Please verify if this behavior is intended. If so, the contract's documentation should be updated to clearly state this early refund mechanism.

foundry.toml (9-18)

This profile has a couple of changes that might affect build reproducibility and deterministic deployments:

• solc_version is not pinned: For reproducible builds, it's a best practice to specify the Solidity compiler version. The solc_version key was removed. Without it, different environments might use different compilers. Please consider adding solc_version = "0.8.23" (or your target version).
• Bytecode metadata is now included: The removal of bytecode_hash = "none" and cbor_metadata = false means that contract bytecode will now include metadata. This makes CREATE2 deployments non-deterministic with respect to metadata changes (e.g., file paths). If deterministic bytecode is desired, please consider adding these settings back.