feat: deploy Arbitrum Sepolia and AVAX Testnet contracts #458
Conversation
📝 WalkthroughWalkthroughThis pull request involves the deployment of two key smart contracts, Changes
Suggested reviewers
Possibly related PRs
📜 Recent review detailsConfiguration used: .coderabbit.yaml ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
Documentation and Community
|
julianrubino
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
lib/types.ts (2)
1-1: Improve naming consistency and organization of token symbols.Consider the following improvements:
- Maintain consistent network naming:
- "ETH.BASESEPOLIA" vs "USDC.SEPOLIA" - standardize on one format
- Group symbols by network type:
- Consider splitting into separate types for mainnet and testnet symbols
- Standardize symbol format:
- Some symbols like "USDC", "tBTC" don't follow the "TOKEN.NETWORK" pattern
Example refactor:
export type MainnetParamSymbol = | "USDC.ARB" | "USDT.ARB" | "ETH.ARB" // Arbitrum | "USDC.AVAX" | "USDT.AVAX" | "AVAX.AVAX" // Avalanche // ... other mainnet symbols export type TestnetParamSymbol = | "ETH.BASESEPOLIA" | "USDC.SEPOLIA" // Sepolia | "USDC.FUJI" | "AVAX.FUJI" // Fuji // ... other testnet symbols export type ParamSymbol = MainnetParamSymbol | TestnetParamSymbol;
2-2: Clarify the purpose of "empty" and improve network naming consistency.
- The purpose of the "empty" chain name is unclear. Please add a comment explaining its use case.
- Consider the following improvements:
- Group networks by type (mainnet/testnet)
- Standardize naming patterns across networks
Example refactor:
/** * Supported blockchain networks in the protocol * @property empty - [Add explanation here] */ export type MainnetParamChainName = | "eth_mainnet" | "bsc_mainnet" | "polygon_mainnet" | "solana_mainnet" | "zeta_mainnet" | "btc_mainnet" | "base_mainnet"; export type TestnetParamChainName = | "bsc_testnet" | "zeta_testnet" | "btc_signet_testnet" | "btc_testnet4" | "amoy_testnet" | "base_sepolia" | "sepolia_testnet"; export type ParamChainName = MainnetParamChainName | TestnetParamChainName | "empty";
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
data/addresses.testnet.jsonis excluded by!data/**
📒 Files selected for processing (1)
lib/types.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Analyze (javascript)
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (8)
broadcast/DeployGatewayEVM.s.sol/43114/run-1739385966.json (2)
22-43: Review of ERC1967Proxy Deployment TransactionThis block (lines 22–43) captures the deployment of the
ERC1967Proxycontract. Note that theargumentsarray includes:
- The address of the
GatewayEVMcontract (line 29).- A long hex string (line 30) that likely encodes initialization or configuration data.
In line with the PR’s objective of modifying the hardcoded salt to prevent address collisions, please verify that the encoded values (such as salt or initializer parameters) are correctly updated. Adding an inline comment or documentation (if not already elsewhere) to clearly indicate the purpose of this hex payload could improve clarity.
393-399: Review of File Metadata and Overall StructureThe closing section (lines 393–399) summarizing metadata (empty libraries/pending/returns, timestamp, chain, and commit) is comprehensive. In line with the PR objective to enhance clarity, you might consider adding an explicit
"networkName": "<network name>"field (e.g."Avalanche Testnet") to avoid any ambiguity regarding the targeted network—especially since the chain ID (43114) could be interpreted differently.broadcast/DeployGatewayEVM.s.sol/42161/run-1739386352.json (1)
63-81: Transaction 4: Inspection of Second CALL on ERC1967ProxyNotice that the second CALL transaction (with
nonce"0x3") has a slightly different gas limit ("0x51a05"vs."0x51bfc") and its"input"field starts with0x2f2ff15d0000..., differing from the previous CALL’s input. Please verify that these differences are intentional—reflecting either distinct function calls or parameter variations—and that the modified gas allocation is sufficient for the call’s execution.broadcast/DeployGatewayEVM.s.sol/42161/run-1739387694.json (2)
1-24: Review of CREATE2 Deployment Transaction Block
The first transaction object (lines 1–24) deploys the ERC1967Proxy using the CREATE2 opcode. Please verify that:
- The order and meaning of the
argumentsarray (lines 10–11) correctly reflect the updated salt and initialization parameters as outlined in the PR objectives.- The lengthy
inputdata (line 18) accurately represents the intended initialization bytecode for the proxy contract.- The hardcoded values (such as the addresses) are consistent with the deployment expectations for the target networks.
353-360: Review of Deployment Metadata and Summary
The final block (lines 353–360) provides overall metadata for the broadcast. Please verify that:
- The empty arrays for
librariesandpending, and the empty object forreturns, are as expected given the current deployment process.- The
timestamp,chain(42161), andcommitfields accurately reflect the intended network and revision state as specified by the deployment scripts and the PR objectives.broadcast/DeployGatewayEVM.s.sol/43114/run-1739382638.json (3)
22-43: Review of ERC1967Proxy Deployment (CREATE2) BlockThis block deploys the
ERC1967Proxycontract via CREATE2. Note that the constructor arguments include a checksummed version of the previously deployedGatewayEVMaddress (line 29) and a long encoded initialization payload (line 30). The use of mixed-case for the proxy’s first argument confirms an EIP-55 checksum and is acceptable. Please verify that the encoded initialization data (the second argument) is correct and matches the intended setup of the proxy.
63-81: Review of Second CALL Transaction to ERC1967Proxy (Nonce: 0x3)In this block (lines 63–81), the CALL transaction again targets the proxy contract but the input data now differs from the previous call: the segment following the function selector
0x2f2ff15dis now all zeros rather than including the previously included bytes (65d7a28e…). Verify that this change in input data is intentional (for example, a variant call with a differing argument value) and that the nonce is correctly incremented.
101-119: Review of Fourth CALL Transaction to ERC1967Proxy (Nonce: 0x5)Here (lines 101–119), the input data starts with the same function selector (
0x36568abe) but—unlike the previous similar call—the payload following the selector is zeros instead of the former non-zero value. This difference may indicate a variant of the same function call (perhaps with default or empty arguments). Please confirm that this variation is deliberate.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
data/addresses.mainnet.jsonis excluded by!data/**data/addresses.testnet.jsonis excluded by!data/**
📒 Files selected for processing (13)
broadcast/DeployERC20Custody.s.sol/42161/run-1739388276.json(1 hunks)broadcast/DeployERC20Custody.s.sol/42161/run-latest.json(1 hunks)broadcast/DeployERC20Custody.s.sol/43114/run-1739386113.json(1 hunks)broadcast/DeployERC20Custody.s.sol/43114/run-latest.json(1 hunks)broadcast/DeployGatewayEVM.s.sol/42161/run-1739386352.json(1 hunks)broadcast/DeployGatewayEVM.s.sol/42161/run-1739387258.json(1 hunks)broadcast/DeployGatewayEVM.s.sol/42161/run-1739387694.json(1 hunks)broadcast/DeployGatewayEVM.s.sol/42161/run-latest.json(1 hunks)broadcast/DeployGatewayEVM.s.sol/43114/run-1739382638.json(1 hunks)broadcast/DeployGatewayEVM.s.sol/43114/run-1739385966.json(1 hunks)broadcast/DeployGatewayEVM.s.sol/43114/run-latest.json(1 hunks)lib/types.ts(1 hunks)tasks/addresses.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- lib/types.ts
🧰 Additional context used
📓 Path-based instructions (1)
`tasks/**`: Review the Hardhat tasks for best practices.
tasks/**: Review the Hardhat tasks for best practices.
tasks/addresses.ts
🔇 Additional comments (67)
broadcast/DeployGatewayEVM.s.sol/43114/run-1739385966.json (6)
1-21: Review of GatewayEVM Deployment TransactionThis first transaction object (lines 1–21) logs the deployment of the
GatewayEVMcontract using the CREATE2 mechanism. The details (transaction hash, type, contract name, contract address, and full transaction parameters) are comprehensive. One point to verify: the"chainId": "0xa86a"appears as a hexadecimal representation of 43114. Please double-check that this chain ID aligns with the intended AVAX Testnet network as outlined in the PR objectives.
44-62: Review of First CALL Transaction to ERC1967ProxyThis transaction (lines 44–62) represents a CALL-type interaction with the deployed
ERC1967Proxycontract. The transaction data (input starting with "0x2f2ff15d") and gas limits are detailed, and the nonce is correctly set. Overall, this entry appears well formed. It would be useful to confirm that the encoded function call matches the intended initializer or configuration method.
63-81: Review of Second CALL Transaction to ERC1967ProxyThis CALL-type transaction (lines 63–81) repeats a similar pattern—with a slightly different input (starting with "0x2f2ff15d0000…") and an incremented nonce. The consistency across these transaction objects is good. Please verify that the subtle differences in the input payload (if intentional) accurately reflect the intended contract interactions.
82-100: Review of Third CALL Transaction to ERC1967ProxyThis section (lines 82–100) logs another CALL transaction (with input starting as "0x36568abe…"). The transaction details—including gas, nonce, and chainId—are laid out consistently. As these interactions likely correspond to post-deployment initialization or configuration calls, ensure that the function signatures encoded in the input data match what the proxy expects.
101-120: Review of Additional CALL TransactionsThe subsequent transactions (lines 101–120) continue with CALL-type operations on the
ERC1967Proxycontract. Multiple entries with incremented nonces and detailed input data suggest iterative configuration or multiple function invocations. The structure is repetitive and appears correct; just be sure that each CALL’s input data is validated against the deployed contract’s ABI.
121-392: Review of Transaction ReceiptsThe
receiptsarray (lines 121–392) provides detailed outcomes for each transaction. Key fields such as status, cumulative gas used, logs (with topics and data), and effective gas prices are present. The event topics (for example,"0xc7f505b2f371ae2175ee4913f4499e1f2633a7b5936321eed1cdaeb6115181d2") and log data help in auditing the deployment and subsequent CALL interactions.A couple of suggestions:
- Verify that each receipt’s log topics correspond to the expected events emanating from the deployed contracts.
- If possible, consider adding a mapping (in documentation or comments) between the known event signatures and their meanings for future maintainability.
broadcast/DeployGatewayEVM.s.sol/42161/run-1739387258.json (7)
1-21: JSON Structure & GatewayEVM Deployment TransactionThis new file defines the deployment transaction for the
GatewayEVMcontract using CREATE2. The transaction object (lines 1–21) includes all expected fields (hash, transactionType, contractName, contractAddress, input bytecode, nonce, chainId, etc.). The long hex “input” appears consistent with a contract creation payload generated by Solidity.
22-43: ERC1967Proxy Deployment for GatewayEVMThe second transaction block deploys an
ERC1967Proxycontract with initialization arguments. Notably, the arguments (line 29 and 30) reference the deployedGatewayEVMcontract’s address and the proxy initialization data. Please double-check that the arguments (including the modified salt values) are updated per the PR objectives to prevent address collisions.
44-62: First CALL Transaction to ERC1967ProxyThis transaction (lines 44–62) is a CALL-type interaction with the proxy contract. The input data (starting with “0x2f2ff15d…”) suggests a method invocation on the proxy. Verify that the encoded function call and parameters match the intended administrative or initialization step. Also, the nonce (“0x2”) is in proper sequence relative to the deployment transactions.
63-81: Second CALL Transaction to ERC1967ProxyThis block (lines 63–81) details another CALL transaction. The input begins with a similar method selector but with different subsequent data. Please confirm that the differences in input encoding correlate with distinct function calls and that the nonce (“0x3”) and gas settings (e.g. "0x1ef6e") are correctly set.
82-100: Third CALL Transaction to ERC1967ProxyHere (lines 82–100), a further CALL transaction is recorded. Note the nonce “0x4” and the repeated pattern in the input data. Ensure that these repeated calls are intentional (e.g. for multi-step initialization or configuration) and that the proxy’s address and transaction parameters remain consistently correct.
101-119: Fourth CALL Transaction to ERC1967ProxyThis final CALL transaction in the “transactions” array (lines 101–119) completes the sequence, with nonce “0x5.” It is important to verify that the order of nonces (from 0x0 to 0x5) is maintained and that every function call’s input is correctly encoded to reflect the chain’s operational requirements.
120-130: Metadata & Pending TransactionsThe file concludes with the “receipts”, “libraries”, “pending”, “returns”, “timestamp”, “chain”, and “commit” fields. The pending array (line 123) contains the expected transaction hash. Overall, the metadata appears complete and consistent with a deployment log on chain 42161.
broadcast/DeployERC20Custody.s.sol/42161/run-1739388276.json (4)
1-21: Deployment Transaction for ERC20CustodyThis new JSON file begins with a CREATE2 transaction (lines 1–21) deploying the
ERC20Custodycontract. The transaction includes all required fields such as hash, contractAddress, input bytecode, nonce ("0x6"), and chainId ("0xa4b1"). The structure and format conform to expectations for a solidity deployment.
22-43: ERC1967Proxy Deployment for ERC20CustodyThe second transaction block (lines 22–43) deploys an
ERC1967Proxyfor ERC20Custody. The initialization arguments (lines 29–30) include the address ofERC20Custody(note the case variation in the hexadecimal string is acceptable if checksummed) and a long hex payload for proxy initialization. Please verify that these arguments correctly match the intended configuration and reflect any changes to the hardcoded salt values.
44-138: Series of CALL Transactions on ERC1967ProxyA number of CALL transactions follow (lines 44–138) that record interactions with the deployed proxy contract. These transactions include varying input data payloads and maintain a proper nonce sequence. Reviewers should confirm that:
- The input encoding for each call (e.g. selectors starting with “0x2f2ff15d”, “0x36568abe”, etc.) accurately reflects the intended function invocations.
- The nonce ordering (increasing sequentially) is maintained.
- The gas limits and values are appropriate for the operations.
Overall, the repeated proxy calls seem deliberate as part of the initialization/configuration process.
159-537: Receipts & Event Logs VerificationThe “receipts” section (lines 159–537) captures receipt details from the deployment and subsequent interactions. The logs within these receipts include several topics and data fields that correspond to events emitted by the deployed contracts. In particular:
- Event topics such as
"0x2f8788117e7eff1d82e926ec794901d17c78024a50270940304540a733656f0d"are present and should be cross-checked with the expected event signatures.- The gas usage and L1-gas metrics are reported, which is useful for cross-chain cost analysis.
Ensure these logs and bloom filters align with the expected contract events and that no important events are missing from the output.broadcast/DeployGatewayEVM.s.sol/42161/run-1739386352.json (6)
1-21: Transaction 1: Validate Deployment Record for GatewayEVM ContractThe deployment entry for the
GatewayEVMcontract appears well structured with proper fields (e.g."transactionType": "CREATE2","contractAddress", and detailed"transaction"data includingnonceandchainId). Please verify that the long"input"hex string correctly encodes the intended constructor data and that the null"hash"is expected at this stage (pre-broadcast).
22-31: Transaction 2: Verify ERC1967Proxy Deployment DataThe record for deploying the
ERC1967Proxycontract includes an"arguments"array carrying two values: the address of the deployedGatewayEVM(with mixed-case checksum) and a lengthy hex blob that likely encapsulates the proxy’s initialization parameters. Please confirm that the order and formatting of these arguments match the expected constructor signature, and that the address format is consistent with your project’s checksum requirements.
44-62: Transaction 3: Review First CALL on ERC1967ProxyThis CALL transaction (with
nonceset to"0x2") carries an"input"data field beginning with0x2f2ff15d65d7a28e.... It appears to invoke a function on the proxy contract. Please double-check that the function selector and the encoded parameters are correct and align with the intended initialization or configuration call on theERC1967Proxy.
82-100: Transaction 5: Validate Third CALL on ERC1967ProxyThis CALL (with
nonce"0x4") introduces an input that begins with0x36568abe, indicating a different function selector compared to the earlier calls. Ensure that the newly targeted function is correct and that its parameter encoding (as represented in the extended hexadecimal string) properly meets the contract’s interface requirements. Also, review if the gas limit provided here is appropriate for the operation.
101-119: Transaction 6: Confirm Fourth CALL on ERC1967ProxyThe final CALL transaction (with
nonce"0x5") reuses the function selector0x36568abebut with a subtle variation in the encoded parameters. Verify that this call fits into the intended sequence—following the previous CALLs—to complete the proxy’s initialization or configuration workflow. Confirm that the nonce progression (from 0x2 through 0x5) correctly reflects the ordered intent in the deployment process.
120-128: Metadata and Overall JSON StructureThe remainder of the JSON (fields such as
"receipts","libraries","pending","returns","timestamp","chain", and"commit") provides useful context for post-deployment tracking. Given the PR objective to deploy on Arbitrum Sepolia and AVAX Testnet, please double-check that the"chain": 42161value (typically associated with Arbitrum One) is indeed intentional for this deployment artifact.broadcast/DeployGatewayEVM.s.sol/42161/run-1739387694.json (8)
25-43: Review of First CALL Transaction Block
This transaction object (lines 25–43) represents a CALL to the ERC1967Proxy contract. Note that thefunctionandargumentsfields are set tonull, which appears to be intentional. Please confirm that:
- The gas limit specified (e.g.,
"gas": "0x18cf2"on line 35) is appropriate for the expected contract interaction.- The nonce and chain-related fields (line 38 and line 39) are consistent with the transaction sequence and network configuration.
44-62: Review of Second CALL Transaction Block
In this transaction (lines 44–62, starting with the hash on line 45), similar CALL parameters are provided for interacting with the ERC1967Proxy. Please ensure that:
- The transaction’s
inputdata (line 56) is correctly encoded to call the intended function (even if the function name remainsnullin the JSON, the data should match the expected ABI format).- The repeated use of the same proxy contract address and consistent gas settings validate the intended sequential interactions.
63-81: Review of Third CALL Transaction Block
This block (lines 63–81) details another CALL transaction on the proxy contract. Please double-check that:
- The encoded call data in the
inputfield (line 75) corresponds to the proper function call as expected from the deployment process.- The nonce progression (line 77) and gas settings are correct relative to the previous transactions.
102-212: Review of First Receipt Block
Receipt block one (lines 102–212) corresponds to the initial CREATE2 deployment transaction. Key points to verify include:
- The event log at line 110 (first topic) and subsequent topics correctly reflect the expected emitted events from the ERC1967Proxy contract—this helps confirm a successful deployment.
- The block and transaction details (e.g., gas values, nonce, and chain id) are consistent with the deployment parameters.
213-247: Review of Second Receipt Block
This receipt (lines 213–247) is generated by a CALL transaction. Please confirm that:
- The log entries (lines 218–224) include the correct topics and address references for the proxy interactions.
- The cumulative gas used and other metadata are in line with expectations for such a transaction.
248-282: Review of Third Receipt Block
Receipt block three (lines 248–282) details another subsequent CALL transaction. Please ensure that:
- The reported gas usage (
"gasUsed": "0x18184"on line 275) and log structure (lines 253–259) match the contract’s event emission pattern.- The event topics continue to correctly trace the interactions with the deployed ERC1967Proxy contract.
283-317: Review of Fourth Receipt Block
This receipt (lines 283–317) includes additional log entries capturing specific event emissions. Please verify that:
- The event signature found at line 290 correctly identifies the expected event from the proxy call.
- Other fields such as nonce progression and block details (lines 293–298) are consistent with prior transactions.
318-352: Review of Fifth Receipt Block
The fifth receipt (lines 318–352) shows further logging for a CALL transaction. Key review points:
- The event logs (e.g., topics on lines 325–329) should be cross-checked with the expected ABI of the contract to ascertain correctness.
- Ensure that the cumulative gas used and L1-related fields (e.g.,
"gasUsedForL1"on line 350) are valid and consistent with the overall deployment reporting.broadcast/DeployGatewayEVM.s.sol/42161/run-latest.json (13)
1-12: Ensure Accurate Contract Initialization and Salt UpdateThis initial JSON block defines the first deployment transaction for the proxy. Please verify that the argument at line 10—which holds the GatewayEVM address (after checksum normalization)—correctly reflects the updated, non-colliding hardcoded salt change. Confirm that this value is propagated consistently across related deployment files.
13-21: Validate First Transaction ParametersThe "transaction" object for the initial CREATE2 deployment (lines 13–21) includes essential metadata (sender, recipient, gas, nonce, and chainId). Ensure that the gas limit and the chainId value ("0xa4b1") match the expected settings for the target test network. Also, verify that the long input data is generated correctly.
22-24: Confirm JSON Structural IntegrityThe closing lines of the first transaction block (lines 22–24) correctly finalize the object's structure. No issues noted.
25-43: Evaluate CALL Transaction Parameters and Input DataThis transaction (lines 25–43) records a CALL to the ERC1967Proxy contract. Note that the "arguments" field is null while the "input" field carries encoded data. Please double-check that the encoded function call and the nonce sequencing (nonce "0x2") are as intended, ensuring that no parameters are inadvertently omitted.
44-62: Verify Second CALL Transaction ConsistencyThe transaction block here (lines 44–62) shows the next proxy call with nonce "0x3". Confirm that the input data correctly represents the desired method invocation and that the transaction details (sender, receiver, gas, chainId) remain consistent with deployment expectations.
63-81: Confirm Correctness of Subsequent CALL InvocationThis transaction (lines 63–81) with nonce "0x4" includes another proxy call. Please ensure that the input field (the encoded call data) is correctly generated and matches the intended function signature. Verifying that the nonce sequence follows as expected is also recommended.
82-100: Ensure Correctness of Final Transaction in SequenceThe final transaction record (lines 82–100) with nonce "0x5" completes the deployment sequence. The input data appears to contain an explicit method signature. Confirm that this hex string correctly corresponds to the targeting of the ERC1967Proxy and that all values (addresses, gas, chainId) are as expected.
102-212: Review Receipt Details for the CREATE2 TransactionThis receipt (lines 102–212) for the initial CREATE2 transaction confirms a successful deployment ("status": "0x1") and includes a set of log entries. Please verify that the event topics—especially those at lines 110–112—accurately reflect the deployment parameters and incorporate the updated salt/address information. Also, check that the gas usage metrics are within expected bounds.
213-247: Verify Receipt Data for First CALL TransactionThe receipt here (lines 213–247) corresponds to a CALL transaction. The cumulative gas used and log entries appear consistent. Please ensure the event signature and topics in the logs (lines 219–224) correctly capture the proxy contract call effects.
248-282: Inspect Receipt for Second CALL TransactionThis receipt (lines 248–282) details another proxy call. The log indices and event topics should be verified against the intended contract interactions. All transaction details (nonce, sender, chainId) appear consistent—double-check for any mismatches.
283-317: Examine Receipt for Third CALL TransactionReceipt (lines 283–317) for the CALL with nonce "0x1" (as part of the sequence) shows multiple event logs. Please confirm that the captured topics (e.g., method identifiers) reflect the updated deployment logic and that the included metadata (gasUsed, block details) is accurate.
318-352: Validate Receipt for Final TransactionThe final receipt (lines 318–352) confirms successful execution with expected log events. Verify that the log topics, gas usage, and overall transaction metadata—including the precise chain id and nonce sequence—align with the updates made for the deployment process.
353-360: Finalize Metadata VerificationThe closing section (lines 353–360) provides metadata such as "timestamp", "chain", and "commit". Confirm that the "chain" value (42161) is correctly set for the targeted test environment and that the commit hash ("e145ca5") corresponds to the current deployment code version.
tasks/addresses.ts (2)
184-184: LGTM! The chain name property update is consistent.The change from
chain.chain_nametochain.namealigns with the network package's API and is applied consistently across all address object creations.Also applies to: 194-194
174-174:❓ Verification inconclusive
Verify the network package's API for chain property naming.
The change from
chain.chain_nametochain.namesuggests an API update. Let's verify this change is consistent with the@zetachain/networkspackage.
🏁 Script executed:
#!/bin/bash # Description: Check the network package's chain object structure # Install the package npm install @zetachain/networks # Create a test script to inspect the chain object cat > test.js << 'EOF' const { getEndpoints } = require('@zetachain/networks'); console.log(JSON.stringify(getEndpoints('evm', 'arbitrum-sepolia'), null, 2)); EOF # Run the test script node test.jsLength of output: 1045
Action: Request Manual Verification for Correct Network Identifier
The update from
chain.chain_nametochain.nameintasks/addresses.tsseems intended to reflect a change in the API of@zetachain/networks. However, the initial test script using'arbitrum-sepolia'failed with an error indicating that this network does not exist. To confidently verify that the API now returns a chain object with thenameproperty, please re-run the verification using a valid network identifier as defined by the package (for example, one from the official documentation or a known working network).
- Next Steps:
- Confirm the valid network identifiers supported by the
@zetachain/networkspackage.- Run a revised test script with a valid network so that the output structure (particularly the chain property) can be inspected.
- Once verified, update this review comment to confirm that using
chain.nameis correct.broadcast/DeployERC20Custody.s.sol/43114/run-latest.json (2)
7-7: LGTM! Contract addresses are deterministic across networks.The ERC20Custody and ERC1967Proxy contracts are deployed at the same addresses across networks:
- ERC20Custody:
0x0944194980ebe1fff6d095c9be966f5a4fde8a66- ERC1967Proxy:
0xece33274237e6422f2668ed7dee5901b16336aa0This is achieved through CREATE2 deployment with consistent salt values.
Also applies to: 26-26
161-161: LGTM! All deployment transactions were successful.All transactions have a status of "0x1" indicating successful execution:
- ERC20Custody implementation deployment
- ERC1967Proxy deployment
- Role assignments and initialization
Also applies to: 177-177, 317-317, 391-391, 426-426, 461-461, 496-496
broadcast/DeployERC20Custody.s.sol/42161/run-latest.json (2)
7-7: LGTM! Contract addresses match AVAX deployment.The ERC20Custody and ERC1967Proxy contracts are deployed at the same addresses as on AVAX:
- ERC20Custody:
0x0944194980ebe1fff6d095c9be966f5a4fde8a66- ERC1967Proxy:
0xece33274237e6422f2668ed7dee5901b16336aa0This confirms the deterministic deployment is working correctly across networks.
Also applies to: 26-26
161-161: LGTM! All deployment transactions were successful.All transactions have a status of "0x1" indicating successful execution:
- ERC20Custody implementation deployment
- ERC1967Proxy deployment
- Role assignments and initialization
Also applies to: 179-179, 321-321, 356-356, 391-391, 426-426, 496-496
broadcast/DeployERC20Custody.s.sol/43114/run-1739386113.json (9)
1-21: Confirm ERC20Custody Deployment via CREATE2
This object records the deployment of the ERC20Custody contract using the CREATE2 scheme. The contract’s name, its deployed address, and the chain identifier (chainId “0xa86a”, which corresponds to 43114) appear consistent with expectations.
Make sure that any modifications to the hardcoded salt (as mentioned in the PR objectives) are properly applied in your deployment script and reflected in the encoded input data.
22-43: Validate ERC1967Proxy Deployment Configuration
The second transaction object deploys the ERC1967Proxy contract via CREATE2. Notice that its arguments array references the ERC20Custody contract address (line 29) and contains a long hex string for initialization. Please verify that the address formats—especially the mixed-case checksum in “0x0944194980ebe1fFF6d095C9bE966F5A4FdE8a66”—are intentional and consistent across the deployment process.
44-62: Review Initialization CALL on ERC1967Proxy
This CALL transaction (starting at line 44) likely represents an initialization or configuration call on the deployed ERC1967Proxy contract. Check that the provided gas limit, nonce, and encoded input data correctly reflect the intended function invocation.
83-99: Examine Subsequent CALL to ERC1967Proxy
For the CALL transaction with hash0x121424d4a4af4134dbf8506172e311d865a366ca01bbb9b1115341c2cb002a16(lines 83-99), verify that the nonce and input data are accurate and that the function call encoded in the input matches the expected updates on the proxy’s state.
102-118: Validate ERC1967Proxy CALL Transaction with Specified Gas
This CALL transaction (hash0x1b336fc962163b581896ee2077dbf13fe8de779e605d3c3dd1b4f05a8e378893, lines 102-118) appears to be another operation on the ERC1967Proxy. Ensure that the gas settings and the encoded call data are correct, and that its execution aligns with your deployment/initialization logic.
121-138: Check Additional ERC1967Proxy CALL Transaction Data
The transaction (hash0xcab71d89e1f9ee3a58c6d5da97b782f60611dcdaaa5e987190434f15ea57e8cf, lines 121-138) should be reviewed for consistency with earlier calls. Confirm that the input encoding and address parameters are correct and that no unintended modifications occurred during the salt or parameter updates.
140-157: Review Final CALL Transaction to ERC1967Proxy
For the last CALL transaction in the list (hash0x640e09f295b9147c84d3bc8ae465d619a47e54caedb174785177209cff8c591f, lines 140-157), verify that the nonce, gas limits, and input data match your intended initialization or configuration actions. This is critical for ensuring that the proxy contract’s state is correctly set.
159-514: Ensure Comprehensive Transaction Receipts Logging
The receipts array (lines 159-514) captures detailed execution data for every transaction, including status codes, gas usage, and emitted logs with their topics and data. In particular:
- Confirm that the receipt for the ERC20Custody deployment (receipt with contractAddress “0x0944194980ebe1fff6d095c9be966f5a4fde8a66” around line 174) is correct.
- Ensure that event topics (e.g. those starting with
0x2f8788117e7eff1d82e926ec794901d17c78024a5...) correspond to the expected events from both the proxy and the deployed custody contract.- Verify that all transactions succeeded (status “0x1”) and that cumulative gas values are within expected bounds.
Overall, the detailed logs will be invaluable for audits and troubleshooting; consider documenting the expected event signatures in your project documentation.
515-521: Confirm Metadata and Deployment Context
The metadata section (lines 515-521) lists empty arrays for libraries, pending transactions, and returns, followed by a timestamp, chain identifier (43114), and commit hash. Verify that these fields accurately represent the deployment context and that the timestamp aligns with your expected deployment window.broadcast/DeployGatewayEVM.s.sol/43114/run-latest.json (4)
1-399: Overall JSON File Structure is Comprehensive
The file is a newly added, well-formatted JSON document that captures both the deployment transactions and the subsequent receipt logs in full detail. The overall structure—with separate sections for “transactions”, “receipts”, and metadata (libraries, pending, returns, timestamp, chain, commit)—provides a clear and complete record of the deployment process.
1-120: Transactions Array: Detailed Deployment and Contract Calls
The “transactions” array (lines 1–120) lists multiple transaction objects, including CREATE2 deployments for both the GatewayEVM and ERC1967Proxy contracts as well as several CALL transactions. Each object includes key parameters such as hash, transactionType, contractName, contractAddress, input data, nonce, gas, and chainId. Please ensure that:
- The encoded input data (e.g., function selectors and arguments) adheres to the contract ABI expectations.
- All addresses (especially those in the “arguments” field) are properly checksummed and accurate.
- Nonces and gas values are consistent with your local deployment tools’ expectations.
121-392: Receipts Array: Event Logs and Gas Metrics are Detailed
The “receipts” section (lines 121–392) records the status, cumulative gas usage, detailed logs (including topics and bloom filters), and other transaction execution metadata. This level of detail is valuable for auditing and troubleshooting. Please verify that:
- The event topics (for example, those related to contract deployments and proxy calls) match the intended contract event definitions.
- The gas usage and cumulative gas figures are in line with expectations.
393-399: Metadata and Timestamp Verification
The metadata at the end of the JSON (lines 393–399) includes fields for libraries, pending, returns, a Unix timestamp (1739385966), the chain number (43114), and the commit hash (e145ca5). These provide useful context for the deployment record. Please confirm that the timestamp reflects the intended deployment time and that the commit hash corresponds to the deployed source.broadcast/DeployGatewayEVM.s.sol/43114/run-1739382638.json (4)
1-21: Review of GatewayEVM Deployment BlockThis transaction deploys the
GatewayEVMcontract via CREATE2. The parameters (e.g. nonce"0x0", gas limit, encoded input bytecode, and chainId"0xa86a") appear consistent with what one would expect for a deterministic deployment on Avalanche (chain 43114).
44-62: Review of First CALL Transaction to ERC1967Proxy (Nonce: 0x2)This CALL transaction (lines 44–62) targets the proxy at
0x1c53e188bc2e471f9d4a4762cff843d32c2c8549with input data starting with0x2f2ff15d…. The gas setting (0x12ffd) and nonce ("0x2") look proper. Ensure that the encoded function selector and parameters in the input data are correct and that the data (including the trailing address parameter) indeed represents the intended call.
82-100: Review of Third CALL Transaction to ERC1967Proxy (Nonce: 0x4)This transaction (lines 82–100) uses a different function selector (
0x36568abe) with appended input data that again includes a non-zero segment. Confirm that the function selector “0x36568abe” and its associated data correctly target the intended function on the proxy. The nonce ("0x4") and gas estimation (0xaaf1) appear in line with the sequence of transactions.
120-128: Review of Metadata and Final FieldsThe final JSON fields (lines 120–128) correctly capture additional metadata such as empty receipts/libraries, the UNIX timestamp, the chain (43114), and the commit hash. This metadata helps ensure traceability for this deployment run.
Summary by CodeRabbit
New Features
ERC20Custody,ERC1967Proxy,GatewayEVMDeployment
ERC20Custodycontract at address0x0944194980ebe1fff6d095c9be966f5a4fde8a66ERC1967Proxycontract at address0xece33274237e6422f2668ed7dee5901b16336aa0GatewayEVMcontract at address0x496dce139a2903af6187af6017167c5880126e2aImprovements
fetchChainSpecificAddressesfunction for better consistency.