Conversation
Individual route configs and deploy artifacts: - USDC: arbitrum, base - USDT: arbitrum, base - mantraUSD: mantra - USDH: hyperevm Combined MULTI config with full cross-enrollment across all routes. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
e8c46f0 to
2a9fe79
Compare
Check Warp Deploy Summary
Last updated: 2026-03-31 19:44:03 UTC |
Deployed QuotedCalls (constructor arg: Permit2 canonical address) on 10 chains for the offchain fee quoting feature. QuotedCalls is a command-based router that atomically submits offchain-signed fee quotes and executes Hyperlane warp transfers.
2a9fe79 to
ff87927
Compare
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…eploy' into yorhodes/add-quoted-calls-addresses # Conflicts: # deployments/warp_routes/warpRouteConfigs.yaml
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
paulbalaji
left a comment
There was a problem hiding this comment.
i dont think you intended to check in all the warp routes
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdded Changes
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Nitpick comments (8)
chains/unichain/addresses.yaml (1)
14-14: Document the address source for traceability.The new
quotedCallsaddress looks good and the alphabetical ordering is spot-on. However, per the coding guidelines, addresses should note their source. Consider adding a comment with the PR number or deployment transaction hash for future reference.📝 Example with source documentation
proxyAdmin: "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0x7C55ef6A28c65f4EDF7d5C46cE82A44E350Fad4B" staticAggregationHookFactory: "0x4ebFf55508394eCd6A76D4a882cff9302487E631"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/unichain/addresses.yaml` at line 14, Add provenance documentation for the new quotedCalls address by appending a comment next to the quotedCalls entry that records the source (e.g., PR number, deployment transaction hash, or other provenance). Update the quotedCalls entry so the address remains unchanged but is followed by a brief comment with the unique identifier of the source (PR#/tx hash) to satisfy the address traceability guideline.chains/avalanche/addresses.yaml (1)
14-14: Document the address source for traceability.The address itself is fine and in the right spot. Would be helpful to add a comment explaining where this came from for anyone reviewing the history later.
📝 Example with source documentation
proxyAdmin: "0xd7CF8c05fd81b8cA7CfF8E6C49B08a9D63265c9B" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0x473E9d1745493cf3281AAEEA8fE1c7147C5dAe07" staticAggregationHookFactory: "0xcae1ed52e7914B4b89c4E49a9d5bdF7425E69252"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/avalanche/addresses.yaml` at line 14, Add provenance documentation for the quotedCalls address "0x473E9d1745493cf3281AAEEA8fE1c7147C5dAe07": update chains/avalanche/addresses.yaml near the quotedCalls entry to include a comment indicating the source (e.g., PR number, transaction hash, block number, or external reference) and any verification steps so future reviewers can trace where the address came from.chains/base/addresses.yaml (1)
18-18: Document the address source for traceability.The address format and positioning are proper, but it'd be better to include a comment noting where this address came from. Makes life easier down the road when someone's wondering about the deployment details.
📝 Example with source documentation
proxyAdmin: "0x4Ed7d626f1E96cD1C0401607Bf70D95243E3dEd1" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0x1D8422eb0F0b88163a4Bd7e83135E59d0D322f07" staticAggregationHookFactory: "0x4f0547800Db0a2427F7367960dc331f8Cbe2e270"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/base/addresses.yaml` at line 18, Add provenance for the quotedCalls address by annotating the quotedCalls entry with a brief comment that documents its source (e.g., PR number, deployment tx hash, contract owner, or repo/commit where it originated). Locate the quotedCalls key in chains/base/addresses.yaml and append a concise comment next to "quotedCalls: 0x1D8422eb0F0b88163a4Bd7e83135E59d0D322f07" that states the exact source and any relevant context for traceability.chains/optimism/addresses.yaml (1)
18-18: Document the address source for traceability.The address looks good and sits right where it should be in the sort order. Just needs a comment documenting the deployment source to match the repository's standards.
📝 Example with source documentation
proxyAdmin: "0xE047cb95FB3b7117989e911c6afb34771183fC35" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0x31169ee5A8C0D680de74461d7B5394fFc7C3576B" staticAggregationHookFactory: "0xb0464AE267dbD8b0c611D7768Cd658d4c39b54d6"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/optimism/addresses.yaml` at line 18, The YAML entry for quotedCalls (value "0x31169ee5A8C0D680de74461d7B5394fFc7C3576B") lacks provenance; update the record by adding a comment next to the quotedCalls entry that documents the deployment/source (e.g., PR number, transaction hash, contract deployment tx or Etherscan link) so the address is traceable and meets repository standards; locate the quotedCalls key in the file and append the brief source note as a YAML comment on the same line or the line above.chains/ink/addresses.yaml (1)
14-14: Document the address source for traceability.Everything's in the right place alphabetically, and the address format checks out. That said, adding a quick comment about where this deployment came from would follow the repository's guidelines.
📝 Example with source documentation
proxyAdmin: "0x3a464f746D23Ab22155710f44dB16dcA53e0775E" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0xE086378F7f0afd5C3ff95E10B5e7806a0901b33f" staticAggregationHookFactory: "0xc67ABC50E7557609077E03e6aeA6834f3E4cf4cE"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/ink/addresses.yaml` at line 14, Add a provenance comment for the quotedCalls address entry so the source is traceable: update the addresses.yaml entry for the key "quotedCalls" to include a comment indicating where the deployment came from (e.g., PR number, transaction hash, or other provenance), e.g., add a trailing comment on the same line or a nearby comment block describing the PR/tx that introduced 0xE086378F7f0afd5C3ff95E10B5e7806a0901b33f so future reviewers can verify origin.chains/ethereum/addresses.yaml (1)
14-14: Document the address source for traceability.Address format and alphabetical placement are both correct. Just needs a comment with the deployment provenance to follow the guidelines.
📝 Example with source documentation
proxyAdmin: "0x75EE15Ee1B4A75Fa3e2fDF5DF3253c25599cc659" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0xc566ae9c0e87a152b9626af7afff0c4428953303" staticAggregationHookFactory: "0x8E0c6231F36cb081ccBcae5810C1793268D6CA7C"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/ethereum/addresses.yaml` at line 14, Add provenance metadata for the new address entry by documenting where the quotedCalls address ("0xc566ae9c0e87a152b9626af7afff0c4428953303") came from (e.g., deployment tx hash, PR number, block number, or other source) next to the quotedCalls entry in chains/ethereum/addresses.yaml so future reviewers can trace it; update the quotedCalls entry to include a brief comment with that provenance (referencing the quotedCalls key and the specific address string) following the repository's guidelines.chains/linea/addresses.yaml (1)
14-14: Document the address source for traceability.The address is properly formatted and positioned correctly in the file. To wrap this up nicely, add a comment documenting the deployment source.
📝 Example with source documentation
proxyAdmin: "0x7f50C5776722630a0024fAE05fDe8b47571D7B39" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0x4eFaacbf0D3d57b401Cb6B559e84b344448b0C30" staticAggregationHookFactory: "0x67eB139588813Eb311C539Ac51C2638f3A318Ba7"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/linea/addresses.yaml` at line 14, Add a provenance comment documenting where the address for quotedCalls came from (e.g., PR number, tx hash, or deployment note) so the source is traceable; locate the quotedCalls entry (symbol "quotedCalls") and insert a concise YAML comment above or beside that line with the deployment/source identifier and date.chains/arbitrum/addresses.yaml (1)
14-14: Document the address source for traceability.The address is valid and properly positioned. To keep things tidy and maintainable, add a comment noting the deployment source.
📝 Example with source documentation
proxyAdmin: "0x80Cebd56A65e46c474a1A101e89E76C4c51D179c" +# Deployed in PR `#1431` with Permit2 constructor arg quotedCalls: "0x3593dc3be3eAc45a886C09D9E47F130687a2B7dd" staticAggregationHookFactory: "0x47113936706B3FfF21a14807A93cc3ab8C76bff8"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@chains/arbitrum/addresses.yaml` at line 14, Add provenance metadata for the quotedCalls address by appending a comment next to the quotedCalls entry that documents its source (e.g., PR number, contract deployment tx hash, or other authoritative reference); update the quotedCalls entry in the same block (symbol: quotedCalls) so the address remains unchanged but is immediately followed by a concise comment containing the provenance information for traceability.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@chains/citrea/addresses.yaml`:
- Line 14: Add provenance for the new quotedCalls entry: locate the quotedCalls
key (value "0xE403ebC56cA50a82CfCBAb53Db29ca3DBF025207") in
chains/citrea/addresses.yaml and record its source (PR number, deployment tx
hash, or other breadcrumb) next to it—either as an inline YAML comment or a
small sibling field (e.g., quotedCalls_provenance or quotedCalls_source) so
future readers can verify where the address came from.
In `@chains/hyperevm/addresses.yaml`:
- Line 14: The YAML entry for the key quotedCalls is missing provenance; update
the addresses.yaml entry for quotedCalls by adding a short provenance comment
(PR number, tx hash, or other source) directly above or beside the quotedCalls
line so future readers can trace where the address came from (e.g., "source: PR
`#1234`" or "tx: 0x...") and ensure the comment format matches other entries in
the file.
In `@chains/monad/addresses.yaml`:
- Line 14: The new quotedCalls address entry lacks provenance metadata; update
the quotedCalls entry to include source information (e.g., PR number, tx hash,
or other provenance) using the repository's existing metadata convention (add a
source/provenance field or comment next to the quotedCalls key), so the entry
for quotedCalls explicitly records where it came from (PR/# or tx hash and
optionally who added it).
In `@deployments/warp_routes/schema.json`:
- Line 37: The schema enum change removed legacy route types and will break many
existing configs; restore the removed enum values (e.g., "EvmHypMultiCollateral"
and "EvmHypCrossCollateralRouter") back into the enum in schema.json or,
alternatively, migrate every config that references them (search for occurrences
in warpRouteConfigs.yaml and individual config files) to the new names before
removing them; update schema.json's enumeration to include both the new and
legacy identifiers until all config files are updated and validated.
In `@deployments/warp_routes/USDT/crosscollateral-deploy.yaml`:
- Around line 29-55: The base chain block is missing the rebalancing
configuration fields; add allowedRebalancers and allowedRebalancingBridges under
the base section to mirror the arbitrum and ethereum blocks so the base chain
can participate in rebalancing; locate the base block (symbol: base under
crossCollateralRouters / type: crossCollateral) and add the same
allowedRebalancers and allowedRebalancingBridges entries (same structure/values
as used in the arbitrum and ethereum blocks) so the deploy YAML matches other
crossCollateral deployments.
In `@deployments/warp_routes/warpRouteConfigs.yaml`:
- Line 4646: Replace the non-conforming route id "MULTI/stableswap" with the
required naming format by changing it to
"MULTI/arbitrum-base-ethereum-hyperevm-mantra"; ensure the ROUTE id follows the
{SYMBOL}/{label} convention (label = chain names joined by hyphens) wherever
"MULTI/stableswap" appears (e.g., the route ID definition for MULTI).
- Line 9378: Replace the route ID "USDC/quoted-calls-demo" with the canonical
naming convention using chain names: change it to
"USDC/arbitrum-avalanche-base-ethereum-ink-linea-optimism-unichain" so the entry
follows the {SYMBOL}/{label} format; update the identifier where
"USDC/quoted-calls-demo" appears in the warpRouteConfigs.yaml so downstream
lookups reference the new route ID consistently.
- Line 5219: Replace the incorrect route ID value 'PYUSD/stableswap' with the
canonical name 'PYUSD/arbitrum-ethereum' in the warp route definitions so it
follows the required {SYMBOL}/{label} naming convention (label = chain names
joined by hyphens); locate the entry that currently contains 'PYUSD/stableswap'
and update it to 'PYUSD/arbitrum-ethereum', then run any lint/validation for
warpRouteConfigs to ensure the format passes checks.
- Line 9616: The route ID value "USDC/stableswap" does not follow the required
naming convention; update the YAML key to "USDC/arbitrum-base-ethereum" so it
follows the {SYMBOL}/{label} pattern (e.g., change the identifier
"USDC/stableswap" to "USDC/arbitrum-base-ethereum" wherever that route ID
appears in the file or related configs).
- Line 11135: The route ID "USDT/stableswap" does not follow the
{SYMBOL}/{label} naming convention; change the YAML key from "USDT/stableswap"
to "USDT/arbitrum-base-ethereum" so the route ID matches the required pattern
(symbol followed by chain label); update any references to the old ID in the
same file (search for "USDT/stableswap") to the new ID to keep consistency.
---
Nitpick comments:
In `@chains/arbitrum/addresses.yaml`:
- Line 14: Add provenance metadata for the quotedCalls address by appending a
comment next to the quotedCalls entry that documents its source (e.g., PR
number, contract deployment tx hash, or other authoritative reference); update
the quotedCalls entry in the same block (symbol: quotedCalls) so the address
remains unchanged but is immediately followed by a concise comment containing
the provenance information for traceability.
In `@chains/avalanche/addresses.yaml`:
- Line 14: Add provenance documentation for the quotedCalls address
"0x473E9d1745493cf3281AAEEA8fE1c7147C5dAe07": update
chains/avalanche/addresses.yaml near the quotedCalls entry to include a comment
indicating the source (e.g., PR number, transaction hash, block number, or
external reference) and any verification steps so future reviewers can trace
where the address came from.
In `@chains/base/addresses.yaml`:
- Line 18: Add provenance for the quotedCalls address by annotating the
quotedCalls entry with a brief comment that documents its source (e.g., PR
number, deployment tx hash, contract owner, or repo/commit where it originated).
Locate the quotedCalls key in chains/base/addresses.yaml and append a concise
comment next to "quotedCalls: 0x1D8422eb0F0b88163a4Bd7e83135E59d0D322f07" that
states the exact source and any relevant context for traceability.
In `@chains/ethereum/addresses.yaml`:
- Line 14: Add provenance metadata for the new address entry by documenting
where the quotedCalls address ("0xc566ae9c0e87a152b9626af7afff0c4428953303")
came from (e.g., deployment tx hash, PR number, block number, or other source)
next to the quotedCalls entry in chains/ethereum/addresses.yaml so future
reviewers can trace it; update the quotedCalls entry to include a brief comment
with that provenance (referencing the quotedCalls key and the specific address
string) following the repository's guidelines.
In `@chains/ink/addresses.yaml`:
- Line 14: Add a provenance comment for the quotedCalls address entry so the
source is traceable: update the addresses.yaml entry for the key "quotedCalls"
to include a comment indicating where the deployment came from (e.g., PR number,
transaction hash, or other provenance), e.g., add a trailing comment on the same
line or a nearby comment block describing the PR/tx that introduced
0xE086378F7f0afd5C3ff95E10B5e7806a0901b33f so future reviewers can verify
origin.
In `@chains/linea/addresses.yaml`:
- Line 14: Add a provenance comment documenting where the address for
quotedCalls came from (e.g., PR number, tx hash, or deployment note) so the
source is traceable; locate the quotedCalls entry (symbol "quotedCalls") and
insert a concise YAML comment above or beside that line with the
deployment/source identifier and date.
In `@chains/optimism/addresses.yaml`:
- Line 18: The YAML entry for quotedCalls (value
"0x31169ee5A8C0D680de74461d7B5394fFc7C3576B") lacks provenance; update the
record by adding a comment next to the quotedCalls entry that documents the
deployment/source (e.g., PR number, transaction hash, contract deployment tx or
Etherscan link) so the address is traceable and meets repository standards;
locate the quotedCalls key in the file and append the brief source note as a
YAML comment on the same line or the line above.
In `@chains/unichain/addresses.yaml`:
- Line 14: Add provenance documentation for the new quotedCalls address by
appending a comment next to the quotedCalls entry that records the source (e.g.,
PR number, deployment transaction hash, or other provenance). Update the
quotedCalls entry so the address remains unchanged but is followed by a brief
comment with the unique identifier of the source (PR#/tx hash) to satisfy the
address traceability guideline.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5911dbbd-5e03-4187-8975-422240f7a5f1
📒 Files selected for processing (41)
chains/addresses.yamlchains/arbitrum/addresses.yamlchains/avalanche/addresses.yamlchains/base/addresses.yamlchains/citrea/addresses.yamlchains/ethereum/addresses.yamlchains/hyperevm/addresses.yamlchains/ink/addresses.yamlchains/linea/addresses.yamlchains/monad/addresses.yamlchains/optimism/addresses.yamlchains/unichain/addresses.yamldeployments/warp_routes/CROSS/crosscollateral-config.yamldeployments/warp_routes/CROSS/ctusd-config.yamldeployments/warp_routes/MULTI/stableswap-config.yamldeployments/warp_routes/PYUSD/crosscollateral-config.yamldeployments/warp_routes/PYUSD/crosscollateral-deploy.yamldeployments/warp_routes/PYUSD/crosscollateral-oft/config.yamldeployments/warp_routes/PYUSD/stableswap-config.yamldeployments/warp_routes/PYUSD/stableswap-deploy.yamldeployments/warp_routes/USDC/crosscollateral-config.yamldeployments/warp_routes/USDC/crosscollateral-deploy.yamldeployments/warp_routes/USDC/ctusd-config.yamldeployments/warp_routes/USDC/ctusd-deploy.yamldeployments/warp_routes/USDC/quoted-calls-demo-config.yamldeployments/warp_routes/USDC/quoted-calls-demo-deploy.yamldeployments/warp_routes/USDC/stableswap-config.yamldeployments/warp_routes/USDC/stableswap-deploy.yamldeployments/warp_routes/USDH/stableswap-config.yamldeployments/warp_routes/USDH/stableswap-deploy.yamldeployments/warp_routes/USDT/crosscollateral-config.yamldeployments/warp_routes/USDT/crosscollateral-deploy.yamldeployments/warp_routes/USDT/crosscollateral-oft/config.yamldeployments/warp_routes/USDT/ctusd-config.yamldeployments/warp_routes/USDT/ctusd-deploy.yamldeployments/warp_routes/USDT/stableswap-config.yamldeployments/warp_routes/USDT/stableswap-deploy.yamldeployments/warp_routes/mantraUSD/stableswap-config.yamldeployments/warp_routes/mantraUSD/stableswap-deploy.yamldeployments/warp_routes/schema.jsondeployments/warp_routes/warpRouteConfigs.yaml
| pausableIsm: "0xA697222b77cDe62A8C47E627d5A1c49A87018236" | ||
| protocolFee: "0xDd08008d2760873E9D4085442B8aED87B93c06Dd" | ||
| proxyAdmin: "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7" | ||
| quotedCalls: "0xE403ebC56cA50a82CfCBAb53Db29ca3DBF025207" |
There was a problem hiding this comment.
Add provenance for the new quotedCalls address.
Line 14 adds a deployed address without a source breadcrumb (PR/tx hash). Let’s leave a trail so future folks can verify where it came from.
🧭 Suggested update
-quotedCalls: "0xE403ebC56cA50a82CfCBAb53Db29ca3DBF025207"
+# source: PR `#1431` (feat: add QuotedCalls contract addresses)
+quotedCalls: "0xE403ebC56cA50a82CfCBAb53Db29ca3DBF025207"As per coding guidelines: "**/chains/*/addresses.yaml: When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| quotedCalls: "0xE403ebC56cA50a82CfCBAb53Db29ca3DBF025207" | |
| # source: PR `#1431` (feat: add QuotedCalls contract addresses) | |
| quotedCalls: "0xE403ebC56cA50a82CfCBAb53Db29ca3DBF025207" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@chains/citrea/addresses.yaml` at line 14, Add provenance for the new
quotedCalls entry: locate the quotedCalls key (value
"0xE403ebC56cA50a82CfCBAb53Db29ca3DBF025207") in chains/citrea/addresses.yaml
and record its source (PR number, deployment tx hash, or other breadcrumb) next
to it—either as an inline YAML comment or a small sibling field (e.g.,
quotedCalls_provenance or quotedCalls_source) so future readers can verify where
the address came from.
| pausableIsm: "0x7927B6fE8FA061c32CE3771d11076E6161DE5f52" | ||
| protocolFee: "0x8d7E604460E1133ebB91513a6D1024f3A3ca17F9" | ||
| proxyAdmin: "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7" | ||
| quotedCalls: "0x7e2cAc751CB4FA5bD78482f91cc2c5aEb194Ee34" |
There was a problem hiding this comment.
Please add source provenance for quotedCalls.
Line 14 is missing a provenance note (PR or tx hash). A tiny comment here saves a lot of archaeology later.
🧭 Suggested update
-quotedCalls: "0x7e2cAc751CB4FA5bD78482f91cc2c5aEb194Ee34"
+# source: PR `#1431` (feat: add QuotedCalls contract addresses)
+quotedCalls: "0x7e2cAc751CB4FA5bD78482f91cc2c5aEb194Ee34"As per coding guidelines: "**/chains/*/addresses.yaml: When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| quotedCalls: "0x7e2cAc751CB4FA5bD78482f91cc2c5aEb194Ee34" | |
| # source: PR `#1431` (feat: add QuotedCalls contract addresses) | |
| quotedCalls: "0x7e2cAc751CB4FA5bD78482f91cc2c5aEb194Ee34" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@chains/hyperevm/addresses.yaml` at line 14, The YAML entry for the key
quotedCalls is missing provenance; update the addresses.yaml entry for
quotedCalls by adding a short provenance comment (PR number, tx hash, or other
source) directly above or beside the quotedCalls line so future readers can
trace where the address came from (e.g., "source: PR `#1234`" or "tx: 0x...") and
ensure the comment format matches other entries in the file.
| pausableIsm: "0xdf4aA3905e0391C7763e33CB6A08fFa97221D49B" | ||
| protocolFee: "0x4A91738390a3D55CB27c2863e8950c9cD1b89d0e" | ||
| proxyAdmin: "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7" | ||
| quotedCalls: "0xad2877D26949b5c98934d4473D0261274628F8bf" |
There was a problem hiding this comment.
Add provenance for the new quotedCalls address.
Nice add, but this new address entry should include source metadata (PR/tx hash) for traceability.
💡 Suggested patch
+# source: PR `#1431` (QuotedCalls deployment)
quotedCalls: "0xad2877D26949b5c98934d4473D0261274628F8bf"As per coding guidelines: "When adding or changing addresses, note the source (PR, tx hash, or other provenance information)".
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| quotedCalls: "0xad2877D26949b5c98934d4473D0261274628F8bf" | |
| # source: PR `#1431` (QuotedCalls deployment) | |
| quotedCalls: "0xad2877D26949b5c98934d4473D0261274628F8bf" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@chains/monad/addresses.yaml` at line 14, The new quotedCalls address entry
lacks provenance metadata; update the quotedCalls entry to include source
information (e.g., PR number, tx hash, or other provenance) using the
repository's existing metadata convention (add a source/provenance field or
comment next to the quotedCalls key), so the entry for quotedCalls explicitly
records where it came from (PR/# or tx hash and optionally who added it).
| "EvmHypEverclearCollateral", | ||
| "EvmHypEverclearEth", | ||
| "EvmHypMultiCollateral", | ||
| "EvmHypCrossCollateralRouter", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== standards still used in warp route configs ==="
rg -n --type=yaml '\bstandard:\s*(EvmHypMultiCollateral|TronHypMultiCollateral|EvmHypCrossCollateralRouter|TronHypCrossCollateralRouter)\b' deployments/warp_routes
echo
echo "=== schema enum values ==="
python - <<'PY'
import json
from pathlib import Path
p = Path("deployments/warp_routes/schema.json")
enum = json.loads(p.read_text())["definitions"]["hyperlaneWarpCoreConfig"]["properties"]["tokens"]["items"]["properties"]["standard"]["enum"]
for v in enum:
if "Collateral" in v or "Router" in v:
print(v)
PYRepository: hyperlane-xyz/hyperlane-registry
Length of output: 6936
Schema migration's gonna cause validation chaos unless the old standards are kept around.
Heads up: there are bunch of configs still using EvmHypMultiCollateral (21+ places in warpRouteConfigs.yaml alone, plus several in individual config files), and it's not in the schema enum anymore. Same deal with EvmHypCrossCollateralRouter—loads of configs use it but it's gotta stay in the enum. Either migrate all those configs alongside this change, or keep the legacy standards in the schema until they're updated.
💡 Backward-compatible way
"EvmHypEverclearCollateral",
"EvmHypEverclearEth",
+ "EvmHypMultiCollateral",
"EvmHypCrossCollateralRouter",
@@
"TronHypEverclearCollateral",
"TronHypEverclearEth",
+ "TronHypMultiCollateral",
"TronHypCrossCollateralRouter"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/schema.json` at line 37, The schema enum change
removed legacy route types and will break many existing configs; restore the
removed enum values (e.g., "EvmHypMultiCollateral" and
"EvmHypCrossCollateralRouter") back into the enum in schema.json or,
alternatively, migrate every config that references them (search for occurrences
in warpRouteConfigs.yaml and individual config files) to the new names before
removing them; update schema.json's enumeration to include both the new and
legacy identifiers until all config files are updated and validated.
| base: | ||
| crossCollateralRouters: | ||
| "1": | ||
| - "0x0000000000000000000000000501f39976d53067915c8c84bfba35a287eaa7bd" | ||
| - "0x000000000000000000000000b6a23ffd07b493a051831092faa83f31ca9f98e7" | ||
| "42161": | ||
| - "0x00000000000000000000000043402d998c0f3331b1afee4f5c7966facab1db1e" | ||
| - "0x00000000000000000000000084eadce7c08788b041351bbac9781d8e820ea96a" | ||
| "8453": | ||
| - "0x000000000000000000000000afd0995c7edca913599d5731d022f5f39bd11f8a" | ||
| mailbox: "0xeA87ae93Fa0019a82A727bfd3eBd1cFCa8f64f1D" | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| scale: 1000000000000 | ||
| token: "0xfde4C96c8593536E31F229EA8f37b2ADa2699bb2" | ||
| tokenFee: | ||
| feeContracts: | ||
| arbitrum: | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: LinearFee | ||
| ethereum: | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: LinearFee | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: RoutingFee | ||
| type: crossCollateral |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if other USDT or similar deploy files have consistent allowedRebalancers patterns
echo "=== Checking allowedRebalancers patterns in other deploy files ==="
rg -l "allowedRebalancers" --glob "deployments/warp_routes/**/*-deploy.yaml" | head -10
echo ""
echo "=== Checking base chain blocks in similar deploy files ==="
rg -B2 -A10 "^base:" --glob "deployments/warp_routes/**/*-deploy.yaml"Repository: hyperlane-xyz/hyperlane-registry
Length of output: 50388
🏁 Script executed:
cd deployments/warp_routes/USDT && wc -l crosscollateral-deploy.yaml && cat -n crosscollateral-deploy.yamlRepository: hyperlane-xyz/hyperlane-registry
Length of output: 3949
🏁 Script executed:
# Quick check: compare similar crossCollateral deployments to confirm pattern
rg -A2 "^base:" deployments/warp_routes/USDC/crosscollateral-deploy.yaml | head -20Repository: hyperlane-xyz/hyperlane-registry
Length of output: 154
Add allowedRebalancers and allowedRebalancingBridges to the base chain block.
The base chain is missin' the rebalancing configuration that both arbitrum and ethereum have. Similar crossCollateral deployments like USDC include these fields across all chains. Without 'em, the base chain won't be able to participate in rebalancing operations.
Reckon you'll want to add both allowedRebalancers and allowedRebalancingBridges to match the pattern in arbitrum and ethereum blocks.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/USDT/crosscollateral-deploy.yaml` around lines 29 -
55, The base chain block is missing the rebalancing configuration fields; add
allowedRebalancers and allowedRebalancingBridges under the base section to
mirror the arbitrum and ethereum blocks so the base chain can participate in
rebalancing; locate the base block (symbol: base under crossCollateralRouters /
type: crossCollateral) and add the same allowedRebalancers and
allowedRebalancingBridges entries (same structure/values as used in the arbitrum
and ethereum blocks) so the deploy YAML matches other crossCollateral
deployments.
| name: Money | ||
| standard: SealevelHypCollateral | ||
| symbol: MONEY | ||
| MULTI/stableswap: |
There was a problem hiding this comment.
Route ID doesn't follow the naming convention.
The route ID MULTI/stableswap should use chain names joined by hyphens instead of a descriptive label. Based on the chains involved (arbitrum, base, ethereum, hyperevm, mantra), it should be MULTI/arbitrum-base-ethereum-hyperevm-mantra.
As per coding guidelines, warp route IDs must follow format: {SYMBOL}/{label} where label is typically chain names joined by hyphens.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/warpRouteConfigs.yaml` at line 4646, Replace the
non-conforming route id "MULTI/stableswap" with the required naming format by
changing it to "MULTI/arbitrum-base-ethereum-hyperevm-mantra"; ensure the ROUTE
id follows the {SYMBOL}/{label} convention (label = chain names joined by
hyphens) wherever "MULTI/stableswap" appears (e.g., the route ID definition for
MULTI).
| name: Pump | ||
| standard: StarknetHypSynthetic | ||
| symbol: PUMP | ||
| PYUSD/stableswap: |
There was a problem hiding this comment.
Route ID doesn't follow the naming convention.
The route ID PYUSD/stableswap should be PYUSD/arbitrum-ethereum to properly reflect the chains involved.
As per coding guidelines, warp route IDs must follow format: {SYMBOL}/{label} where label is typically chain names joined by hyphens.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/warpRouteConfigs.yaml` at line 5219, Replace the
incorrect route ID value 'PYUSD/stableswap' with the canonical name
'PYUSD/arbitrum-ethereum' in the warp route definitions so it follows the
required {SYMBOL}/{label} naming convention (label = chain names joined by
hyphens); locate the entry that currently contains 'PYUSD/stableswap' and update
it to 'PYUSD/arbitrum-ethereum', then run any lint/validation for
warpRouteConfigs to ensure the format passes checks.
| name: USDC | ||
| standard: EvmHypCollateral | ||
| symbol: USDC | ||
| USDC/quoted-calls-demo: |
There was a problem hiding this comment.
Route ID doesn't follow the naming convention.
Look, I get that quoted-calls-demo describes what this route's for, but the route ID should still use the actual chain names. It should be USDC/arbitrum-avalanche-base-ethereum-ink-linea-optimism-unichain.
As per coding guidelines, warp route IDs must follow format: {SYMBOL}/{label} where label is typically chain names joined by hyphens.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/warpRouteConfigs.yaml` at line 9378, Replace the
route ID "USDC/quoted-calls-demo" with the canonical naming convention using
chain names: change it to
"USDC/arbitrum-avalanche-base-ethereum-ink-linea-optimism-unichain" so the entry
follows the {SYMBOL}/{label} format; update the identifier where
"USDC/quoted-calls-demo" appears in the warpRouteConfigs.yaml so downstream
lookups reference the new route ID consistently.
| name: USDC | ||
| standard: SealevelHypSynthetic | ||
| symbol: USDC | ||
| USDC/stableswap: |
There was a problem hiding this comment.
Route ID doesn't follow the naming convention.
The route ID USDC/stableswap should be USDC/arbitrum-base-ethereum.
As per coding guidelines, warp route IDs must follow format: {SYMBOL}/{label} where label is typically chain names joined by hyphens.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/warpRouteConfigs.yaml` at line 9616, The route ID
value "USDC/stableswap" does not follow the required naming convention; update
the YAML key to "USDC/arbitrum-base-ethereum" so it follows the {SYMBOL}/{label}
pattern (e.g., change the identifier "USDC/stableswap" to
"USDC/arbitrum-base-ethereum" wherever that route ID appears in the file or
related configs).
| name: USDT | ||
| standard: SealevelHypSynthetic | ||
| symbol: USDT | ||
| USDT/stableswap: |
There was a problem hiding this comment.
Route ID doesn't follow the naming convention.
The route ID USDT/stableswap should be USDT/arbitrum-base-ethereum.
As per coding guidelines, warp route IDs must follow format: {SYMBOL}/{label} where label is typically chain names joined by hyphens.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/warpRouteConfigs.yaml` at line 11135, The route ID
"USDT/stableswap" does not follow the {SYMBOL}/{label} naming convention; change
the YAML key from "USDT/stableswap" to "USDT/arbitrum-base-ethereum" so the
route ID matches the required pattern (symbol followed by chain label); update
any references to the old ID in the same file (search for "USDT/stableswap") to
the new ID to keep consistency.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
deployments/warp_routes/USDT/ctusd-deploy.yaml (1)
1-85: Please confirmcontractVersionomission is intentional for both chains.No blocker, but since this is a deploy file, leaving out
contractVersionmeans these chains will take the latest contract version. It’d be good to explicitly confirm that intent in the PR notes so nobody gets surprised later.#!/bin/bash # Verify how contractVersion is handled in warp route deploy files # (read-only reconnaissance) set -euo pipefail echo "== Files matching *-deploy.yaml under deployments/warp_routes ==" fd -a '.*-deploy\.ya?ml$' deployments/warp_routes echo echo "== crossCollateral deploy files and contractVersion presence (with context) ==" rg -n -C2 --type=yaml 'type:\s*crossCollateral|contractVersion:' deployments/warp_routes echo echo "== This file quick check ==" rg -n -C2 'contractVersion|type:\s*crossCollateral' deployments/warp_routes/USDT/ctusd-deploy.yamlBased on learnings: In Hyperlane warp route deployment YAML files, omitting
contractVersionmeans using the latest version and should be intentional/documented.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/warp_routes/USDT/ctusd-deploy.yaml` around lines 1 - 85, The deploy YAML omits the contractVersion for both top-level routes (arbitrum and base) so they'll default to the latest; confirm this is intentional and either add an explicit contractVersion field under the arbitrum and base objects or state in the PR notes that omitting contractVersion is deliberate for these crossCollateral routes (reference keys: "arbitrum", "base", and "contractVersion", and the "type: crossCollateral" entries) so reviewers know no accidental implicit-versioning will occur.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deployments/warp_routes/USDC/ctusd-deploy.yaml`:
- Around line 1-164: The diff shows that each chain config (arbitrum, base,
citrea, ethereum) intentionally omits the contractVersion field to allow each
deployment to track the latest contract; update the PR description to explicitly
state that contractVersion is intentionally left out for all these tokens (e.g.,
token entries like token: "0xaf88..." and token: "0xA0b8...") so reviewers know
versioning is delegated to automatic/latest tracking and not an accidental
omission.
---
Nitpick comments:
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml`:
- Around line 1-85: The deploy YAML omits the contractVersion for both top-level
routes (arbitrum and base) so they'll default to the latest; confirm this is
intentional and either add an explicit contractVersion field under the arbitrum
and base objects or state in the PR notes that omitting contractVersion is
deliberate for these crossCollateral routes (reference keys: "arbitrum", "base",
and "contractVersion", and the "type: crossCollateral" entries) so reviewers
know no accidental implicit-versioning will occur.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 25ff6e25-d242-4f4b-bc0c-a01a176bfd5b
📒 Files selected for processing (2)
deployments/warp_routes/USDC/ctusd-deploy.yamldeployments/warp_routes/USDT/ctusd-deploy.yaml
| arbitrum: | ||
| allowedRebalancers: | ||
| - "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| - "0xa3948a15e1d0778a7d53268b651B2411AF198FE3" | ||
| - "0x3e0a78a330f2b97059a4d507ca9d8292b65b6fb5" | ||
| crossCollateralRouters: | ||
| "42161": | ||
| - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" | ||
| "8453": | ||
| - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf" | ||
| mailbox: "0x979Ca5202784112f4738403dBec5D0F3B9daabB9" | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| token: "0xaf88d065e77c8cC2239327C5EDb3A432268e5831" | ||
| tokenFee: | ||
| feeContracts: | ||
| base: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| citrea: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| ethereum: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: CrossCollateralRoutingFee | ||
| type: crossCollateral | ||
| base: | ||
| allowedRebalancers: | ||
| - "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| - "0xa3948a15e1d0778a7d53268b651B2411AF198FE3" | ||
| allowedRebalancingBridges: | ||
| "4114": | ||
| - bridge: "0x1c9DA8e9077323B5bb0Af96b94092992B59cE175" # slow | ||
| crossCollateralRouters: | ||
| "42161": | ||
| - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" | ||
| "8453": | ||
| - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf" | ||
| mailbox: "0xeA87ae93Fa0019a82A727bfd3eBd1cFCa8f64f1D" | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| token: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" | ||
| tokenFee: | ||
| feeContracts: | ||
| arbitrum: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| citrea: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| ethereum: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: CrossCollateralRoutingFee | ||
| type: crossCollateral | ||
| citrea: | ||
| allowedRebalancers: | ||
| - "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| - "0xa3948a15e1d0778a7d53268b651B2411AF198FE3" | ||
| allowedRebalancingBridges: | ||
| "1": | ||
| - bridge: "0xeBEB7F52892dF3066885F4D31137a76327f6348b" | ||
| "8453": | ||
| - bridge: "0x1a559f3D0753A07BB1dc597E4c2b4C7723CB27F4" # slow | ||
| crossCollateralRouters: | ||
| "42161": | ||
| - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" | ||
| "8453": | ||
| - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf" | ||
| mailbox: "0x3a464f746D23Ab22155710f44dB16dcA53e0775E" | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| token: "0x8D82c4E3c936C7B5724A382a9c5a4E6Eb7aB6d5D" | ||
| tokenFee: | ||
| feeContracts: | ||
| arbitrum: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| base: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| ethereum: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: CrossCollateralRoutingFee | ||
| type: crossCollateral | ||
| ethereum: | ||
| allowedRebalancers: | ||
| - "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| - "0xa3948a15e1d0778a7d53268b651B2411AF198FE3" | ||
| allowedRebalancingBridges: | ||
| "4114": | ||
| - bridge: "0x6372e1C8a08940C7e95AF2891B9201aC48De6519" | ||
| crossCollateralRouters: | ||
| "42161": | ||
| - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" | ||
| "8453": | ||
| - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf" | ||
| mailbox: "0xc005dc82818d67AF737725bD4bf75435d065D239" | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| token: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" | ||
| tokenFee: | ||
| feeContracts: | ||
| arbitrum: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| base: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| citrea: | ||
| "0x6e086cd647d6eb8b516856666e2c1465fb8a6a58d3a75938362acc674eacaf47": | ||
| bps: 3 | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| quoteSigners: | ||
| - "0xEd1829805De615eEFC7303766D395Ea0a1B2b04d" | ||
| type: OffchainQuotedLinearFee | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: CrossCollateralRoutingFee | ||
| type: crossCollateral |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify how contractVersion is used across USDC deploy files.
# Expected: either consistent intentional omission, or explicit values where pinning is required.
set -euo pipefail
echo "Scanning USDC warp deploy files for contractVersion usage..."
fd '.*-deploy\.yaml$' deployments/warp_routes/USDC -x sh -c '
f="$1"
echo "== $f =="
rg -n "^[[:space:]]*contractVersion:" "$f" || echo "(no contractVersion key)"
' sh {}
echo
echo "Showing this file header/context for documentation clues..."
rg -n "contractVersion|version|latest|intentional|note" deployments/warp_routes/USDC/ctusd-deploy.yaml -C 2 || trueRepository: hyperlane-xyz/hyperlane-registry
Length of output: 4405
All chains intentionally use the latest contract version—just make sure to note that in the PR description.
Every chain in this file skips the contractVersion field, which is the intended behavior when you want each one tracking the latest version. (Other USDC deploy files do the same, so this is consistent with the pattern.) Just add a quick note in the PR to make it crystal clear that version tracking is being left to auto-update—saves everyone from wondering down the road why versions drift differently than expected.
🧰 Tools
🪛 Betterleaks (1.1.1)
[high] 13-13: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 54-54: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 97-97: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
[high] 138-138: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/USDC/ctusd-deploy.yaml` around lines 1 - 164, The
diff shows that each chain config (arbitrum, base, citrea, ethereum)
intentionally omits the contractVersion field to allow each deployment to track
the latest contract; update the PR description to explicitly state that
contractVersion is intentionally left out for all these tokens (e.g., token
entries like token: "0xaf88..." and token: "0xA0b8...") so reviewers know
versioning is delegated to automatic/latest tracking and not an accidental
omission.
There was a problem hiding this comment.
🧹 Nitpick comments (2)
deployments/warp_routes/USDT/ctusd-deploy.yaml (1)
1-91: Add address provenance notes for future traceabilityNice clean structure, but with this many fresh addresses, it’ll be easier to audit later if we include provenance (deploy tx hash or source reference) near the entries or in a companion note. Keeps folks from peeling the whole onion next time they need to verify a route fast.
Based on learnings: "When adding or changing contract addresses, note the source (PR, tx hash) for address provenance".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/warp_routes/USDT/ctusd-deploy.yaml` around lines 1 - 91, Add provenance metadata for newly added addresses (e.g., entries under arbitrum.allowedRebalancers, base.allowedRebalancers, crossCollateralRouters, mailbox, owner, token, and tokenFee.feeContracts keys) by adding a brief source field or companion comment/note that records the deploy transaction hash or PR/source reference for each address; update each block where fresh addresses appear (allowedRebalancers arrays, crossCollateralRouters mappings, mailbox/owner/token values, and feeContracts keys) to include a provenance note (or add a separate provenance section mapping those unique identifiers to tx hashes/PR IDs) so future auditors can quickly trace each address back to its origin.deployments/warp_routes/USDC/ctusd-deploy.yaml (1)
6-13: SortcrossCollateralRouterskeys alphabetically, aye?Look, I know it's a wee bit picky, but the coding guidelines say YAML keys should be sorted alphabetically. Right now these chain ID strings are ordered as
"42161","8453","1399811149", but string-wise they should go"1399811149","42161","8453"(since'1' < '4' < '8').Same thing happens in the base, citrea, and ethereum sections too. Not the end of the world, but keeping things tidy makes the swamp easier to navigate later.
♻️ Proposed fix for arbitrum section
crossCollateralRouters: + "1399811149": + - "0x3f1376c74e0409c7d9b7a25cc7b05c9739a04082986a21665a6128ef281cdb84" + - "0xfc0f72cda5fa979e0eee3aa711b3e52425c3516a245ea0eb9d1d46548df4b21b" "42161": - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" "8453": - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf" - "1399811149": - - "0x3f1376c74e0409c7d9b7a25cc7b05c9739a04082986a21665a6128ef281cdb84" - - "0xfc0f72cda5fa979e0eee3aa711b3e52425c3516a245ea0eb9d1d46548df4b21b"Apply the same reordering to
base(lines 50-57),citrea(lines 96-103), andethereum(lines 140-147). As per coding guidelines: "YAML files must have keys sorted alphabetically".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/warp_routes/USDC/ctusd-deploy.yaml` around lines 6 - 13, Reorder the string keys under crossCollateralRouters so they are alphabetically sorted (string order), e.g., change the current order ("42161","8453","1399811149") to ("1399811149","42161","8453"); apply the same alphabetical key sorting to the other crossCollateralRouters blocks in the file for the base, citrea, and ethereum sections so each mapping's keys are in string-alphabetical order.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@deployments/warp_routes/USDC/ctusd-deploy.yaml`:
- Around line 6-13: Reorder the string keys under crossCollateralRouters so they
are alphabetically sorted (string order), e.g., change the current order
("42161","8453","1399811149") to ("1399811149","42161","8453"); apply the same
alphabetical key sorting to the other crossCollateralRouters blocks in the file
for the base, citrea, and ethereum sections so each mapping's keys are in
string-alphabetical order.
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml`:
- Around line 1-91: Add provenance metadata for newly added addresses (e.g.,
entries under arbitrum.allowedRebalancers, base.allowedRebalancers,
crossCollateralRouters, mailbox, owner, token, and tokenFee.feeContracts keys)
by adding a brief source field or companion comment/note that records the deploy
transaction hash or PR/source reference for each address; update each block
where fresh addresses appear (allowedRebalancers arrays, crossCollateralRouters
mappings, mailbox/owner/token values, and feeContracts keys) to include a
provenance note (or add a separate provenance section mapping those unique
identifiers to tx hashes/PR IDs) so future auditors can quickly trace each
address back to its origin.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7dab1343-f2eb-4786-b1fd-e51d83455c25
📒 Files selected for processing (2)
deployments/warp_routes/USDC/ctusd-deploy.yamldeployments/warp_routes/USDT/ctusd-deploy.yaml
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
deployments/warp_routes/USDC/ctusd-deploy.yaml (1)
1-204: Add address provenance note for auditability.This file introduces a lot of new on-chain addresses; please add provenance (source PR/tx hash) in the PR description or adjacent docs so future audits can trace each one cleanly.
Based on learnings "When adding or changing contract addresses, note the source (PR, tx hash) for address provenance".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/warp_routes/USDC/ctusd-deploy.yaml` around lines 1 - 204, This change adds many on-chain addresses (e.g. keys under allowedRebalancers, allowedRebalancingBridges, crossCollateralRouters, and token/mailbox entries such as arbitrum.token, base.token, citrea.token, ethereum.token and the tokenFee.feeContracts addresses); add provenance for each address by listing the source PR/transaction hash and short justification either in the PR description and a linked audit document or as an adjacent doc (e.g. a metadata YAML/README) that references these exact keys (allowedRebalancers, allowedRebalancingBridges, crossCollateralRouters, mailbox, token, and each tokenFee.feeContracts entry) so auditors can trace every address back to its origin.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deployments/warp_routes/USDC/ctusd-deploy.yaml`:
- Around line 7-13: The crossCollateralRouters map in the YAML has keys out of
alphabetical order (e.g., the entries with keys "42161", "8453", "1399811149");
reorder the keys within each crossCollateralRouters block so they are sorted
lexicographically (alphabetically) — update the block containing those keys and
also the other crossCollateralRouters blocks referenced (lines 58-64, 111-117,
162-168) to ensure every crossCollateralRouters mapping has its keys in
alphabetical order.
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml`:
- Around line 7-15: The YAML mapping for crossCollateralRouters contains
unsorted numeric-string keys (e.g., "1", "4114", "42161", "8453", "1399811149")
in both chain blocks; reorder these keys alphabetically (lexicographically as
strings) so the entries under crossCollateralRouters are sorted (for example "1"
comes before "4114", etc.) and ensure you perform the same alphabetical sort for
the other block at the later occurrence (lines referenced around the second
block). Update the key ordering only—preserve the associated address values and
indentation/formatting.
---
Nitpick comments:
In `@deployments/warp_routes/USDC/ctusd-deploy.yaml`:
- Around line 1-204: This change adds many on-chain addresses (e.g. keys under
allowedRebalancers, allowedRebalancingBridges, crossCollateralRouters, and
token/mailbox entries such as arbitrum.token, base.token, citrea.token,
ethereum.token and the tokenFee.feeContracts addresses); add provenance for each
address by listing the source PR/transaction hash and short justification either
in the PR description and a linked audit document or as an adjacent doc (e.g. a
metadata YAML/README) that references these exact keys (allowedRebalancers,
allowedRebalancingBridges, crossCollateralRouters, mailbox, token, and each
tokenFee.feeContracts entry) so auditors can trace every address back to its
origin.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b4b6faad-1c8d-4fba-bacd-c4a44b6a39ed
📒 Files selected for processing (2)
deployments/warp_routes/USDC/ctusd-deploy.yamldeployments/warp_routes/USDT/ctusd-deploy.yaml
| "42161": | ||
| - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" | ||
| "8453": | ||
| - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf" | ||
| "1399811149": | ||
| - "0x3f1376c74e0409c7d9b7a25cc7b05c9739a04082986a21665a6128ef281cdb84" | ||
| - "0xfc0f72cda5fa979e0eee3aa711b3e52425c3516a245ea0eb9d1d46548df4b21b" |
There was a problem hiding this comment.
Sort crossCollateralRouters keys alphabetically.
Quick heads-up: these maps are not in alphabetical key order (for example, Line 7-13). That violates the repo YAML ordering rule and can trip deterministic formatting checks.
♻️ Suggested reorder pattern (apply to each `crossCollateralRouters` block)
crossCollateralRouters:
- "42161":
- - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15"
- "8453":
- - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf"
"1399811149":
- "0x3f1376c74e0409c7d9b7a25cc7b05c9739a04082986a21665a6128ef281cdb84"
- "0xfc0f72cda5fa979e0eee3aa711b3e52425c3516a245ea0eb9d1d46548df4b21b"
+ "42161":
+ - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15"
+ "8453":
+ - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf"As per coding guidelines "**/*.{yaml,yml}: YAML files must have keys sorted alphabetically" and "**/*.yaml: YAML files must have keys sorted alphabetically".
Also applies to: 58-64, 111-117, 162-168
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/USDC/ctusd-deploy.yaml` around lines 7 - 13, The
crossCollateralRouters map in the YAML has keys out of alphabetical order (e.g.,
the entries with keys "42161", "8453", "1399811149"); reorder the keys within
each crossCollateralRouters block so they are sorted lexicographically
(alphabetically) — update the block containing those keys and also the other
crossCollateralRouters blocks referenced (lines 58-64, 111-117, 162-168) to
ensure every crossCollateralRouters mapping has its keys in alphabetical order.
| "1": | ||
| - "0x000000000000000000000000d4463cb3c90b3f49c673310bec9bc18311134b47" | ||
| "4114": | ||
| - "0x00000000000000000000000038e8720ebe02e7c5254f9de9f81440c7a770a9c6" | ||
| "42161": | ||
| - "0x00000000000000000000000062fe676dff1e7abbccbedc8babc993827b9fb189" | ||
| "8453": | ||
| - "0x000000000000000000000000d54a15f8df8c6dd9ef3b5589be0bf37ec6f61f91" | ||
| "1399811149": |
There was a problem hiding this comment.
Sort crossCollateralRouters keys alphabetically in both chain blocks.
At Line 7-15 and Line 59-67, the numeric-string keys are not alphabetically ordered. Please reorder to satisfy the repository YAML ordering rule.
♻️ Suggested order
crossCollateralRouters:
"1":
- "..."
+ "1399811149":
+ - "..."
+ - "..."
"4114":
- "..."
"42161":
- "..."
"8453":
- "..."
- "1399811149":
- - "..."
- - "..."As per coding guidelines "**/*.{yaml,yml}: YAML files must have keys sorted alphabetically" and "**/*.yaml: YAML files must have keys sorted alphabetically".
Also applies to: 59-67
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml` around lines 7 - 15, The YAML
mapping for crossCollateralRouters contains unsorted numeric-string keys (e.g.,
"1", "4114", "42161", "8453", "1399811149") in both chain blocks; reorder these
keys alphabetically (lexicographically as strings) so the entries under
crossCollateralRouters are sorted (for example "1" comes before "4114", etc.)
and ensure you perform the same alphabetical sort for the other block at the
later occurrence (lines referenced around the second block). Update the key
ordering only—preserve the associated address values and indentation/formatting.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
deployments/warp_routes/USDC/ctusd-deploy.yaml (1)
6-13:⚠️ Potential issue | 🟠 Major
crossCollateralRouterskey order is still outta line with repo YAML sorting rules.Line 6, Line 74, Line 145, and Line 216 use
"42161","8453","1399811149"; lexicographic order should place"1399811149"first. Same issue repeats in all four chain blocks.♻️ Suggested reorder (apply to each
crossCollateralRoutersblock)crossCollateralRouters: - "42161": - - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" - "8453": - - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf" "1399811149": - "0x3f1376c74e0409c7d9b7a25cc7b05c9739a04082986a21665a6128ef281cdb84" - "0xfc0f72cda5fa979e0eee3aa711b3e52425c3516a245ea0eb9d1d46548df4b21b" + "42161": + - "0x000000000000000000000000824353938ee1361265097acc9e329828e3455c15" + "8453": + - "0x000000000000000000000000a9a434f0abce2f3e7073752046545530e32de6cf"As per coding guidelines "
**/*.{yaml,yml}: YAML files must have keys sorted alphabetically" and "**/*.yaml: YAML files must have keys sorted alphabetically".Also applies to: 74-81, 145-152, 216-223
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/warp_routes/USDC/ctusd-deploy.yaml` around lines 6 - 13, Reorder the keys under each crossCollateralRouters mapping so they follow lexical (alphabetical) order; specifically move the "1399811149" entry before "42161" and "8453" in every crossCollateralRouters block (the blocks containing keys "42161", "8453", "1399811149"), ensuring the same fix is applied at all occurrences (the blocks starting at the three repeated locations), so the YAML keys conform to the repo rule that YAML keys are sorted alphabetically.deployments/warp_routes/USDT/ctusd-deploy.yaml (1)
6-17:⚠️ Potential issue | 🟠 MajorSort
crossCollateralRouterskeys lexicographically in both blocks.Quick fix needed: Line 7 and Line 79 mappings are out of alphabetical order (
"1399811149"is currently after"8453"). That breaks the repo’s YAML ordering rule.♻️ Suggested reorder
crossCollateralRouters: "1": - "0x000000000000000000000000d4463cb3c90b3f49c673310bec9bc18311134b47" + "1399811149": + - "0x3f1376c74e0409c7d9b7a25cc7b05c9739a04082986a21665a6128ef281cdb84" + - "0xfc0f72cda5fa979e0eee3aa711b3e52425c3516a245ea0eb9d1d46548df4b21b" "4114": - "0x00000000000000000000000038e8720ebe02e7c5254f9de9f81440c7a770a9c6" "42161": - "0x00000000000000000000000062fe676dff1e7abbccbedc8babc993827b9fb189" "8453": - "0x000000000000000000000000d54a15f8df8c6dd9ef3b5589be0bf37ec6f61f91" - "1399811149": - - "0x3f1376c74e0409c7d9b7a25cc7b05c9739a04082986a21665a6128ef281cdb84" - - "0xfc0f72cda5fa979e0eee3aa711b3e52425c3516a245ea0eb9d1d46548df4b21b"As per coding guidelines "
**/*.{yaml,yml}: YAML files must have keys sorted alphabetically" and "**/*.yaml: YAML files must have keys sorted alphabetically".Also applies to: 78-89
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/warp_routes/USDT/ctusd-deploy.yaml` around lines 6 - 17, The crossCollateralRouters mapping has keys out of lexicographic order (notably the "1399811149" entry placed after "8453"); reorder the keys in the crossCollateralRouters blocks so all keys (e.g., "1", "4114", "42161", "8453", "1399811149") are sorted lexicographically in both occurrences of crossCollateralRouters to satisfy the YAML key-sorting rule.
🧹 Nitpick comments (2)
deployments/warp_routes/USDC/ctusd-deploy.yaml (1)
1-259: Please add provenance for new onchain addresses (PR note or inline deploy reference).This file introduces a lotta fresh addresses; adding deployment source (tx hash / explorer link / script ref) makes audits and future rotations much easier to track.
Based on learnings "When adding or changing contract addresses, note the source (PR, tx hash) for address provenance".
deployments/warp_routes/USDT/ctusd-deploy.yaml (1)
1-145: Add provenance for newly introduced addresses (tx hash or deploy artifact link).There are many new contract addresses here; adding a short provenance note makes future audits and incident response a lot less swampy.
Based on learnings "When adding or changing contract addresses, note the source (PR, tx hash) for address provenance".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@deployments/warp_routes/USDT/ctusd-deploy.yaml` around lines 1 - 145, This file adds many new on-chain addresses (e.g., arbitrum.allowedRebalancers, arbitrum.crossCollateralRouters, arbitrum.mailbox, arbitrum.token, arbitrum.tokenFee.feeContracts, base.allowedRebalancers, base.crossCollateralRouters, base.mailbox, base.token) without provenance; add a provenance note for each newly introduced address by including the deploying transaction hash or a deploy artifact/PR link (either as an adjacent “provenance” field under each address block or a top-level provenance map keyed by the same identifiers) so auditors can trace each address back to its deployment artifact or tx.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml`:
- Around line 20-35: Reorder the nested YAML mappings for the ethereum domain
block so all mapping keys are alphabetized (e.g., ensure the ethereum mapping
contains keys in alphabetical order such as lowerIsm, threshold, type, upperIsm
as applicable) and apply the same alphabetical sorting inside lowerIsm/upperIsm
and each modules entry (sort keys within module maps like relayer, type, owner,
domains alphabetically). Locate the ethereum block and the paired block
referenced (the second domain block with the same structure) and reorder their
nested keys and module-entry maps to follow the repository guideline that all
YAML mappings must be sorted alphabetically.
---
Duplicate comments:
In `@deployments/warp_routes/USDC/ctusd-deploy.yaml`:
- Around line 6-13: Reorder the keys under each crossCollateralRouters mapping
so they follow lexical (alphabetical) order; specifically move the "1399811149"
entry before "42161" and "8453" in every crossCollateralRouters block (the
blocks containing keys "42161", "8453", "1399811149"), ensuring the same fix is
applied at all occurrences (the blocks starting at the three repeated
locations), so the YAML keys conform to the repo rule that YAML keys are sorted
alphabetically.
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml`:
- Around line 6-17: The crossCollateralRouters mapping has keys out of
lexicographic order (notably the "1399811149" entry placed after "8453");
reorder the keys in the crossCollateralRouters blocks so all keys (e.g., "1",
"4114", "42161", "8453", "1399811149") are sorted lexicographically in both
occurrences of crossCollateralRouters to satisfy the YAML key-sorting rule.
---
Nitpick comments:
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml`:
- Around line 1-145: This file adds many new on-chain addresses (e.g.,
arbitrum.allowedRebalancers, arbitrum.crossCollateralRouters, arbitrum.mailbox,
arbitrum.token, arbitrum.tokenFee.feeContracts, base.allowedRebalancers,
base.crossCollateralRouters, base.mailbox, base.token) without provenance; add a
provenance note for each newly introduced address by including the deploying
transaction hash or a deploy artifact/PR link (either as an adjacent
“provenance” field under each address block or a top-level provenance map keyed
by the same identifiers) so auditors can trace each address back to its
deployment artifact or tx.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d33ae1c5-6bf5-4ba2-953b-23ae9c40a21d
📒 Files selected for processing (2)
deployments/warp_routes/USDC/ctusd-deploy.yamldeployments/warp_routes/USDT/ctusd-deploy.yaml
| ethereum: | ||
| type: amountRoutingIsm | ||
| threshold: 1000000000 | ||
| lowerIsm: | ||
| type: staticAggregationIsm | ||
| threshold: 1 | ||
| modules: | ||
| - type: trustedRelayerIsm | ||
| relayer: "0x1e100476e9360b11a592eafe1c90328368e547b6" | ||
| - type: defaultFallbackRoutingIsm | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| domains: {} | ||
| upperIsm: | ||
| domains: {} | ||
| owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01" | ||
| type: defaultFallbackRoutingIsm |
There was a problem hiding this comment.
Reorder nested ISM mappings to keep YAML key sorting consistent.
Line 21-35 and Line 93-107 have unsorted nested keys (for example type/threshold/lowerIsm/upperIsm, plus module-entry maps). Those need alphabetical ordering too, not just top-level keys.
🧹 Example reorder for one `ethereum` domain block
ethereum:
- type: amountRoutingIsm
- threshold: 1000000000
lowerIsm:
- type: staticAggregationIsm
- threshold: 1
modules:
- - type: trustedRelayerIsm
- relayer: "0x1e100476e9360b11a592eafe1c90328368e547b6"
- - type: defaultFallbackRoutingIsm
- owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01"
+ - relayer: "0x1e100476e9360b11a592eafe1c90328368e547b6"
+ type: trustedRelayerIsm
+ - domains: {}
+ owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01"
+ type: defaultFallbackRoutingIsm
- domains: {}
+ threshold: 1
+ type: staticAggregationIsm
+ threshold: 1000000000
+ type: amountRoutingIsm
upperIsm:
domains: {}
owner: "0xEA2117b24F7947647Bec60527B68f4244AE40c01"
type: defaultFallbackRoutingIsmAs per coding guidelines "**/*.{yaml,yml}: YAML files must have keys sorted alphabetically" and "**/*.yaml: YAML files must have keys sorted alphabetically".
Also applies to: 92-107
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@deployments/warp_routes/USDT/ctusd-deploy.yaml` around lines 20 - 35, Reorder
the nested YAML mappings for the ethereum domain block so all mapping keys are
alphabetized (e.g., ensure the ethereum mapping contains keys in alphabetical
order such as lowerIsm, threshold, type, upperIsm as applicable) and apply the
same alphabetical sorting inside lowerIsm/upperIsm and each modules entry (sort
keys within module maps like relayer, type, owner, domains alphabetically).
Locate the ethereum block and the paired block referenced (the second domain
block with the same structure) and reorder their nested keys and module-entry
maps to follow the repository guideline that all YAML mappings must be sorted
alphabetically.
Summary
0x000000000022D473030F116dDEE9F6B43aC78BA3)Chains
0x3593dc3be3eAc45a886C09D9E47F130687a2B7dd0xc566ae9c0e87a152b9626af7afff0c44289533030x1D8422eb0F0b88163a4Bd7e83135E59d0D322f070x31169ee5A8C0D680de74461d7B5394fFc7C3576B0xE086378F7f0afd5C3ff95E10B5e7806a0901b33f0x7C55ef6A28c65f4EDF7d5C46cE82A44E350Fad4B0x473E9d1745493cf3281AAEEA8fE1c7147C5dAe070x7e2cAc751CB4FA5bD78482f91cc2c5aEb194Ee340x4eFaacbf0D3d57b401Cb6B559e84b344448b0C300xad2877D26949b5c98934d4473D0261274628F8bf🤖 Generated with Claude Code