feat: deploy Arbitrum Sepolia and AVAX Testnet contracts

[julianrubino]

• Changed the hardcoded salt string to avoid address collision
• Deployed EVMGateway contract
• Deployed ERC20Custody contract
• Pushed runs json files
• Added chain names and param symbols

Summary by CodeRabbit

• New Features

  • Added support for Arbitrum Sepolia and Avalanche Testnet networks
  • Deployed new smart contracts: ERC20Custody, ERC1967Proxy, GatewayEVM

• Deployment

  • Deployed ERC20Custody contract on multiple blockchain networks
  • Deployed GatewayEVM contract on multiple blockchain networks
  • Updated deterministic deployment salt values for contracts

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request involves the deployment of two key smart contracts, ERC20Custody and GatewayEVM, across multiple blockchain networks including Arbitrum Sepolia and Avalanche Testnet. The deployments use CREATE2 transaction type for deterministic contract addresses. The changes include modifications to salt values for contract deployment, updates to supported blockchain networks and cryptocurrency symbols in type definitions, and the generation of deployment transaction logs and receipts.

Changes

File	Change Summary
lib/types.ts	Added new blockchain network names and cryptocurrency symbols: - "arbitrum_sepolia" - "avalanche_testnet" - "ETH.ARBSEPOLIA" - "AVAX.AVAX"
scripts/deploy/deterministic/DeployERC20Custody.s.sol	Updated salt values from *-2 to plain versions for deterministic deployment
scripts/deploy/deterministic/DeployGatewayEVM.s.sol	Updated salt values from *-2 to plain versions for deterministic deployment
broadcast/*	Generated deployment transaction logs for multiple networks

Suggested reviewers

• fadeev
• CharlieMc0
• andresaiello
• brewmaster012
• lumtis
• skosito

Possibly related PRs

• feat: inbound evm prototype #178: Changes to GatewayEVM and ERC20Custody contracts
• feat: prototype inbound zevm #183: Introduction of GatewayZEVM contract
• feat: Deploy system contracts to Amoy #190: Deployment of system contracts
• chore: deployment info for v21 implementation contract #434: Deployment information for ERC20Custody
• chore: make v2 the root of the directory #449: Restructuring project directory

---

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cc6041c and f4ef6b5.

📒 Files selected for processing (13)

• broadcast/DeployERC20Custody.s.sol/421614/run-1738383935.json (1 hunks)
• broadcast/DeployERC20Custody.s.sol/421614/run-latest.json (1 hunks)
• broadcast/DeployERC20Custody.s.sol/43113/run-1738383750.json (1 hunks)
• broadcast/DeployERC20Custody.s.sol/43113/run-latest.json (1 hunks)
• broadcast/DeployGatewayEVM.s.sol/421614/run-1738344855.json (1 hunks)
• broadcast/DeployGatewayEVM.s.sol/421614/run-1738345437.json (1 hunks)
• broadcast/DeployGatewayEVM.s.sol/421614/run-1738345534.json (1 hunks)
• broadcast/DeployGatewayEVM.s.sol/421614/run-latest.json (1 hunks)
• broadcast/DeployGatewayEVM.s.sol/43113/run-1738346292.json (1 hunks)
• broadcast/DeployGatewayEVM.s.sol/43113/run-latest.json (1 hunks)
• lib/types.ts (1 hunks)
• scripts/deploy/deterministic/DeployERC20Custody.s.sol (2 hunks)
• scripts/deploy/deterministic/DeployGatewayEVM.s.sol (2 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

scripts/deploy/deterministic/DeployGatewayEVM.s.sol (1)

Pattern scripts/**: Review the Hardhat scripts for best practices.

scripts/deploy/deterministic/DeployERC20Custody.s.sol (1)

Pattern scripts/**: Review the Hardhat scripts for best practices.

⏰ Context from checks skipped due to timeout of 90000ms (4)

• GitHub Check: test
• GitHub Check: slither
• GitHub Check: generate
• GitHub Check: Analyze (javascript)

🔇 Additional comments (47)

lib/types.ts (2)

1-1: LGTM! The new symbols follow the established pattern.

The added symbols "ETH.ARBSEPOLIA" and "AVAX.AVAX" maintain consistency with the existing naming pattern and align with the PR objectives for deploying contracts on Arbitrum Sepolia and AVAX Testnet networks.

---

2-2: LGTM! The new network names follow the established pattern.

The added networks "arbitrum_sepolia" and "avalanche_testnet" maintain consistency with the existing naming pattern and align with the PR objectives.

scripts/deploy/deterministic/DeployGatewayEVM.s.sol (1)

18-19: Verify potential address collisions with the new salt values.

The salt values have been simplified from keccak256("GatewayEVM-2") to keccak256("GatewayEVM"). While this makes the values cleaner, we need to ensure no address collisions with previously deployed contracts.

Run this script to check for existing contracts at the computed addresses:

scripts/deploy/deterministic/DeployERC20Custody.s.sol (1)

17-18: Verify potential address collisions and deployment order.

The salt values have been simplified from keccak256("ERC20Custody-2") to keccak256("ERC20Custody"). Two important aspects need verification:

1. Potential address collisions with previously deployed contracts
2. Correct deployment order since ERC20Custody depends on GatewayEVM

Run these checks:

broadcast/DeployERC20Custody.s.sol/43113/run-1738383750.json (2)

4-60: Verify successful deployment of ERC20Custody implementation.

The deployment transaction was successful with status "0x1". Contract deployed at 0x0944194980ebe1fff6d095c9be966f5a4fde8a66 using CREATE2 with appropriate gas limits.

---

62-201: Verify successful deployment of ERC20Custody proxy and role assignments.

The proxy deployment and initialization was successful:

• Proxy deployed at 0x521c7665ca120db02c115041122235b8654e60e6
• Implementation set correctly (log at index 0)
• Admin roles granted appropriately (logs at indices 1-6)
• Initialization completed (log at index 7)

broadcast/DeployERC20Custody.s.sol/43113/run-latest.json (1)

1-209: Identical to run-1738383750.json.

This file contains the same deployment information as run-1738383750.json.

broadcast/DeployERC20Custody.s.sol/421614/run-1738383935.json (5)

1-21: ERC20Custody Deployment Transaction Details

This segment documents the first transaction deploying the ERC20Custody contract via CREATE2. The transaction hash, transaction type, contract name, and the deployed contract address are clearly captured. The absence of function calls or constructor arguments (marked as null) is consistent with a straightforward deployment.

---

22-43: ERC1967Proxy Deployment Transaction Details

Here the second transaction is recorded for deploying the ERC1967Proxy contract via CREATE2. Notice that the “arguments” array (lines 28–31) includes initialization parameters—most notably the address of the ERC20Custody implementation (which should match the deployment above) and additional configuration data. Verify that these addresses (case‐insensitive) and parameter encodings match your expected deterministic deployment scheme.

---

45-63: Receipt for ERC20Custody Transaction

This receipt corresponds to the ERC20Custody deployment. The transaction status is successful ("status": "0x1"), and key fields such as cumulativeGasUsed, gasUsed, and sender/receiver addresses are present. The logs array is empty, which is typical if no events were emitted during creation.

---

64-190: Detailed Logs for ERC1967Proxy Deployment

This lengthy logs section records multiple event entries emitted during the ERC1967Proxy deployment. The topics and data fields indicate that events (such as proxy initialization or configuration) are being fired. Please double-check that the topic values (e.g. those beginning with 0x2f878811… and 0x10dac8c06a…) match the expected event signatures for your proxy upgrade mechanism. Overall, the logs provide a detailed audit trail for the deployment process.

---

210-213: Metadata and Deployment Context

The metadata block (timestamp, chain, commit hash) at the end confirms the deployment context. This information is crucial for traceability on the blockchain and integration with your deployment pipeline.

broadcast/DeployERC20Custody.s.sol/421614/run-latest.json (5)

1-21: ERC20Custody Deployment Transaction (Latest Run)

This file essentially reaffirms the deployment details for the ERC20Custody contract. The transaction parameters in lines 1–21 match those in the previous JSON file. The clarity in the transaction’s CREATE2 type and the detailed bytecode input provide confidence in the deterministic deployment procedure.

---

22-43: ERC1967Proxy Deployment Transaction (Latest Run)

The second transaction in this file similarly deploys the ERC1967Proxy using CREATE2 and includes the appropriate initialization arguments. Ensure that the addresses provided (specifically the reference to the ERC20Custody address) are consistent across your deployment logs and that the initialization data has been tested.

---

45-63: Receipt for the First Transaction (Latest Run)

The receipt block (lines 45–63) here mirrors the earlier file – confirming a successful execution with status "0x1", a well‐formatted logsBloom field, and correct gas usage.

---

64-190: Detailed Receipt Logs for ERC1967Proxy (Latest Run)

Like in the previous file, these log entries (lines 64–190) capture the emitted events from the ERC1967Proxy contract. The multiple topics and associated data entries should be cross-checked against the expected events (for proxy initialization, address linking, etc.). They provide a strong audit trail for verification purposes.

---

210-213: Deployment Metadata (Latest Run)

The metadata at the end (timestamp, chain, commit hash) remains consistent. This reinforces that both the “run-1738383935.json” and “run-latest.json” files are reflecting the same deployment context on chain 421614.

broadcast/DeployGatewayEVM.s.sol/421614/run-1738344855.json (8)

1-18: GatewayEVM Deployment Transaction Details

This segment describes the deployment of the GatewayEVM contract via CREATE2. The transaction (lines 1–18) includes the sender, receiver, gas limit, and the long hexadecimal input representing the contract’s bytecode. The recorded contract address (0x496dce139a2903af6187af6017167c5880126e2a) should be verified against your deterministic deployment expectations.

---

19-21: Additional Deployment Flags for GatewayEVM

The fields "additionalContracts": [] and "isFixedGasLimit": false are set appropriately here, indicating no supplementary contracts were bundled and that gas is not fixed.

---

22-43: ERC1967Proxy Deployment in Gateway Context

This second transaction in the file (lines 22–43) deploys the ERC1967Proxy contract. The "arguments" array (lines 29–31) is particularly important: the first argument ("0x496dCe139A2903af6187Af6017167C5880126E2A") should match the deployed GatewayEVM address (note that address comparisons should be case‑insensitive), and the remaining parameters configure the proxy. Ensure these parameters reflect your intended proxy settings across both test networks.

---

44-62: First CALL Transaction to ERC1967Proxy

The next transaction object (lines 44–62) is of type "CALL" and is sent to the previously deployed ERC1967Proxy. The input data (starting with 0x2f2ff15d) suggests an initialization or configuration call. Verify that the encoded parameters (including the target address 0xb741531a1a8984d5188d1058f47eb7cbd57f4655) are as expected for setting up the proxy state.

---

63-81: Second CALL Transaction to ERC1967Proxy

This CALL transaction (lines 63–81) shows a different input payload (starting with 0x2f2ff15d0000…). The near-zero padded portion suggests a possible reconfiguration or a call with empty additional parameters. Confirm that this behavior is intentional and will not lead to an unintended state change in the proxy.

---

82-100: Third CALL Transaction to ERC1967Proxy

Here (lines 82–100), another CALL is issued with an input beginning with 0x36568abe. This likely corresponds to a method selector for a specific proxy function (e.g., updating an implementation address or a related setting). The argument provided is 0x7a3d1b584fd06d8efb9b83672cd1de402c81d873. Ensure that this call correctly finalizes the proxy’s configuration.

---

101-119: Fourth CALL Transaction to ERC1967Proxy

This final CALL transaction (lines 101–119) again uses the selector 0x36568abe but with a slightly different payload (note the difference in the trailing zero bytes). It appears designed to complement the previous call—possibly completing a multi-step initialization. Double-check that the two CALL transactions (with nonces 0x4 and 0x5) together perform the intended configuration without redundancy or conflict.

---

120-128: Deployment Metadata and Context for GatewayEVM

The metadata portion at the end (lines 120–128) provides the timestamp, chain id (421614), and commit hash. This auxiliary data is very useful for auditing and future traceability, ensuring that the deployment is linked to a specific state of the repository and network context.

broadcast/DeployGatewayEVM.s.sol/421614/run-1738345437.json (4)

1-21: Deployment of GatewayEVM Contract

This transaction object deploys the GatewayEVM contract using CREATE2. The detailed fields (e.g. "contractAddress", "input", "nonce", and "chainId": "0x66eee") appear to be set correctly. Please double-check that the updated salt string (embedded within the input bytecode) is intentional so that address collisions are avoided.

---

22-43: Deployment of ERC1967Proxy Contract

This segment deploys the ERC1967Proxy contract via CREATE2. The "arguments" array correctly includes the address of the deployed GatewayEVM contract along with additional encoded initialization parameters. Verify that the hardcoded parameters (especially the salt and the initialization data) have been updated as intended to match the current deployment strategy.

---

44-100: Proxy Contract Interactions via CALL Transactions

Several CALL-type transactions follow, interacting with the newly deployed ERC1967Proxy contract. These transactions show incrementing nonces (from "nonce": "0x2" upward) and include encoded input data for method calls or state changes in the proxy. Please confirm that:

• The input data payloads precisely represent the intended function invocations.
• The gas limits provided (e.g. "gas": "0x8c55" etc.) meet the requirements for each call.
• The overall nonce sequencing remains consistent.

---

121-128: Metadata and File Structure Overview

The tail of the JSON file contains global metadata such as an empty "receipts" array, "libraries", "pending", and overall transaction returns, followed by the "timestamp", "chain": 421614, and the commit identifier. Ensure that having empty receipts is intentional (e.g. in a dry-run or pre-submission state) and that all metadata matches the environment for the Arbitrum Sepolia deployment.

broadcast/DeployGatewayEVM.s.sol/43113/run-1738346292.json (4)

1-21: Deployment of GatewayEVM Contract on Avalanche Testnet

This transaction deploys the GatewayEVM contract using CREATE2 on chain id "0xa869", which appears to correspond to the Avalanche Testnet. The input data and gas limit look analogous to the other deployment file; however, double-check that the chain-specific parameters (such as nonce and chainId) correctly reflect the Avalanche environment.

---

22-43: Deployment of ERC1967Proxy Contract on Avalanche Testnet

Here the ERC1967Proxy is deployed with its arguments array that again references the GatewayEVM address. Notably, the final argument in the list (line 30) differs from that in the Arbitrum deployment—ending with "0xb741531a1a8984d5188d1058f47eb7cbd57f4655" rather than an address used previously. This discrepancy is likely introduced to align with Avalanche Testnet configurations. Please verify that this address change is deliberate and that all initialization parameters are correct for the Avalanche context.

---

45-183: Transaction Receipts and Log Verification

The "receipts" array is populated in this file, detailing the outcomes of the deployments and subsequent interactions. For example, the first receipt confirms the successful deployment of GatewayEVM (with matching "contractAddress") and the logged event topics validate the expected event emissions. Similarly, the second receipt for the proxy reveals logs with expected topics and data. It is advisable to cross-check that these logs precisely match the events defined in your contracts.

---

184-191: Overall File Metadata and Consistency

The file concludes with metadata including "timestamp", "chain": 43113, and the commit hash "cc6041c". Confirm that these metadata values match your deployment pipeline and that the Avalanche Testnet configuration is fully integrated with these settings.

broadcast/DeployGatewayEVM.s.sol/43113/run-latest.json (4)

1-21: Deployment Transaction for GatewayEVM
The first transaction object clearly details the deployment of the GatewayEVM contract using CREATE2. The chain ID "0xa869" correctly corresponds to 43113, matching the Avalanche Fuji Testnet. Please verify that the hardcoded salt (if any) and constructor parameters used (here, no arguments) are exactly those intended for deterministic deployment.

---

22-43: Deployment Transaction for ERC1967Proxy
This transaction deploys the ERC1967Proxy contract via CREATE2. Note that the "arguments" array (lines 28–31) includes two hex strings. The first argument is the deployed GatewayEVM address (with case‐insensitive checksum) and the second is a long encoded parameter (likely constructor data for the proxy). Ensure that these values exactly match the intended initialization parameters to wire the proxy to the correct implementation.

---

45-75: Receipt for GatewayEVM Deployment
The receipt for the GatewayEVM deployment (first receipt object) includes comprehensive details: status, gas used, event logs (with expected topics), and the deployed contract address. All fields (like "gasUsed", "effectiveGasPrice", and "blockHash") appear detailed. Verify that the event log topic on line 53 corresponds to the expected event from GatewayEVM.

---

76-84: Receipt for ERC1967Proxy Deployment
The second receipt object confirms the successful deployment of ERC1967Proxy by showing the correct sender, block data, and detailed event logs. The topics (e.g. on lines 96–104 and 111–119) appear to reflect the expected proxy initialization events. Confirm that these logs reliably indicate that the proxy was correctly initialized with the GatewayEVM address.

broadcast/DeployGatewayEVM.s.sol/421614/run-latest.json (5)

1-21: Deployment Transaction for GatewayEVM on Chain 421614
This transaction object deploys GatewayEVM on a different network—chain ID "0x66eee" translates to 421614. The transaction details (including gas and input) are formatted similarly to the 43113 file. Verify that these parameters meet the requirements for the Arbitrum Sepolia (or other testnet corresponding to 421614) deployment.

---

22-43: Deployment Transaction for ERC1967Proxy on Chain 421614
Here the proxy contract is again deployed via CREATE2. The "arguments" array (lines 29–31) is identical in structure to the previous file, referencing the GatewayEVM address and including the proxy’s initialization data. Please confirm that these values are correctly set for this deployment and that the expected dependency on GatewayEVM is maintained.

---

45-77: Receipt for GatewayEVM Deployment (421614)
The receipt for the GatewayEVM deployment on this chain includes additional fields such as "gasUsedForL1" and "l1BlockNumber", which are often present in rollup or layer‑2 environments. These extra fields (e.g. line 75–76) are useful for cost calculations. Ensure that the logged values and the effective gas price (line 71) match your expectations for the network’s fee structure.

---

78-187: Receipt for ERC1967Proxy Deployment (421614)
This receipt details the success of the ERC1967Proxy deployment. The event logs (lines 83–172) include multiple event topics verifying both initialization and any emitted events from the proxy. The consistency of sender, gas consumption, and other properties (including the extra L1 fields) confirms an overall correct execution. Check that the sequence of topics (especially those on lines 147–156) accurately reflects the expected proxy event signatures.

---

188-195: Metadata and Overall Deployment Summary
The metadata section (lines 188–195) shows the timestamp, the chain (421614), and the commit hash. This final summary ties the deployment records to the PR’s specific commit. Ensure that the metadata remains in sync with the desired deployment environment and that any documentation referencing these files is updated accordingly.

broadcast/DeployGatewayEVM.s.sol/421614/run-1738345534.json (5)

1-21: Review GatewayEVM Transaction Object:

The deployment transaction for the GatewayEVM contract is clearly structured and correctly uses the CREATE2 mechanism. Key fields such as "hash", "transactionType", "contractName", and "contractAddress" are present and in the expected format. Please verify that the updated hardcoded salt (as mentioned in the PR objectives to prevent address collisions) is correctly integrated in the contract initialization, if applicable.

---

22-43: Review ERC1967Proxy Deployment Details:

This transaction object is responsible for deploying the ERC1967Proxy contract. The "arguments" array includes two critical parameters: the first being the implementation contract address and the second containing the encoded initialization data. Ensure that the second argument reflects the updated salt string and related parameters according to the PR, thereby preventing address collisions. Also, the transaction fields (such as "nonce", "chainId", and "gas") appear appropriate.

---

45-77: Validate GatewayEVM Deployment Receipt:

The first receipt confirms a successful deployment of the GatewayEVM contract. The "status" field is "0x1", the "cumulativeGasUsed" appears correct, and the single log entry (with its topic and data) is well structured. It is recommended to double-check that the emitted event corresponds to your expected contract event.

---

78-187: Validate ERC1967Proxy Deployment Receipt and Logs:

The second receipt is comprehensive with several log entries that document various events from the proxy deployment. The multiple log entries—with distinct topic hashes—suggest that both initialization events and proxy-specific notifications are captured. Confirm that these logs accurately reflect the proper initialization parameters, and that the gas details (including "gasUsed", "effectiveGasPrice", and "gasUsedForL1") match your deployment expectations.

---

188-195: Review Metadata and Chain Details:

The metadata section at the end of the file provides important information such as the timestamp, the deployment chain (set to 421614, which aligns with the target network), and the commit identifier. These details ensure proper traceability. No issues are noted with this section.

✨ Finishing Touches

• 📝 Generate Docstrings (Beta)

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.07%. Comparing base (cc6041c) to head (f4ef6b5).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #458   +/-   ##
=======================================
  Coverage   87.07%   87.07%           
=======================================
  Files           9        9           
  Lines         526      526           
  Branches      128      128           
=======================================
  Hits          458      458           
  Misses         68       68           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.