CipherLabs
/
hyperlane-monorepo
mirror of https://github.com/hyperlane-xyz/hyperlane-monorepo
2
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
The home for Hyperlane core contracts, sdk packages, and other infrastructure
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2237 Commits
486 Branches
322 Tags
224 MiB
Tag: Branch: Tree: 6171d82c82
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '6171d82c82'
${ noResults }
hyperlane-monorepo/rust/config/mainnet_config.json

1365 lines
55 KiB
Raw Normal View History Unescape

Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
{
"chains": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"ancient8": {
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"aggregationHook": "0x1EF4ED658d542524d1D547ba2F94d3B038a55b8f",
fix: agent config check, run relayer on mantapacific (#3714) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"batchContractAddress": "0x4C97D35c668EE5194a13c8DE8Afc18cce40C9F28",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"blockExplorers": [
{
"apiUrl": "https://scan.ancient8.gg/api",
"family": "blockscout",
"name": "Ancient8 Explorer",
"url": "https://scan.ancient8.gg"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 2,
"reorgPeriod": 0
},
"chainId": 888888888,
"displayName": "Ancient8",
"domainId": 888888888,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0xB6F0f1267B01C27326F61a4B4fe2c73751802685",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x5E01d8F34b629E3f92d69546bbc4142A7Adee7e9",
"gasCurrencyCoinGeckoId": "ethereum",
"index": {
"from": 2507127
},
"interchainGasPaymaster": "0x8F1E22d309baa69D398a03cc88E9b46037e988AA",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0xBd3C7253F08c040eDB9c54e7CD4f8a5fd1eb935D",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"isTestnet": false,
"mailbox": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"merkleTreeHook": "0x811808Dd29ba8B0FC6C0ec0b5537035E59745162",
"name": "ancient8",
"nativeToken": {
"decimals": 18,
"name": "Ether",
"symbol": "ETH"
},
"pausableHook": "0x66DC49405Ae2956f7E87FEAa9fE8f506C8987462",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0xcf678903c003651DB0bb933820259A16ea9d95e4",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocol": "ethereum",
"protocolFee": "0xE0C452DDA7506f0F4dE5C8C1d383F7aD866eA4F0",
"proxyAdmin": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
"rpcUrls": [
{
"http": "https://rpc.ancient8.gg"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0xBd3C7253F08c040eDB9c54e7CD4f8a5fd1eb935D",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMerkleRootMultisigIsmFactory": "0x2C1FAbEcd7bFBdEBF27CcdB67baADB38b6Df90fC",
"staticMessageIdMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"storageGasOracle": "0x59Bf7c7b458375b1A7c453aE70EaCb376E65CDAF",
"technicalStack": "other",
"testRecipient": "0x2Fa570E83009eaEef3a1cbd496a9a30F05266634",
fix: agent config check, run relayer on mantapacific (#3714) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"validatorAnnounce": "0x931dFCc8c1141D6F532FD023bd87DAe0080c835d"
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"arbitrum": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0xe0cb37cFc47296f1c4eD77EFf92Aed478644d10c",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.arbiscan.io/api",
"family": "etherscan",
"name": "Arbiscan",
"url": "https://arbiscan.io"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
"reorgPeriod": 0
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 42161,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Arbitrum",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 42161,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0x5d759B5CeEb1C3b0181bEc0F80fb04f820cc35D1",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0xa2931C37957f3079d3B21b877d56E1db930e02a5",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x9e8fFb1c26099e75Dd5D794030e2E9AA51471c25",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "ethereum",
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-arbitrum.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"from": 143649797
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0xfa8bfcE55B3A0631dF38257615cEF7FCD3523A48",
"interchainAccountRouter": "0xCD0CFFf6eFD943b4b81f2c15847730dbcD30e3aE",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x3b6044acd6767f017e99318AA6Ef93b7B06A5a22",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0x96845a0469363f90779f6D5cd49D79bDDAc69429",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x979Ca5202784112f4738403dBec5D0F3B9daabB9",
"merkleTreeHook": "0x748040afB89B8FdBb992799808215419d36A0930",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "arbitrum",
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "Ether",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"symbol": "ETH"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0xEf30f29Dcd3FCB1DCcDA9C7Cbf2A5957E8Ee9Cc3",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0x1E38556b4fE553e6249448960875883990efcf34",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xD0199067DACb8526e7dc524a9a7DCBb57Cd25421",
"proxyAdmin": "0x80Cebd56A65e46c474a1A101e89E76C4c51D179c",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
{
"http": "https://arbitrum.llamarpc.com"
},
{
"http": "https://rpc.ankr.com/arbitrum"
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
{
"http": "https://arb1.arbitrum.io/rpc"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x9B5f440bBb64Fee337F37e03362b628711Ea09C7",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0x96845a0469363f90779f6D5cd49D79bDDAc69429",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0xD4883084389fC1Eeb4dAfB2ADcFc36B711c310EB",
"staticMerkleRootMultisigIsmFactory": "0x3C330D4A2e2b8443AFaB8E326E64ab4251B7Eae0",
"staticMessageIdMultisigIsmFactory": "0x12Df53079d399a47e9E730df095b712B0FDFA791",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0xD3805207b65d99C075ceA938Fa7c0587026a5DF5",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"technicalStack": "arbitrumnitro",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x1df063280C4166AF9a725e3828b4dAC6c7113B08"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
"avalanche": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x0165a22BA489F7DA37DAf6397781777D9FCB5708",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"apiUrl": "https://api.routescan.io/v2/network/mainnet/evm/43114/etherscan/api",
"family": "routescan",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"name": "SnowTrace",
"url": "https://snowtrace.io"
}
],
"blocks": {
"confirmations": 3,
"estimateBlockTime": 2,
"reorgPeriod": 3
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 43114,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Avalanche",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 43114,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0x9f68F961ba2dF53b1cB3EbCC0b08e89790C6E2f6",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x28F7907911C7E321c596686AE6D1F20516450037",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x61D15D571D5f7A9eF0D1938f072f430bBF024747",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "avalanche-2",
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-avalanche.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 36874693
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x786c26C1857032617c215f265509d6E44e44Bfe3",
"interchainAccountRouter": "0xA967A6CE0e73fAf672843DECaA372511996E8852",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x95519ba800BBd0d34eeAE026fEc620AD978176C0",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0xe7a61510EA7197281b49e5bdf1798608d5132595",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0xFf06aFcaABaDDd1fb08371f9ccA15D73D51FeBD6",
"merkleTreeHook": "0x84eea61D679F42D92145fA052C89900CBAccE95A",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "avalanche",
"nativeToken": {
"decimals": 18,
"name": "Avalanche",
"symbol": "AVAX"
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0x239eB860770F1C48ABAC9bE9825d20e3E7c018df",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0xd76080269C641e1adb786b72ae60Ddac3b6b8ed0",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xEc4AdA26E51f2685279F37C8aE62BeAd8212D597",
"proxyAdmin": "0xd7CF8c05fd81b8cA7CfF8E6C49B08a9D63265c9B",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
{
"http": "https://rpc.ankr.com/avalanche"
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
{
"http": "https://api.avax.network/ext/bc/C/rpc",
"pagination": {
"maxBlockRange": 100000,
"minBlockNumber": 6765067
}
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x3bF6Ac986C7Af9A9Ac356C0e99C0041EFd8D96e7",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0xe7a61510EA7197281b49e5bdf1798608d5132595",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0xa5E13796eB7d2EDCc88012c8cfF90D69B51FcF9f",
"staticMerkleRootMultisigIsmFactory": "0x896cF1D1B66cD211633eDd589fF158E8Cfaf9B54",
"staticMessageIdMultisigIsmFactory": "0x8819D653DF5b1FC0DdB32189a2704E471AF8483c",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0x175821F30AdCAA4bbB72Ce98eF76C2E0De2C3f21",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x9Cad0eC82328CEE2386Ec14a12E81d070a27712f"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
"base": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x13f3d4B0Ee0a713430fded9E18f7fb6c91A6E41F",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.basescan.org/api",
"family": "etherscan",
"name": "BaseScan",
"url": "https://basescan.org"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 2,
"reorgPeriod": 1
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 8453,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Base",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 8453,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0x80C8F6394c0FcF7bAB16ac08b85484361eCe5888",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x7E27456a839BFF31CA642c060a2b68414Cb6e503",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x4Eb82Ee35b0a1c1d776E3a3B547f9A9bA6FCC9f2",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "ethereum",
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-base.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 5695475
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x861908E6c8F992537F557da5Fb5876836036b347",
"interchainAccountRouter": "0xa85F9e4fdA2FFF1c07f2726a630443af3faDF830",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0xc3F23848Ed2e04C0c6d41bd7804fa8f89F940B94",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0x77bE0b5aE400675063Ce2B2B0d692D9341f4b193",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0xeA87ae93Fa0019a82A727bfd3eBd1cFCa8f64f1D",
"merkleTreeHook": "0x19dc38aeae620380430C200a6E990D5Af5480117",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "base",
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "Ether",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"symbol": "ETH"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0x46fa3A5780e5B90Eaf34BDED554d5353B5ABE9E7",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0x2AF32cF8e3Cf42d221eDa0c843818fA5ee129E27",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0x99ca8c74cE7Cfa9d72A51fbb05F9821f5f826b3a",
"proxyAdmin": "0x4Ed7d626f1E96cD1C0401607Bf70D95243E3dEd1",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
"http": "https://base.publicnode.com/"
},
{
"http": "https://mainnet.base.org"
},
{
"http": "https://base.blockpi.network/v1/rpc/public"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0x77bE0b5aE400675063Ce2B2B0d692D9341f4b193",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
"staticMerkleRootMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
"staticMessageIdMultisigIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0xBF12ef4B9f307463D3FB59c3604F294dDCe287E2",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"testRecipient": "0xb7C9307fE90B9AB093c6D3EdeE3259f5378D5f03",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x182E8d7c5F1B06201b102123FC7dF0EaeB445a7B"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Deploy to Mode & Blast (#3653) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"blast": {
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"aggregationHook": "0x012278333Ce0A845AE9bD7302867a59Bd5D3635d",
Deploy to Mode & Blast (#3653) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"blockExplorers": [
{
"apiUrl": "https://api.routescan.io/v2/network/mainnet/evm/81457/etherscan/api",
"family": "routescan",
"name": "Blast Explorer",
"url": "https://blastexplorer.io"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 2,
"reorgPeriod": 1
},
"chainId": 81457,
"displayName": "Blast",
"domainId": 81457,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0x0296D16d371a49F631143612020138896b3eA421",
Deploy to Mode & Blast (#3653) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"domainRoutingIsmFactory": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"fallbackRoutingHook": "0x6Fae4D9935E2fcb11fC79a64e917fb2BF14DaFaa",
"gasCurrencyCoinGeckoId": "ethereum",
"index": {
"from": 2496427
},
"interchainGasPaymaster": "0xB3fCcD379ad66CED0c91028520C64226611A48c9",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0x208263bB303B2a737642fB13C765F106a2591be8",
Deploy to Mode & Blast (#3653) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"mailbox": "0x3a867fCfFeC2B790970eeBDC9023E75B0a172aa7",
"merkleTreeHook": "0xC9B8ea6230d6687a4b13fD3C0b8f0Ec607B26465",
"name": "blast",
"nativeToken": {
"decimals": 18,
"name": "Ether",
"symbol": "ETH"
},
"pausableHook": "0xE0C452DDA7506f0F4dE5C8C1d383F7aD866eA4F0",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0x4C97D35c668EE5194a13c8DE8Afc18cce40C9F28",
Deploy to Mode & Blast (#3653) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"protocol": "ethereum",
"protocolFee": "0x12582c7B0f43c6A667CBaA7fA8b112F7fb1E69F0",
"proxyAdmin": "0xeA87ae93Fa0019a82A727bfd3eBd1cFCa8f64f1D",
"rpcUrls": [
{
"http": "https://rpc.blast.io"
}
],
"staticAggregationHookFactory": "0x4Ed7d626f1E96cD1C0401607Bf70D95243E3dEd1",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0x208263bB303B2a737642fB13C765F106a2591be8",
Deploy to Mode & Blast (#3653) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"staticAggregationIsmFactory": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
"staticMerkleRootMultisigIsmFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
"staticMessageIdMultisigIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
"storageGasOracle": "0xBDa330Ea8F3005C421C8088e638fBB64fA71b9e0",
"technicalStack": "other",
"testRecipient": "0x17E216fBb22dF4ef8A6640ae9Cb147C92710ac84",
"validatorAnnounce": "0xFC62DeF1f08793aBf0E67f69257c6be258194F72"
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"bsc": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x402Fc106576462a892355d69ACF03D46A888ae88",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.bscscan.com/api",
"family": "etherscan",
"name": "BscScan",
"url": "https://bscscan.com"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
"reorgPeriod": 15
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 56,
"displayName": "Binance Smart Chain",
"displayNameShort": "Binance",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"domainId": 56,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0xBc3Af0D4930502Ff0f6a8416a7a184c7BFFe19E7",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0xe6Af5720d34213C805C08e2470aea979e3F72F75",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x237E81f87F57Badad9e09f13CC676D986cA852e7",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "binancecoin",
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-bsc.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 32893043
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0xB274Bbbc1df5f1d1763216A93d473fde6f5de043",
"interchainAccountRouter": "0x4BBd67dC995572b40Dc6B3eB6CdE5185a5373868",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x78E25e7f84416e69b9339B0A6336EB6EFfF6b451",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0xfA360ff588623A026BF19A1801F2A8F1f045fa33",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x2971b9Aec44bE4eb673DF1B88cDB57b96eefe8a4",
"merkleTreeHook": "0xFDb9Cd5f9daAA2E4474019405A328a88E7484f26",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"name": "bsc",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"nativeToken": {
"decimals": 18,
"name": "BNB",
"symbol": "BNB"
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0x7DBdAd1b4A922B65d37d7258a4227b6658344b7f",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0x25dB01caDf91CfD2f7e6dD829Ce81698217F9151",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xA8Aa5f14a5463a78E45CC068F11c867949F3E367",
"proxyAdmin": "0x65993Af9D0D3a64ec77590db7ba362D6eB78eF70",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"http": "https://rpc.ankr.com/bsc"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
{
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"http": "https://bsc.drpc.org"
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
{
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"http": "https://bscrpc.com"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xe70E86a7D1e001D419D71F960Cb6CaD59b6A3dB6",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0xfA360ff588623A026BF19A1801F2A8F1f045fa33",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x38B3878c4fb44d201DA924c4a04bae3EE728c065",
"staticMerkleRootMultisigIsmFactory": "0xfADBc81Ca8A957F1Bf7c78bCc575b28DBDE042b6",
"staticMessageIdMultisigIsmFactory": "0x4B1d8352E35e3BDE36dF5ED2e73C24E35c4a96b7",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0x91d23D603d60445411C06e6443d81395593B7940",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"transactionOverrides": {
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"gasPrice": 3000000000
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
},
"validatorAnnounce": "0x7024078130D9c2100fEA474DAD009C2d1703aCcd"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
"celo": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0xc65890329066FB20c339Bc5C22f1756e9D3a4fF5",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.celoscan.io/api",
"family": "etherscan",
"name": "CeloScan",
"url": "https://celoscan.io"
},
{
"apiUrl": "https://explorer.celo.org/mainnet/api",
"family": "blockscout",
"name": "Blockscout",
"url": "https://explorer.celo.org"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 5,
"reorgPeriod": 0
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 42220,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Celo",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 42220,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"domainRoutingIsm": "0xf18E32428dad0802C5D6F723cB80A6Da889777c4",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x2A2c22B0a8615ad24839fA6Af302E896Af32d1a3",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0xDC98a856fb9112894c2fE32267DA8bF35645FAF3",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-celo.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 22102340
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x30a8DEc5318e2aAa9ad5b069fC606c4CfF6f5676",
"interchainAccountRouter": "0x4ED23E3885e1651E62564F78817D91865beba575",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x571f1435613381208477ac5d6974310d88AC7cB7",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0x0dcb01D4ABfa73fadB17C4B0e8cd52A38BD52c66",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x50da3B3907A08a24fe4999F4Dcf337E8dC7954bb",
"merkleTreeHook": "0x04dB778f05854f26E67e0a66b740BBbE9070D366",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "celo",
"nativeToken": {
"decimals": 18,
"name": "CELO",
"symbol": "CELO"
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0x80672c5D9Fd26B235654C24adc1CFcDeb8d15115",
"pausableIsm": "0x6Bc4437ce69696C9461Cbc89582c259AC8847A58",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0x89886d431f9c3eEE64DCD6dAbA3f7D689D98D899",
"proxyAdmin": "0x90f9a2E9eCe93516d65FdaB726a3c62F5960a1b9",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
"http": "https://forno.celo.org"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xc3745652EFB8555A8b064A0EA78d295133d326D2",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"staticAggregationIsm": "0x99e8E56Dce3402D6E09A82718937fc1cA2A9491E",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x1722dd970a1F56040712129f5Eeb76B003fd7500",
"staticMerkleRootMultisigIsmFactory": "0x4C96a1abc44dc846775CE702C9E9BE821D3b487c",
"staticMessageIdMultisigIsmFactory": "0xaB402f227e892Ef37C105bf06619c0fa106a1fB2",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0xD9A9966E7dA9a7f0032bF449FB12696a638E673C",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0xCeF677b65FDaA6804d4403083bb12B8dB3991FE1"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
"ethereum": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0xb87AC8EA4533AE017604E44470F7c1E550AC6F10",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.etherscan.io/api",
"family": "etherscan",
"name": "Etherscan",
"url": "https://etherscan.io"
},
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"apiUrl": "https://eth.blockscout.com/api",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"family": "blockscout",
"name": "Blockscout",
"url": "https://blockscout.com/eth/mainnet"
}
],
"blocks": {
"confirmations": 3,
"estimateBlockTime": 13,
"reorgPeriod": 14
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 1,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Ethereum",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 1,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0xBA328338044e0C0AFd0591FB6E5e2F83C4e8F742",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x28fA9552F19039b450498B0d8e5DEAe0d0aAc559",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x571f1435613381208477ac5d6974310d88AC7cB7",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"gasCurrencyCoinGeckoId": "ethereum",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-mainnet.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 18422581
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x609707355a53d2aAb6366f48E2b607C599D26B29",
"interchainAccountRouter": "0x8dBae9B1616c46A20591fE0006Bf015E28ca5cC9",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x9e6B1022bE9BBF5aFd152483DAD9b88911bC8611",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0x8CE0c6cAf18DbF5882b35F26E28412f3E9AbDeca",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0xc005dc82818d67AF737725bD4bf75435d065D239",
"merkleTreeHook": "0x48e6c30B97748d1e2e03bf3e9FbE3890ca5f8CCA",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "ethereum",
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "Ether",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"symbol": "ETH"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0x3A66Dc852e56d3748838b3C27CF381105b83705b",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0xDC98a856fb9112894c2fE32267DA8bF35645FAF3",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0x8B05BF30F6247a90006c5837eA63C7905D79e6d8",
"proxyAdmin": "0x75EE15Ee1B4A75Fa3e2fDF5DF3253c25599cc659",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"http": "https://ethereum.publicnode.com"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
{
"http": "https://cloudflare-eth.com"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x6D2555A8ba483CcF4409C39013F5e9a3285D3C9E",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0x5447cdC0f4B1Afd827BF9d2F6b6cE7668d5dc284",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x46FA191Ad972D9674Ed752B69f9659A0d7b22846",
"staticMerkleRootMultisigIsmFactory": "0x47e8aF9e30C32Ab91060ED587894288786761B45",
"staticMessageIdMultisigIsmFactory": "0xfA21D9628ADce86531854C2B7ef00F07394B0B69",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"storageGasOracle": "0xc9a103990A8dB11b4f627bc5CD1D0c2685484Ec5",
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"transactionOverrides": {
"maxFeePerGas": 150000000000,
"maxPriorityFeePerGas": 5000000000
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0xCe74905e51497b4adD3639366708b821dcBcff96"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
"gnosis": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0xdD1FA1C12496474c1dDC67a658Ba81437F818861",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.gnosisscan.io/api",
"family": "etherscan",
"name": "GnosisScan",
"url": "https://gnosisscan.io"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 5,
"reorgPeriod": 14
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 100,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Gnosis",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 100,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0x83873DB8B4982091D0781B4eDF108DCb98075C39",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0xbB5Df000113e767dE11343A16f83De733e5bCC0F",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x24f5E353dD03E103Ba2372F7D6FC0cf3A66f849c",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "xdai",
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-gnosis-chain.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 30620793
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x5a56dff3D92D635372718f86e6dF09C1129CFf53",
"interchainAccountRouter": "0x5E59EBAedeB691408EBAcF6C37218fa2cFcaC9f2",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0xDd260B99d302f0A3fF885728c086f729c06f227f",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0x5DB7edF8C1CF91e34895dB2e4b28d8b9C68ddC7B",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0xaD09d78f4c6b9dA2Ae82b1D34107802d380Bb74f",
"merkleTreeHook": "0x2684C6F89E901987E1FdB7649dC5Be0c57C61645",
"name": "gnosis",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "xDai",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"symbol": "xDai"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0xf728C884De5275a608dEC222dACd0f2BF2E23AB6",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0x223F7D3f27E6272266AE4B5B91Fd5C7A2d798cD8",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0x9c2214467Daf9e2e1F45b36d08ce0b9C65BFeA88",
"proxyAdmin": "0x81a92A1a272cb09d7b4970b07548463dC7aE0cB7",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
"http": "https://rpc.gnosischain.com",
"pagination": {
"maxBlockRange": 10000,
"minBlockNumber": 25997478
}
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xbC8AA096dabDf4A0200BB9f8D4Cbb644C3D86d7B",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0xe640167B9a283C8b4039fA33f3ac7be6e7E788c5",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x11EF91d17c5ad3330DbCa709a8841743d3Af6819",
"staticMerkleRootMultisigIsmFactory": "0x8E273260EAd8B72A085B19346A676d355740e875",
"staticMessageIdMultisigIsmFactory": "0x603f46cc520d2fc22957b81e206408590808F02F",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0x5E01d8F34b629E3f92d69546bbc4142A7Adee7e9",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x87ED6926abc9E38b9C7C19f835B41943b622663c"
Cosmos / CosmWasm agents (#2865) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Mattie Conover <git@mconover.dev> Co-authored-by: hashableric <hashableric@gmail.com> Co-authored-by: byeongsu-hong <hong@byeongsu.dev> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"inevm": {
"aggregationHook": "0xe0dDb5dE7D52918237cC1Ae131F29dcAbcb0F62B",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"apiUrl": "https://inevm.calderaexplorer.xyz/api",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"family": "blockscout",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"name": "Caldera inEVM Explorer",
"url": "https://inevm.calderaexplorer.xyz"
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"reorgPeriod": 0
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"chainId": 2525,
"displayName": "Injective EVM",
"displayNameShort": "inEVM",
"domainId": 2525,
"domainRoutingIsm": "0xBD70Ea9D599a0FC8158B026797177773C3445730",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"gasCurrencyCoinGeckoId": "injective-protocol",
"index": {
"from": 18972465
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x31894E7a734540B343d67E491148EB4FC9f7A45B",
"interchainAccountRouter": "0x4E55aDA3ef1942049EA43E904EB01F4A0a9c39bd",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x19dc38aeae620380430C200a6E990D5Af5480117",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0x440f7AD246F3e75df88a6338E8A33e91DA4B2B05",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"merkleTreeHook": "0x0972954923a1e2b2aAb04Fa0c4a0797e5989Cd65",
"name": "inevm",
Cosmos / CosmWasm agents (#2865) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Mattie Conover <git@mconover.dev> Co-authored-by: hashableric <hashableric@gmail.com> Co-authored-by: byeongsu-hong <hong@byeongsu.dev> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
1 year ago
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"name": "Injective",
"symbol": "INJ"
Cosmos / CosmWasm agents (#2865) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Mattie Conover <git@mconover.dev> Co-authored-by: hashableric <hashableric@gmail.com> Co-authored-by: byeongsu-hong <hong@byeongsu.dev> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0xBDa330Ea8F3005C421C8088e638fBB64fA71b9e0",
"pausableIsm": "0x6Fae4D9935E2fcb11fC79a64e917fb2BF14DaFaa",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0x0D63128D887159d63De29497dfa45AFc7C699AE4",
"proxyAdmin": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
Cosmos / CosmWasm agents (#2865) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Mattie Conover <git@mconover.dev> Co-authored-by: hashableric <hashableric@gmail.com> Co-authored-by: byeongsu-hong <hong@byeongsu.dev> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
1 year ago
"rpcUrls": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"http": "https://inevm.calderachain.xyz/http"
Cosmos / CosmWasm agents (#2865) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Mattie Conover <git@mconover.dev> Co-authored-by: hashableric <hashableric@gmail.com> Co-authored-by: byeongsu-hong <hong@byeongsu.dev> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz>
1 year ago
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"staticAggregationIsm": "0x3052aD50De54aAAc5D364d80bBE681d29e924597",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMerkleRootMultisigIsmFactory": "0x2C1FAbEcd7bFBdEBF27CcdB67baADB38b6Df90fC",
"staticMessageIdMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"storageGasOracle": "0x6119E37Bd66406A1Db74920aC79C15fB8411Ba76",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x15ab173bDB6832f9b64276bA128659b0eD77730B"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"injective": {
"bech32Prefix": "inj",
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"blockExplorers": [
],
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"blocks": {
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"confirmations": 1,
"estimateBlockTime": 1,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"reorgPeriod": 10
},
"canonicalAsset": "inj",
"chainId": "injective-1",
"contractAddressBytes": 20,
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"displayName": "Injective",
"domainId": 6909546,
"gasCurrencyCoinGeckoId": "injective-protocol",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"gasPrice": {
"amount": "700000000",
"denom": "inj"
},
Injective & inevm agents (#3155) ### Description - Deploys injective & inevm validators, adds them to the hyperlane context relayer, and starts scraping inevm ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: nambrot <nambrot@googlemail.com> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>
10 months ago
"grpcUrls": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"http": "https://injective-grpc.goldenratiostaking.net:443"
Injective & inevm agents (#3155) ### Description - Deploys injective & inevm validators, adds them to the hyperlane context relayer, and starts scraping inevm ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: nambrot <nambrot@googlemail.com> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>
10 months ago
}
],
Add Neutron back to mainnet3_config.json (#3220) ### Description Looks like https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-edae1a4e631a67121d92119998e37740c0190bec5060e3c842cc86e4d3d26a4dL417 removed Neutron from mainnet3_config.json :( Seems like the Typescript tooling may have overridden it accidentally? Will need to figure out what to do there ### Drive-by changes ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
"index": {
Update gas oracles, deploy agents (#3755) ### Description - Updates gas oracles to make messages to Scroll slightly cheaper - After running into issues configuring non-EVM remotes in the IGP / gas oracle tooling (see https://discord.com/channels/935678348330434570/1238439687165579264), added a temporary band aid of just try/catching. We'll want to fix this at some point in the future - Deploys agents with a new image - Updates the agent JSON configs with some params we were running the agents with in prod via env vars - Adjusts kathy frequency on testnet to send every 1.5hrs instead of 7hrs - Stops running eclipsetestnet agents - apparently there was a reset ### Drive-by changes Some drive-by logging changes ### Related issues n/a ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"chunk": 25,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"from": 58419500
Add Neutron back to mainnet3_config.json (#3220) ### Description Looks like https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-edae1a4e631a67121d92119998e37740c0190bec5060e3c842cc86e4d3d26a4dL417 removed Neutron from mainnet3_config.json :( Seems like the Typescript tooling may have overridden it accidentally? Will need to figure out what to do there ### Drive-by changes ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
},
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
"interchainGasPaymaster": "0x27ae52298e5b53b34b7ae0ca63e05845c31e1f59",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x0f7fb53961d70687e352aa55cb329ca76edc0c19",
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
"merkleTreeHook": "0x568ad3638447f07def384969f4ea39fae3802962",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"name": "injective",
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"nativeToken": {
"decimals": 18,
"denom": "inj",
"name": "Injective",
"symbol": "INJ"
},
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
"protocol": "cosmos",
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"restUrls": [
{
"http": "https://sentry.lcd.injective.network:443"
}
],
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
"rpcUrls": [
{
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"http": "https://sentry.tm.injective.network:443"
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
}
],
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"slip44": 118,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x1fb225b2fcfbe75e614a1d627de97ff372242eed"
},
"mantapacific": {
"aggregationHook": "0x8464aF853363B8d6844070F68b0AB34Cb6523d0F",
"blockExplorers": [
Cosmos grpc fallbackprovider (#3139) ### Description Implements grpc fallback provider logic for cosmos - initially tried implementing the fallback provider deprioritization logic at middleware level like in the EVM. The difference between ethers and cosmrs is that in the latter, middleware can only live at the transport layer (`tower` crate level). - based on this github [issue](https://github.com/hyperium/tonic/issues/733), that actually doesn't look possible, because the http::Request type isn't `Clone` so it can't be submitted to multiple providers - ended up implementing the fallback provider at the application layer, by keeping an array of grpc channels - There is now a `call` method in `hyperlane_core::FallbackProvider` which I'm actually really happy with. This method handles the fallbackprovider-specific logic by taking in an async closure, running it on each provider, and iterating providers if the closure call fails. In `grpc.rs` you can see how this is slightly verbose but I think it's quite manageable. The only part that bugs me is having to duplicate `Pin::from(Box::from(future))`, but that's need afaict because the regular closure returns an anonymous type - adds `grpcUrls` and `customGrpcUrls` config items - tests the cosmos fallback provider e2e ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes: https://github.com/hyperlane-xyz/issues/issues/998 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"apiUrl": "https://pacific-explorer.manta.network/api",
"family": "blockscout",
"name": "Manta Pacific Explorer",
"url": "https://pacific-explorer.manta.network"
Cosmos grpc fallbackprovider (#3139) ### Description Implements grpc fallback provider logic for cosmos - initially tried implementing the fallback provider deprioritization logic at middleware level like in the EVM. The difference between ethers and cosmrs is that in the latter, middleware can only live at the transport layer (`tower` crate level). - based on this github [issue](https://github.com/hyperium/tonic/issues/733), that actually doesn't look possible, because the http::Request type isn't `Clone` so it can't be submitted to multiple providers - ended up implementing the fallback provider at the application layer, by keeping an array of grpc channels - There is now a `call` method in `hyperlane_core::FallbackProvider` which I'm actually really happy with. This method handles the fallbackprovider-specific logic by taking in an async closure, running it on each provider, and iterating providers if the closure call fails. In `grpc.rs` you can see how this is slightly verbose but I think it's quite manageable. The only part that bugs me is having to duplicate `Pin::from(Box::from(future))`, but that's need afaict because the regular closure returns an anonymous type - adds `grpcUrls` and `customGrpcUrls` config items - tests the cosmos fallback provider e2e ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes: https://github.com/hyperlane-xyz/issues/issues/998 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
}
],
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
"reorgPeriod": 1
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"chainId": 169,
"displayName": "Manta Pacific",
"displayNameShort": "Manta",
"domainId": 169,
"domainRoutingIsm": "0xDEed16fe4b1c9b2a93483EDFf34C77A9b57D31Ff",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x8358D8291e3bEDb04804975eEa0fe9fe0fAfB147",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0xD1E267d2d7876e97E217BfE61c34AB50FEF52807",
"gasCurrencyCoinGeckoId": "ethereum",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"gnosisSafeTransactionServiceUrl": "https://transaction.safe.manta.network",
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
"index": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"from": 437300
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0xA34ceDf9068C5deE726C67A4e1DCfCc2D6E2A7fD",
"interchainAccountRouter": "0x0f6fF770Eda6Ba1433C39cCf47d4059b254224Aa",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x0D63128D887159d63De29497dfa45AFc7C699AE4",
Update Mode and Blast validator sets & gas oracles (#3669) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: nambrot <nambrot@googlemail.com>
7 months ago
"interchainSecurityModule": "0xEda7cCD2A8CF717dc997D0002e363e4D10bF5c0d",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"isTestnet": false,
"mailbox": "0x3a464f746D23Ab22155710f44dB16dcA53e0775E",
"merkleTreeHook": "0x149db7afD694722747035d5AEC7007ccb6F8f112",
"name": "mantapacific",
"nativeToken": {
"decimals": 18,
"name": "Ether",
"symbol": "ETH"
},
"pausableHook": "0x7556a0E61d577D921Cba8Fca0d7D6299d36E607E",
"protocol": "ethereum",
"protocolFee": "0xd83A4F747fE80Ed98839e05079B1B7Fe037b1638",
"proxyAdmin": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"rpcUrls": [
{
"http": "https://pacific-rpc.manta.network/http"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
"staticAggregationIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
"staticMerkleRootMultisigIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMessageIdMultisigIsmFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"storageGasOracle": "0x19dc38aeae620380430C200a6E990D5Af5480117",
"testRecipient": "0x4E1c88DD261BEe2941e6c1814597e30F53330428",
"testTokenRecipient": "0x5060eCD5dFAD300A90592C04e504600A7cdcF70b",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x2fa5F5C96419C222cDbCeC797D696e6cE428A7A9"
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
},
Deploy to Mode & Blast (#3653) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"mode": {
"blockExplorers": [
{
"apiUrl": "https://explorer.mode.network/api",
"family": "blockscout",
"name": "Mode Explorer",
"url": "https://explorer.mode.network"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 2,
"reorgPeriod": 1
},
"chainId": 34443,
"displayName": "Mode",
"domainId": 34443,
"domainRoutingIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
"fallbackRoutingHook": "0x8F1E22d309baa69D398a03cc88E9b46037e988AA",
"gasCurrencyCoinGeckoId": "ethereum",
"index": {
"from": 6817759
},
"interchainGasPaymaster": "0x931dFCc8c1141D6F532FD023bd87DAe0080c835d",
"interchainSecurityModule": "0x8dfE6790DbB2Ecc1bEdb0eECfc1Ff467Ae5d8C89",
"mailbox": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"merkleTreeHook": "0xE2ee936bEa8e42671c400aC96dE198E06F2bA2A6",
"name": "mode",
"nativeToken": {
"decimals": 18,
"name": "Ether",
"symbol": "ETH"
},
"pausableHook": "0xA1ac41d8A663fd317cc3BD94C7de92dC4BA4a882",
"protocol": "ethereum",
"protocolFee": "0xea820f9BCFD5E16a0dd42071EB61A29874Ad81A4",
"proxyAdmin": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
"rpcUrls": [
{
"http": "https://mainnet.mode.network"
}
],
"staticAggregationHookFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
"staticAggregationIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMerkleRootMultisigIsmFactory": "0x2C1FAbEcd7bFBdEBF27CcdB67baADB38b6Df90fC",
"staticMessageIdMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
"storageGasOracle": "0xC9B8ea6230d6687a4b13fD3C0b8f0Ec607B26465",
"technicalStack": "other",
"testRecipient": "0x12582c7B0f43c6A667CBaA7fA8b112F7fb1E69F0",
"validatorAnnounce": "0x48083C69f5a42c6B69ABbAd48AE195BD36770ee2"
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"moonbeam": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x23cca255aE83F57F39EAf9D14fB9FdaDF22D5863",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api-moonbeam.moonscan.io/api",
"family": "etherscan",
"name": "MoonScan",
"url": "https://moonscan.io"
}
],
"blocks": {
"confirmations": 2,
"estimateBlockTime": 12,
"reorgPeriod": 2
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 1284,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Moonbeam",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 1284,
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x8061Af3A459093540d17823D651BC5E2A92669a7",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x6C2D6eA0969F7Aa0A850CCA88c7BFACa563B2361",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gnosisSafeTransactionServiceUrl": "https://transaction.multisig.moonbeam.network",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 4719713
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x799eA6f430f5CA901b59335fFC2fA10531106009",
"interchainAccountRouter": "0x6b142f596FFc761ac3fFaaC1ecaDe54f4EE09977",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x14760E32C0746094cF14D97124865BC7F0F7368F",
"interchainSecurityModule": "0x373836DFa82f2D27ec79Ca32A197Aa1665F0E1e9",
"mailbox": "0x094d03E751f49908080EFf000Dd6FD177fd44CC3",
"merkleTreeHook": "0x87403b85f6f316e7ba91ba1fa6C3Fb7dD4095547",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "moonbeam",
"nativeToken": {
"decimals": 18,
"name": "GLMR",
"symbol": "GLMR"
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0xe28f2AEEB42ee83CAd068D9A9a449c8b868C137f",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xCd3e29A9D293DcC7341295996a118913F7c582c0",
"proxyAdmin": "0x6A9cdA3dd1F593983BFd142Eb35e6ce4137bd5ce",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
"http": "https://rpc.api.moonbeam.network"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x59cC3E7A49DdC4893eB8754c7908f96072A7DbE8",
"staticAggregationIsmFactory": "0x40c6Abcb6A2CdC8882d4bEcaC47927005c7Bb8c2",
"staticMerkleRootMultisigIsmFactory": "0xE2f485bc031Feb5a4C41C1967bf028653d75f0C3",
"staticMessageIdMultisigIsmFactory": "0x84Df48F8f241f11d0fA302d09d73030429Bd9C73",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0x448b7ADB0dA36d41AA2AfDc9d63b97541A7b3819",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Update key funder deployments w/ RpcConsensusType.Fallback, fix with ESM (#3583) ### Description Making testnet4 and mainnet3 key funder use fallback for consistency & robustness ### Drive-by changes Updated the deployed key funder images
8 months ago
"transactionOverrides": {
Set prio fee override for moonbeam (#3587) ### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"maxFeePerGas": 350000000000,
"maxPriorityFeePerGas": 50000000000
Update key funder deployments w/ RpcConsensusType.Fallback, fix with ESM (#3583) ### Description Making testnet4 and mainnet3 key funder use fallback for consistency & robustness ### Drive-by changes Updated the deployed key funder images
8 months ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x8c1001eBee6F25b31863A55EadfF149aF88B356F"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"neutron": {
"bech32Prefix": "neutron",
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"blockExplorers": [
{
"apiUrl": "https://www.mintscan.io/neutron",
"family": "other",
"name": "Mintscan",
"url": "https://www.mintscan.io/neutron"
}
],
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"blocks": {
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"confirmations": 1,
"estimateBlockTime": 3,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"reorgPeriod": 1
},
"canonicalAsset": "untrn",
"chainId": "neutron-1",
"contractAddressBytes": 32,
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"displayName": "Neutron",
"domainId": 1853125230,
"gasCurrencyCoinGeckoId": "neutron-3",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"gasPrice": {
Update IGP gas oracles with new heuristics, get Cosmos gas prices from registry (#3662) ### Description The original and main motivation of this PR was to feel confident when running `deploy.ts -m igp` off of main. Prior to this, running it off main could result in misconfiguring gas oracles, particularly when it came to non-EVM remotes. See https://github.com/hyperlane-xyz/issues/issues/1178 for some context. This PR does a number of things: - Fetches Cosmos gas prices from the Cosmos registry - the `gasPrices.json` now lets you specify the decimals relating to the amount in there. There are 2 reasons for this: it's easier for us to deal with gwei values for EVM chains (as we often end up manually changing these instead of just relying on the script). The second reason is covered in the next bullet - Handles decimals when it comes to gas prices. The existing tooling assumed gas prices would always be denominated in wei. An extra weird situation arises with non-EVM chains: chains like Neutron have gas prices that are quotes in the smallest denomination (ie the equivalent of "wei" for NTRN), but the gas price is not an integer and is very small, e.g. `0.0053`. This poses issues because the IGP contracts require the gas price that's configured onchain to be an integer. Simply rounding up from 0.0053 to 1 results in almost 2 orders of magnitude difference :(. So the solution here is to have some logic that accommodates really tiny gas prices by scaling up the configured gas price and scaling down the configured token exchange rate. - Applies some "non-linear" gas pricing heuristics. See https://github.com/hyperlane-xyz/issues/issues/1204 and https://discord.com/channels/935678348330434570/935678739663192184/1232293417309044818 for some context - Running `update-agent-config.ts` will fetch gas prices for Cosmos chains from the Cosmos registry and ensure they're accurate ### Drive-by changes Some logging messages when applying IGP gas oracle changes to make it more clear what the change actually does ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3386 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3484 - Fixes https://github.com/hyperlane-xyz/issues/issues/1178 - Fixes https://github.com/hyperlane-xyz/issues/issues/1206 - Fixes https://github.com/hyperlane-xyz/issues/issues/1204 ### Backward compatibility Fully backward compatible ### Testing Ran deploy.ts for the IGP on all chains! --------- Co-authored-by: nambrot <nambrot@googlemail.com>
7 months ago
"amount": "0.0053",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"denom": "untrn"
},
"grpcUrls": [
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"http": "http://grpc-kralum.neutron-1.neutron.org:80"
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
}
],
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"chunk": 50,
"from": 4000000
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x504ee9ac43ec5814e00c7d21869a90ec52becb489636bdf893b7df9d606b5d67",
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"isTestnet": false,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x848426d50eb2104d5c6381ec63757930b1c14659c40db8b8081e516e7c5238fc",
"merkleTreeHook": "0xcd30a0001cc1f436c41ef764a712ebabc5a144140e3fd03eafe64a9a24e4e27c",
"name": "neutron",
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"nativeToken": {
"decimals": 6,
"denom": "untrn",
"name": "Neutron",
"symbol": "NTRN"
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocol": "cosmos",
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"restUrls": [
{
"http": "https://rest-lb.neutron.org"
}
],
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
"rpcUrls": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"http": "https://rpc-kralum.neutron-1.neutron.org"
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
}
],
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"signer": {
"key": "0x5486418967eabc770b0fcb995f7ef6d9a72f7fc195531ef76c5109f44f51af26",
"prefix": "neutron",
"type": "cosmosKey"
},
fix: use secret RPC urls in infra, apply environment-specific registry overrides (#3875) ### Description A while back, it seems secret RPC URLs stopped being used by monorepo services (see https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3179/files#diff-ba3b7bea2b5c046acd88d25ed382df875b49d77e061f2ef8347ffcc741c0353eR34). This adds them back. Some things to note on the approach: - Sadly, due to the way some of the infra config generation works, we're forced to use synchronous interfaces for getting chain metadata in a bunch of places. This is why `getRegistry` returns a `FileSystemRegistry`, which is a `SynchronousRegistry`. - Applying secrets / overrides requires us to do things async for two reasons -- one is just that fetching from GCP secrets is an async operation, the other is that a `MergedRegistry` is not a `SynchronousRegistry`. The approach I've taken is that there are two ways of getting a registry - using `getRegistry` will give the synchronous version that can continue to be used by our sync config generation, but it won't have any environment-specific overrides (tx overrides or secrets). To get an async registry with environment-specific overrides, the `getRegistry` function on the EnvironmentConfig is used. - Overrides are now more succinct as the merging happens later in the pipeline ### Drive-by changes - Started moving away from using the gcloud CLI under the hood for GCP operations and toward using the GCP secret SDK - Updated the mainnet3 key funder to fix an incident, but will follow up with a fresh deploy once this is mergd ### Related issues - These are the code changes for https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3774, but I'll follow up with fresh deploys for the monorepo services ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: Connor McEwen <connor.mcewen@gmail.com> Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: J M Rossy <jm.rossy@gmail.com>
6 months ago
"slip44": 118,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0xf3aa0d652226e21ae35cd9035c492ae41725edc9036edf0d6a48701b153b90a0"
Injective / inevm agent code & config changes (#3185) ### Description Taken from https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 but without any of the ancillary things like changes to the SDK or infra. Merging to get an image off `main` that works w/ injective. Branch plan is: - after this is merged, an image off main can be used to run an agent against injective/inevm - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3140 will have all the SDK changes from the contract deployments - https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3155 will have the infra changes to start deploying injective / inevm validators / relayer ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
10 months ago
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"optimism": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x4ccC6d8eB79f2a1EC9bcb0f211fef7907631F91f",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api-optimistic.etherscan.io/api",
"family": "etherscan",
"name": "Etherscan",
"url": "https://optimistic.etherscan.io"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
"reorgPeriod": 0
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 10,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Optimism",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 10,
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0xD2e905108c5e44dADA680274740f896Ea96Cf2Fb",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0xD4b132C6d4AA93A4247F1A91e1ED929c0572a43d",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "ethereum",
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-optimism.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 111290758
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x0389faCac114023C123E22F3E54394944cAbcb48",
"interchainAccountRouter": "0x33Ef006E7083BB38E0AFe3C3979F4e9b84415bf1",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0xD8A76C4D91fCbB7Cc8eA795DFDF870E48368995C",
"interchainSecurityModule": "0x04938856bE60c8e734ffDe5f720E2238302BE8D2",
"mailbox": "0xd4C1905BB1D26BC93DAC913e13CaCC278CdCC80D",
"merkleTreeHook": "0x68eE9bec9B4dbB61f69D9D293Ae26a5AACb2e28f",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "optimism",
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "Ether",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"symbol": "ETH"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0xf753CA2269c8A7693ce1808b5709Fbf36a65D47A",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xD71Ff941120e8f935b8b1E2C1eD72F5d140FF458",
"proxyAdmin": "0xE047cb95FB3b7117989e911c6afb34771183fC35",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
"http": "https://mainnet.optimism.io"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x15DEeAB8dECDe553bb0B1F9C00984cbcae1af3D7",
"staticAggregationIsmFactory": "0x7491843F3A5Ba24E0f17a22645bDa04A1Ae2c584",
"staticMerkleRootMultisigIsmFactory": "0xCA6Cb9Bc3cfF9E11003A06617cF934B684Bc78BC",
"staticMessageIdMultisigIsmFactory": "0xAa4Be20E9957fE21602c74d7C3cF5CB1112EA9Ef",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0x27e88AeB8EA4B159d81df06355Ea3d20bEB1de38",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x30f5b08e01808643221528BB2f7953bf2830Ef38"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
feat: add agent config for Osmosis Mainnet (#3825) ### Description - Added agent config description for Osmosis Mainnet - Updated infra test to allow agent config chains to be a superset of infra chains Taken from @byeongsu-hong's https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3766, but with a fixed test ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests --> --------- Co-authored-by: byeongsu-hong <hong@byeongsu.dev>
6 months ago
"osmosis": {
"bech32Prefix": "osmo",
"blocks": {
"reorgPeriod": 1
},
"canonicalAsset": "uosmo",
"chainId": "osmosis-1",
"contractAddressBytes": 32,
"domainId": "875",
"gasPrice": {
"amount": "0.025",
"denom": "uosmo"
},
"grpcUrls": [
{
"http": "https://osmosis-grpc.publicnode.com:443"
}
],
"index": {
"from": 14389169
},
"interchainGasPaymaster": "0xd20a9dcf61939fc2fe6ad501b9457b1029b3cc7ab12ed72675ea2e10d831ee5d",
"mailbox": "0x9493e39d85dd038022f97d88aba6bff98d98f9a016b4f2e498bf1d9898420172",
"merkleTreeHook": "0x8920e062ee5ed8afccbc155d13ea9049296399ee41403655864fcd243edc7388",
"name": "osmosis1",
"protocol": "cosmos",
"rpcUrls": [
{
"http": "https://osmosis-rpc.publicnode.com:443"
}
],
"validatorAnnounce": "0xaf867da5b09a20ee49161d57f99477c0c42d100f34eb53da0d2eb7fc6c257235"
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"polygon": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x34dAb05650Cf590088bA18aF9d597f3e081bCc47",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.polygonscan.com/api",
"family": "etherscan",
"name": "PolygonScan",
"url": "https://polygonscan.com"
}
],
"blocks": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"confirmations": 3,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"estimateBlockTime": 2,
"reorgPeriod": 256
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 137,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Polygon",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 137,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0xBcb9d74E1D2549fc1939023433aaAB11587bc338",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x0d0E816eE4557689d34fAd5885C53b9393C1D9fA",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0xca4cCe24E7e06241846F5EA0cda9947F0507C40C",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "matic-network",
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-polygon.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 49108065
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0x90384bC552e3C48af51Ef7D9473A9bF87431f5c7",
"interchainAccountRouter": "0x5e80f3474825B61183c0F0f0726796F589082420",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x0071740Bf129b05C4684abfbBeD248D80971cce2",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0xe289bD204Dbb4F3aaFA27Dbe5751C71e101CFD80",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x5d934f4e2f797775e53561bB72aca21ba36B96BB",
"merkleTreeHook": "0x73FbD25c3e817DC4B4Cd9d00eff6D83dcde2DfF6",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "polygon",
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
chore: fix mainnet3 agent config (#3931) chore: fix mainnet3 agent config follow-on from https://github.com/hyperlane-xyz/hyperlane-registry/pull/49 Signed-off-by: Paul Balaji <paul@hyperlane.xyz>
6 months ago
"name": "Matic",
"symbol": "MATIC"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0x748040afB89B8FdBb992799808215419d36A0930",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableIsm": "0x6741e91fFDC31c7786E3684427c628dad06299B0",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xF8F3629e308b4758F8396606405989F8D8C9c578",
"proxyAdmin": "0xC4F7590C5d30BE959225dC75640657954A86b980",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"http": "https://polygon-bor.publicnode.com"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
{
"http": "https://polygon-rpc.com"
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
{
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"http": "https://rpc.ankr.com/polygon"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xFeeB86e70e4a640cDd29636CCE19BD6fe8628135",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0xe289bD204Dbb4F3aaFA27Dbe5751C71e101CFD80",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x81AdDD9Ca89105063DaDEBd5B4408551Ce850E22",
"staticMerkleRootMultisigIsmFactory": "0xa9E0E18E78b098c2DE36c42E4DDEA13ce214c592",
"staticMessageIdMultisigIsmFactory": "0xEa5Be2AD66BB1BA321B7aCf0A079fBE304B09Ca0",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0xA3a24EC5670F1F416AB9fD554FcE2f226AE9D7eB",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"testRecipient": "0x36FdA966CfffF8a9Cdc814f546db0e6378bFef35",
"testTokenRecipient": "0x85ac1164878e017b67660a74ff1f41f3D05C02Bb",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"transactionOverrides": {
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"maxFeePerGas": 550000000000,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"maxPriorityFeePerGas": 50000000000
},
"validatorAnnounce": "0x454E1a1E1CA8B51506090f1b5399083658eA4Fc5"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
"polygonzkevm": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x8464aF853363B8d6844070F68b0AB34Cb6523d0F",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api-zkevm.polygonscan.com/api",
"family": "etherscan",
"name": "PolygonScan",
"url": "https://zkevm.polygonscan.com"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 10,
"reorgPeriod": 1
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 1101,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Polygon zkEVM",
"displayNameShort": "zkEVM",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 1101,
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0xe4057c5B0c43Dc18E36b08C39B419F190D29Ac2d",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0x01aE937A7B05d187bBCBE80F44F41879D3D335a4",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "ethereum",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"gnosisSafeTransactionServiceUrl": "https://safe-transaction-zkevm.safe.global/",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
"from": 6577743
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0xC49aF4965264FA7BB6424CE37aA06773ad177224",
"interchainAccountRouter": "0xF15D70941dE2Bf95A23d6488eBCbedE0a444137f",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x0D63128D887159d63De29497dfa45AFc7C699AE4",
"interchainSecurityModule": "0xf2BEE9D2c15Ba9D7e06799B5912dE1F05533c141",
"mailbox": "0x3a464f746D23Ab22155710f44dB16dcA53e0775E",
"merkleTreeHook": "0x149db7afD694722747035d5AEC7007ccb6F8f112",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "polygonzkevm",
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "Ether",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"symbol": "ETH"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0xc2FbB9411186AB3b1a6AFCCA702D1a80B48b197c",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xd83A4F747fE80Ed98839e05079B1B7Fe037b1638",
"proxyAdmin": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"http": "https://zkevm-rpc.com"
},
{
"http": "https://rpc.ankr.com/polygon_zkevm"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
"staticAggregationIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
"staticMerkleRootMultisigIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMessageIdMultisigIsmFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0x19dc38aeae620380430C200a6E990D5Af5480117",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x2fa5F5C96419C222cDbCeC797D696e6cE428A7A9"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"redstone": {
"blockExplorers": [
{
"apiUrl": "https://explorer.redstone.xyz/api",
"family": "blockscout",
"name": "Redstone Explorer",
"url": "https://explorer.redstone.xyz"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 2,
"reorgPeriod": 0
},
"chainId": 690,
"displayName": "Redstone",
"domainId": 690,
"domainRoutingIsmFactory": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
"fallbackRoutingHook": "0xA1ac41d8A663fd317cc3BD94C7de92dC4BA4a882",
"gasCurrencyCoinGeckoId": "ethereum",
"index": {
"from": 1797579
},
"interchainGasPaymaster": "0x2Fa570E83009eaEef3a1cbd496a9a30F05266634",
"interchainSecurityModule": "0xF4689C7fA4920C91a6EEEd59630C9C8da7a77D40",
"mailbox": "0xeA87ae93Fa0019a82A727bfd3eBd1cFCa8f64f1D",
"merkleTreeHook": "0x8F1E22d309baa69D398a03cc88E9b46037e988AA",
"name": "redstone",
"nativeToken": {
"decimals": 18,
"name": "Ether",
"symbol": "ETH"
},
"pausableHook": "0xC9B8ea6230d6687a4b13fD3C0b8f0Ec607B26465",
"protocol": "ethereum",
"protocolFee": "0x26f32245fCF5Ad53159E875d5Cae62aEcf19c2d4",
"proxyAdmin": "0x4Ed7d626f1E96cD1C0401607Bf70D95243E3dEd1",
"rpcUrls": [
{
"http": "https://rpc.redstonechain.com"
}
],
"staticAggregationHookFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
"staticAggregationIsmFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
"staticMerkleRootMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
"staticMessageIdMultisigIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"storageGasOracle": "0x6Fae4D9935E2fcb11fC79a64e917fb2BF14DaFaa",
"testRecipient": "0x1Ab68dC4f7b6cfcd00218D4b761b7F3b5a724555",
"validatorAnnounce": "0x12582c7B0f43c6A667CBaA7fA8b112F7fb1E69F0"
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"scroll": {
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"aggregationHook": "0x9Bc0FAf446E128a618A88a2F28960Fb2Ca169faE",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"blockExplorers": [
{
"apiUrl": "https://api.scrollscan.com/api",
"family": "etherscan",
"name": "Scroll Explorer",
"url": "https://scrollscan.com/"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
"reorgPeriod": 1
},
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"chainId": 534352,
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"displayName": "Scroll",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"domainId": 534352,
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0xe03dad16074BC5EEA9A9311257BF02Eb0B6AAA2b",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"fallbackRoutingHook": "0xDa7cECb05C4aeB02c1aFDE277d4306a2da7Bd762",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"gasCurrencyCoinGeckoId": "ethereum",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"gnosisSafeTransactionServiceUrl": "https://transaction.safe.scroll.xyz",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"index": {
Update gas oracles, deploy agents (#3755) ### Description - Updates gas oracles to make messages to Scroll slightly cheaper - After running into issues configuring non-EVM remotes in the IGP / gas oracle tooling (see https://discord.com/channels/935678348330434570/1238439687165579264), added a temporary band aid of just try/catching. We'll want to fix this at some point in the future - Deploys agents with a new image - Updates the agent JSON configs with some params we were running the agents with in prod via env vars - Adjusts kathy frequency on testnet to send every 1.5hrs instead of 7hrs - Stops running eclipsetestnet agents - apparently there was a reset ### Drive-by changes Some drive-by logging changes ### Related issues n/a ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"chunk": 999,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"from": 271840
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0xb89c6ED617f5F46175E41551350725A09110bbCE",
"interchainAccountRouter": "0x9629c28990F11c31735765A6FD59E1E1bC197DbD",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0xBF12ef4B9f307463D3FB59c3604F294dDCe287E2",
"interchainSecurityModule": "0xaDc0cB48E8DB81855A930C0C1165ea3dCe4Ba5C7",
"mailbox": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"merkleTreeHook": "0x6119E37Bd66406A1Db74920aC79C15fB8411Ba76",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "scroll",
"nativeToken": {
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"decimals": 18,
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"name": "Ether",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"symbol": "ETH"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"pausableHook": "0x4Eb82Ee35b0a1c1d776E3a3B547f9A9bA6FCC9f2",
feat:update deployments to use `FallbackRoutingHook` (#3179) ### Description - mainnet3, testnet4 should be using fallback routing hooks because it's more "porous" for first-time deployers of hyperlane to have merkleTreeHook out of the box ### Drive-by changes - added overrides to configureHook in basedeployer and setHook in hookdeployer - added fetching local rpc first logic in infra/chains and then secrets rpc if needed. This would mean the forking and live setup will be closer as the rpc urls will be the same between the two. ### Related issues None ### Backward compatibility Yes ### Testing Fork
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xc3F23848Ed2e04C0c6d41bd7804fa8f89F940B94",
"proxyAdmin": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"rpcUrls": [
{
"http": "https://scroll.blockpi.network/v1/rpc/public"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
"staticAggregationIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMerkleRootMultisigIsmFactory": "0x2C1FAbEcd7bFBdEBF27CcdB67baADB38b6Df90fC",
"staticMessageIdMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
"storageGasOracle": "0x481171eb1aad17eDE6a56005B7F1aB00C581ef13",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"transactionOverrides": {
"gasPrice": 2000000000
},
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0xd83A4F747fE80Ed98839e05079B1B7Fe037b1638"
Deploy viction core and warp routes (#3067) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
10 months ago
},
"viction": {
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"aggregationHook": "0x5c7890FAf9c99dC55926F00d624D7Bc6D7ac6834",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"blockExplorers": [
{
"apiUrl": "https://www.vicscan.xyz/api",
"family": "other",
"name": "Vicscan",
"url": "https://www.vicscan.xyz"
}
],
Deploy viction core and warp routes (#3067) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
10 months ago
"blocks": {
"confirmations": 1,
"estimateBlockTime": 2,
"reorgPeriod": 0
},
"chainId": 88,
"displayName": "Viction",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"domainId": 88,
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"domainRoutingIsm": "0x477145b11E1a71fEb658d96A0E27F19495121504",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"domainRoutingIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"fallbackRoutingHook": "0x5d69BC38eF3eDb491c0b7186BEc4eC45c4013f93",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"gasCurrencyCoinGeckoId": "tomochain",
"index": {
Update gas oracles, deploy agents (#3755) ### Description - Updates gas oracles to make messages to Scroll slightly cheaper - After running into issues configuring non-EVM remotes in the IGP / gas oracle tooling (see https://discord.com/channels/935678348330434570/1238439687165579264), added a temporary band aid of just try/catching. We'll want to fix this at some point in the future - Deploys agents with a new image - Updates the agent JSON configs with some params we were running the agents with in prod via env vars - Adjusts kathy frequency on testnet to send every 1.5hrs instead of 7hrs - Stops running eclipsetestnet agents - apparently there was a reset ### Drive-by changes Some drive-by logging changes ### Related issues n/a ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
7 months ago
"chunk": 999,
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"from": 73573878
},
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"interchainAccountIsm": "0xD1E267d2d7876e97E217BfE61c34AB50FEF52807",
"interchainAccountRouter": "0x1956848601549de5aa0c887892061fA5aB4f6fC4",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"interchainGasPaymaster": "0x0D63128D887159d63De29497dfa45AFc7C699AE4",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"interchainSecurityModule": "0xf8F3AF5F6B8f319364c339c0b8cA5975481901eD",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"mailbox": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"merkleTreeHook": "0x149db7afD694722747035d5AEC7007ccb6F8f112",
Deploy viction core and warp routes (#3067) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
10 months ago
"name": "viction",
"nativeToken": {
"decimals": 18,
"name": "Viction",
"symbol": "VIC"
},
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"pausableHook": "0xDab56C5A1EffFdd23f6BD1243E457B1575984Bc6",
"pausableIsm": "0x92cdbF0Ccdf8E93467FA858fb986fa650A02f2A8",
Deploy viction core and warp routes (#3067) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
10 months ago
"protocol": "ethereum",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"protocolFee": "0xd83A4F747fE80Ed98839e05079B1B7Fe037b1638",
"proxyAdmin": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
Deploy viction core and warp routes (#3067) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
10 months ago
"rpcUrls": [
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
{
"http": "https://rpc.tomochain.com"
},
Deploy viction core and warp routes (#3067) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
10 months ago
{
"http": "https://viction.blockpi.network/v1/rpc/public"
}
],
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationHookFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
"staticAggregationIsm": "0x60586f0b79426f8F406C807a59c7b6478e8bBa0C",
Agent transaction overrides, ensure agent configs are updated in CI (#3563) ### Description - Adds some basic transaction overrides for Ethereum chains to be used by the agents. This follows the existing config schema in chain metadata that we have been using on the TS side for a while. The overrides are as follows: - `transactionOverrides.gasPrice` - if specified, non EIP-1559 txs are used, and they use this gasPrice - `transactionOverrides.gasLimit` - if specified, this takes precedence over any gas estimation that's done and is the gas limit that's used for txs. (This is pretty niche and I don't imagine we'll ever wanna use this internally, but happens to cover the use case described [here](https://discord.com/channels/935678348330434570/984123861144600587/1224617234580766741), which is nice to cover) - `transactionOverrides.maxFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxFeePerGas` - `transactionOverrides.maxPriorityFeePerGas` - if specified and if the chain supports EIP 1559 txs, is used for the `maxPriorityFeePerGas` - Updates some of the transaction overrides in mainnet3 / testnet4 to be more reasonable now that we'll be using them to submit transactions pretty frequently - Note that atm the transaction overrides are most easily applied to the agents via the config JSONs, and not via our K8s configuration. The upshot of this is if we wanna change a transaction override right now, the easiest way to do it will be to run `update-agent-config.ts` and then build a new image. Created https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3565 to track making this experience better - Part of this change means that it's more important to keep the `transactionOverrides` specified in the SDK / infra up to date with the agent config. So I ended up doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 along the way, which also required doing https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311. - To fix the issue with arbitrum blocks, we now require the index.from to be specified in the chain metadata if the chain's technical stack is arbitrum nitro - A new script, `update-agent-config.ts` is added, and it's ran for mainnet3 and testnet4 in CI to make sure there's no diff (similar idea to what we do with prettier) - Along the way I renamed mainnet3_config.json and testnet4_config.json to mainnet_config.json and testnet_config.json. This has been a source of confusion with ppl in the past - in v2 we named them without any numeric suffixes, so we now just do that again ### Drive-by changes - There's a drive-by to poll more frequently for pending transactions (2 seconds). The default is 7 seconds in Ethers, and for many chains that have really quick block times, this may be a way for us to speed up us learning that a transaction is included - Don't enforce gas on the inevm routes, looks like there's some weirdness there that was reported by Nam ### Related issues - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3562 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3311 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
8 months ago
"staticAggregationIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMerkleRootMultisigIsmFactory": "0x2C1FAbEcd7bFBdEBF27CcdB67baADB38b6Df90fC",
"staticMessageIdMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
Deploy viction core and warp routes (#3067) ### Description Deploys core and warp to viction ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/850 - Fixes https://github.com/hyperlane-xyz/issues/issues/859 ### Backward compatibility Yes ### Testing Fork tests --------- Co-authored-by: J M Rossy <jm.rossy@gmail.com> Co-authored-by: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
10 months ago
"storageGasOracle": "0x19dc38aeae620380430C200a6E990D5Af5480117",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"testRecipient": "0x17E216fBb22dF4ef8A6640ae9Cb147C92710ac84",
"testTokenRecipient": "0xe042D1fbDf59828dd16b9649Ede7abFc856F7a6c",
Migrate SDK consts to Registry and use new registry utilities (#3615) ### Description - Remove most consts from SDK - Refactor tests that relied on chainMetadata - Remove JSON imports/exports in the SDK - Update the HelloWorld package to read metadata from the registry lib - Update the Infra package to read/write to a LocalRegistry - Update the CLI to read and write from registries ### Drive-by changes - Fix typo in `EvmHypCollateralVault` token standard - Use consistent, newest yaml lib version ### Related issues Fixes https://github.com/hyperlane-xyz/issues/issues/917 Fixes https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/2810 ### Backward compatibility No: - Several SDK exports like `chainMetadata` have been removed - Common args for the CLI like `--chain` have been replaced with `--registry` and `--overrides`
7 months ago
"timelockController": "0x0000000000000000000000000000000000000000",
Ancient8 deploy (#3472) ### Description - Deploys ancient8 core - Deploys a USDC warp route from Ethereum to ancient8 - Some changes to the key generation step - specifically: - `scripts/create-keys.ts` now expects `--newChainValidators chainname=1` instead of the flag `--newChains` - fixed the logic around adding new validators, which previously was broken - Adds a hook module to deploy.ts - this is meant to be used in a similar fashion to the warp module, where configs are built ad-hoc - changes `aw-multisig.json` to be `aw-multisig-${context}.json`, as previously the entire aw-multisig.json would be overridden no matter what the current context was
8 months ago
"validatorAnnounce": "0x2fa5F5C96419C222cDbCeC797D696e6cE428A7A9"
feat: deploy to zetachain and redstone (#3788) ### Description - Deploys to zetachain and redstone - Some learnings can be found in https://discord.com/channels/935678348330434570/1240168332813144084 Chains not yet fully connected: - inevm (Mailbox ownership situation makes this hard) - mantapacific (waiting on an update to the multisig ownership set there, then will create the tx) - non-EVM chains ### Drive-by changes - decreased ethereum cost from $2 to $1.5 following some feedback - Added Superform to the blast set - Allowed for concurrent deploys I originally had some ugly caching to avoid checking storage gas oracles so much (we check them for each route in a routing hook configuration), but I've removed this. Calling it out for the future though https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/3788/commits/232695dd6cdec054e164a9ab79788b3c43e32cd1 ### Related issues <!-- - Fixes #[issue number here] --> ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing <!-- What kind of testing have these changes undergone? None/Manual/Unit Tests -->
6 months ago
},
"zetachain": {
"blockExplorers": [
{
"apiUrl": "https://explorer.zetachain.com",
"family": "other",
"name": "ZetaScan",
"url": "https://explorer.zetachain.com"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 6,
"reorgPeriod": 0
},
"chainId": 7000,
"displayName": "ZetaChain",
"domainId": 7000,
"domainRoutingIsmFactory": "0x1052eF3419f26Bec74Ed7CEf4a4FA6812Bc09908",
"fallbackRoutingHook": "0x8F1E22d309baa69D398a03cc88E9b46037e988AA",
"gasCurrencyCoinGeckoId": "zetachain",
"index": {
"from": 3068132
},
"interchainGasPaymaster": "0x931dFCc8c1141D6F532FD023bd87DAe0080c835d",
"interchainSecurityModule": "0x8dfE6790DbB2Ecc1bEdb0eECfc1Ff467Ae5d8C89",
"mailbox": "0x2f2aFaE1139Ce54feFC03593FeE8AB2aDF4a85A7",
"merkleTreeHook": "0xE2ee936bEa8e42671c400aC96dE198E06F2bA2A6",
"name": "zetachain",
"nativeToken": {
"decimals": 18,
"name": "ZetaChain",
"symbol": "ZETA"
},
"pausableHook": "0xA1ac41d8A663fd317cc3BD94C7de92dC4BA4a882",
"protocol": "ethereum",
"protocolFee": "0xea820f9BCFD5E16a0dd42071EB61A29874Ad81A4",
"proxyAdmin": "0x0761b0827849abbf7b0cC09CE14e1C93D87f5004",
"rpcUrls": [
{
"http": "https://zetachain-evm.blockpi.network/v1/rpc/public"
},
{
"http": "https://zetachain-athens-evm.blockpi.network/v1/rpc/public"
},
{
"http": "https://zetachain-mainnet-archive.allthatnode.com:8545"
}
],
"staticAggregationHookFactory": "0xEb9FcFDC9EfDC17c1EC5E1dc085B98485da213D6",
"staticAggregationIsmFactory": "0x8F7454AC98228f3504Bb91eA3D8Adafe6406110A",
"staticMerkleRootMultisigIsmFactory": "0x2C1FAbEcd7bFBdEBF27CcdB67baADB38b6Df90fC",
"staticMessageIdMultisigIsmFactory": "0x8b83fefd896fAa52057798f6426E9f0B080FCCcE",
"storageGasOracle": "0xC9B8ea6230d6687a4b13fD3C0b8f0Ec607B26465",
"testRecipient": "0x12582c7B0f43c6A667CBaA7fA8b112F7fb1E69F0",
"validatorAnnounce": "0x48083C69f5a42c6B69ABbAd48AE195BD36770ee2"
Deploy contracts to mainnet3 (#2826) ### Description - Deploys mainnet3 (and removes mainnet2) ### Drive-by changes - Changes protocol fees to 0 - Changes owners to deployer key (temporarily) ### Related issues - closes https://github.com/hyperlane-xyz/issues/issues/655 ### Testing Some v2 related tests broken --------- Co-authored-by: Yorke Rhodes <yorke@hyperlane.xyz> Co-authored-by: Nam Chu Hoai <nambrot@googlemail.com>
1 year ago
}
},
"defaultRpcConsensusType": "fallback"
fix: proxy factory impl names (#3471)
8 months ago
}