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.
2172 Commits
486 Branches
322 Tags
226 MiB
Tag: Branch: Tree: ff221f66a0
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'ff221f66a0'
${ noResults }
hyperlane-monorepo/rust/config/testnet_config.json

425 lines
16 KiB
Raw Normal View History Unescape

Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
{
"chains": {
"alfajores": {
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
"aggregationHook": "0xdBabD76358897E68E4964647C1fb8Bf524f5EFdB",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"blockExplorers": [
{
"apiUrl": "https://api-alfajores.celoscan.io/api",
"family": "etherscan",
"name": "CeloScan",
"url": "https://alfajores.celoscan.io"
},
{
"apiUrl": "https://explorer.celo.org/alfajores/api",
"family": "blockscout",
"name": "Blockscout",
"url": "https://explorer.celo.org/alfajores"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 5,
"reorgPeriod": 0
},
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"chainId": 44787,
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"displayName": "Alfajores",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"domainId": 44787,
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": "0x30d9A03762431F8A917a0C469E7A62Bf55092Ca6",
"fallbackRoutingHook": "0x3528B1aeF3a3d29E0eae90ad777A2b4A6a48aC3F",
"index": {
"from": 20231908
},
"interchainAccountIsm": "0x6895d3916B94b386fAA6ec9276756e16dAe7480E",
"interchainAccountRouter": "0xEbA64c8a9b4a61a9210d5fe7E4375380999C821b",
"interchainGasPaymaster": "0x44769b0f4a6f01339e131a691cc2eebbb519d297",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"isTestnet": true,
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
"mailbox": "0xEf9F292fcEBC3848bF4bB92a96a04F9ECBb78E59",
"merkleTreeHook": "0x221FA9CBaFcd6c1C3d206571Cf4427703e023FFa",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"name": "alfajores",
"nativeToken": {
"decimals": 18,
"name": "CELO",
"symbol": "CELO"
},
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"protocol": "ethereum",
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
"protocolFee": "0xC9D50584F08Bf6cCD1004d14c7062044b45E3b48",
"proxyAdmin": "0x4eDBf5846D973c53AF478cf62aB5bC92807521e3",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"rpcUrls": [
{
"http": "https://alfajores-forno.celo-testnet.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": "0x71bB34Ee833467443628CEdFAA188B2387827Cee",
"staticAggregationIsmFactory": "0x4bE8AC22f506B1504C93C3A5b1579C5e7c550D9C",
fix: proxy factory impl names (#3471)
8 months ago
"staticMerkleRootMultisigIsmFactory": "0xa9C7e306C0941896CA1fd528aA59089571D8D67E",
"staticMessageIdMultisigIsmFactory": "0xC1b8c0e56D6a34940Ee2B86172450B54AFd633A7",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"storageGasOracle": "0x8356113754C7aCa297Db3089b89F87CC125499fb",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"testRecipient": "0x6489d13AcAd3B8dce4c5B31f375DE4f9451E7b38",
"testTokenRecipient": "0x92dC0a76452a9D9358D2d2dEd8CddA209DF67c45",
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
"timelockController": "0x0000000000000000000000000000000000000000",
"validatorAnnounce": "0x3726EE36a2A9e11a40d1ffD7D9A1A16e0154cDA0"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
},
"bsctestnet": {
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
"aggregationHook": "0x3d675bB93250Ab7603F40cbb9194bae210784627",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"blockExplorers": [
{
"apiUrl": "https://api-testnet.bscscan.com/api",
"family": "etherscan",
"name": "BscScan",
"url": "https://testnet.bscscan.com"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
"reorgPeriod": 9
},
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"chainId": 97,
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"displayName": "BSC Testnet",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"domainId": 97,
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
"fallbackRoutingHook": "0x2670ED2EC08cAd135307556685a96bD4c16b007b",
"index": {
"from": 34323977
},
"interchainAccountIsm": "0xa9D8Ec959F34272B1a56D09AF00eeee58970d3AE",
"interchainAccountRouter": "0x6d2B3e304E58c2a19f1492E7cf15CaF63Ce6e0d2",
"interchainGasPaymaster": "0x0dD20e410bdB95404f71c5a4e7Fa67B892A5f949",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"isTestnet": true,
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
"mailbox": "0xF9F6F5646F478d5ab4e20B0F910C92F1CCC9Cc6D",
"merkleTreeHook": "0xc6cbF39A747f5E28d1bDc8D9dfDAb2960Abd5A8f",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"name": "bsctestnet",
"nativeToken": {
"decimals": 18,
"name": "BNB",
"symbol": "BNB"
},
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"protocol": "ethereum",
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
"protocolFee": "0x3eF0a63B8976b838704Bcc93C78C56b6653E5a39",
"proxyAdmin": "0xb12282d2E838Aa5f2A4F9Ee5f624a77b7199A078",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"rpcUrls": [
{
DomainRouting and FallbackDomainRouting hooks deployer (#2825) ### Description Add deployer for routing and fallback routing hooks ### Drive-by changes None ### Related issues ### Backward compatibility Yes ### Testing Manual
1 year ago
"http": "https://bsc-testnet.publicnode.com"
},
{
"http": "https://bsc-testnet.blockpi.network/v1/rpc/public"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
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": "0xa1145B39F1c7Ef9aA593BC1DB1634b00CC020942",
"staticAggregationIsmFactory": "0x40613dE82d672605Ab051C64079022Bb4F8bDE4f",
fix: proxy factory impl names (#3471)
8 months ago
"staticMerkleRootMultisigIsmFactory": "0x3E235B90197E1D6b5DB5ad5aD49f2c1ED6406382",
"staticMessageIdMultisigIsmFactory": "0x0D96aF0c01c4bbbadaaF989Eb489c8783F35B763",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"storageGasOracle": "0x124EBCBC018A5D4Efe639f02ED86f95cdC3f6498",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"testRecipient": "0xfbcD1c00a3d809f36cC1A15918694B17B32c0b6c",
"testTokenRecipient": "0x260f6024119549a40595d0937471e607411E8ea5",
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
"timelockController": "0x0000000000000000000000000000000000000000",
"transactionOverrides": {
"gasPrice": 8000000000
},
"validatorAnnounce": "0xf09701B0a93210113D175461b6135a96773B5465"
},
"eclipsetestnet": {
"blocks": {
"confirmations": 1,
"estimateBlockTime": 0.4,
"reorgPeriod": 0
},
"chainId": 239092742,
"displayName": "Eclipse Testnet",
"domainId": 239092742,
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year 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": 1,
"mode": "sequence"
},
"interchainGasPaymaster": "9SQVtTNsbipdMzumhzi6X8GwojiSMwBfqAhS7FgyTcqy",
"isTestnet": true,
"mailbox": "75HBBLae3ddeneJVrZeyrDfv6vb7SMC3aCpBucSXS5aR",
"merkleTreeHook": "75HBBLae3ddeneJVrZeyrDfv6vb7SMC3aCpBucSXS5aR",
"name": "eclipsetestnet",
"nativeToken": {
"decimals": 9,
"name": "Ether",
"symbol": "ETH"
},
"protocol": "sealevel",
"rpcUrls": [
{
"http": "https://testnet.dev2.eclipsenetwork.xyz"
}
],
"validatorAnnounce": "8qNYSi9EP1xSnRjtMpyof88A26GBbdcrsa61uSaHiwx3"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
},
"fuji": {
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
"aggregationHook": "0x8E9b4006171c6B75111823e7545Ee5400CEce0B3",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"blockExplorers": [
{
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
"apiUrl": "https://api.routescan.io/v2/network/testnet/evm/43113/etherscan/api",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"family": "etherscan",
"name": "SnowTrace",
"url": "https://testnet.snowtrace.io"
}
],
"blocks": {
"confirmations": 3,
"estimateBlockTime": 2,
"reorgPeriod": 3
},
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"chainId": 43113,
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"displayName": "Fuji",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"domainId": 43113,
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": "0x683a81E0e1a238dcA7341e04c08d3bba6f0Cb74f",
"fallbackRoutingHook": "0xc684f7F50DB4b2563218512e021fBdd0BeD6b57E",
"index": {
"from": 26503317
},
"interchainAccountIsm": "0xfaB4815BDC5c60c6bD625459C8577aFdD79D9311",
"interchainAccountRouter": "0xeEF6933122894fF217a7dd07510b3D64b747e29b",
"interchainGasPaymaster": "0x6895d3916B94b386fAA6ec9276756e16dAe7480E",
"interchainSecurityModule": "0x4B02673875ba86729f1490247A14A01c4D6B0a67",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"isTestnet": true,
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
"mailbox": "0x5b6CFf85442B851A8e6eaBd2A4E4507B5135B3B0",
"merkleTreeHook": "0x9ff6ac3dAf63103620BBf76136eA1AFf43c2F612",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"name": "fuji",
"nativeToken": {
"decimals": 18,
"name": "Avalanche",
"symbol": "AVAX"
},
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
"pausableHook": "0x495e9E119b2aa848b418EF6A4d30b42803de43A9",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"protocol": "ethereum",
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
"protocolFee": "0xEbA64c8a9b4a61a9210d5fe7E4375380999C821b",
"proxyAdmin": "0x378dA02f7dC3c23A8B5ecE32b8056CdF01e8d477",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"rpcUrls": [
{
"http": "https://api.avax-test.network/ext/bc/C/rpc",
"pagination": {
"maxBlockRange": 2048
}
}
],
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": "0x99554CC33cBCd6EDDd2f3fc9c7C9194Cb3b5df1E",
"staticAggregationIsmFactory": "0xF588129ed84F219A1f0f921bE7Aa1B2176516858",
fix: proxy factory impl names (#3471)
8 months ago
"staticMerkleRootMultisigIsmFactory": "0x93F50Ac4E5663DAAb03508008d592f6260964f62",
"staticMessageIdMultisigIsmFactory": "0x90e1F9918F304645e4F6324E5C0EAc70138C84Ce",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"storageGasOracle": "0x9305dE34306886d615B096Bdf23b94a978f6a6c0",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"testRecipient": "0x44a7e1d76fD8AfA244AdE7278336E3D5C658D398",
"testTokenRecipient": "0x9CC10c844B3Bbae2444E39991aB027C4A05D1F2e",
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
"timelockController": "0x0000000000000000000000000000000000000000",
"validatorAnnounce": "0x4f7179A691F8a684f56cF7Fed65171877d30739a"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
},
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"plumetestnet": {
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
"aggregationHook": "0x31dF0EEE7Dc7565665468698a0da221225619a1B",
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"blockExplorers": [
{
"apiUrl": "https://plume-testnet.explorer.caldera.xyz/api",
"family": "blockscout",
"name": "Plume Testnet Explorer",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"url": "https://plume-testnet.explorer.caldera.xyz"
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
wip: deploy agents to plumetestnet (#3306) ### 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: Trevor Porter <trkporter@ucdavis.edu> Co-authored-by: -f <kunalarora1729@gmail.com>
9 months ago
"reorgPeriod": 0
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
},
"chainId": 161221135,
"displayName": "Plume Testnet",
"domainId": 161221135,
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": "0x54148470292C24345fb828B003461a9444414517",
"fallbackRoutingHook": "0x19Be55D859368e02d7b9C00803Eb677BDC1359Bd",
"index": {
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
"from": 5284139
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
},
"interchainAccountIsm": "0x7c115c16E34c74afdb88bd268EaB19bC705891FE",
"interchainAccountRouter": "0xB6F8aA9B1b314A6E6DFB465DD3e0E95936347517",
"interchainGasPaymaster": "0x28B02B97a850872C4D33C3E024fab6499ad96564",
"interchainSecurityModule": "0x7B40deb01A127E3A5eECdbCDF263e41899a90078",
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"isTestnet": true,
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
"mailbox": "0x33dB966328Ea213b0f76eF96CA368AB37779F065",
"merkleTreeHook": "0xddf4C3e791caCaFd26D7fb275549739B38ae6e75",
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"name": "plumetestnet",
"nativeToken": {
"decimals": 18,
"name": "Ether",
"symbol": "ETH"
},
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
"pausableHook": "0x5821f3B6eE05F3dC62b43B74AB1C8F8E6904b1C8",
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"protocol": "ethereum",
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
"protocolFee": "0x1b33611fCc073aB0737011d5512EF673Bff74962",
"proxyAdmin": "0x589C201a07c26b4725A4A829d772f24423da480B",
"rpcConsensusType": "single",
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"rpcUrls": [
{
"http": "https://plume-testnet.rpc.caldera.xyz/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": "0x6966b0E55883d49BFB24539356a2f8A673E02039",
"staticAggregationIsmFactory": "0xC2E36cd6e32e194EE11f15D9273B64461A4D49A2",
fix: proxy factory impl names (#3471)
8 months ago
"staticMerkleRootMultisigIsmFactory": "0x16B710b86CAd07E6F1C531861a16F5feC29dba37",
"staticMessageIdMultisigIsmFactory": "0x44b764045BfDC68517e10e783E69B376cef196B2",
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"storageGasOracle": "0x267B6B6eAf6790faE5D5E9070F28a9cE64CbF279",
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
"technicalStack": "arbitrumnitro",
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
"testRecipient": "0xe0B988062A0C6492177d64823Ab95a9c256c2a5F",
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
"timelockController": "0x0000000000000000000000000000000000000000",
"transactionOverrides": {
"gasPrice": 1000000
},
"validatorAnnounce": "0x20c44b1E3BeaDA1e9826CFd48BeEDABeE9871cE9"
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
},
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"scrollsepolia": {
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
"aggregationHook": "0x7b63Aa270335F8896717c2A809205F4b650E4268",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"blockExplorers": [
{
"apiUrl": "https://api-sepolia.scrollscan.com/api",
"family": "etherscan",
"name": "Scroll Explorer",
"url": "https://sepolia.scrollscan.dev/"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 3,
"reorgPeriod": 1
},
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"chainId": 534351,
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"displayName": "Scroll Sepolia",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"domainId": 534351,
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": "0x17866ebE0e503784a9461d3e753dEeD0d3F61153",
"fallbackRoutingHook": "0xE1CCB130389f687bf745Dd6dc05E50da17d9ea96",
"index": {
"from": 1344054
},
"interchainAccountIsm": "0xE023239c8dfc172FF008D8087E7442d3eBEd9350",
"interchainAccountRouter": "0xe17c37212d785760E8331D4A4395B17b34Ba8cDF",
"interchainGasPaymaster": "0x86fb9F1c124fB20ff130C41a79a432F770f67AFD",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"isTestnet": true,
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
"mailbox": "0x3C5154a193D6e2955650f9305c8d80c18C814A68",
"merkleTreeHook": "0x863E8c26621c52ACa1849C53500606e73BA272F0",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"name": "scrollsepolia",
"nativeToken": {
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"decimals": 18,
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"name": "Ether",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"symbol": "ETH"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
},
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"protocol": "ethereum",
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
"protocolFee": "0x5821f3B6eE05F3dC62b43B74AB1C8F8E6904b1C8",
"proxyAdmin": "0x598facE78a4302f11E3de0bee1894Da0b2Cb71F8",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"rpcUrls": [
{
"http": "https://sepolia-rpc.scroll.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": "0x44b764045BfDC68517e10e783E69B376cef196B2",
"staticAggregationIsmFactory": "0x16B710b86CAd07E6F1C531861a16F5feC29dba37",
fix: proxy factory impl names (#3471)
8 months ago
"staticMerkleRootMultisigIsmFactory": "0x275aCcCa81cAD931dC6fB6E49ED233Bc99Bed4A7",
"staticMessageIdMultisigIsmFactory": "0xeb6f11189197223c656807a83B0DD374f9A6dF44",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"storageGasOracle": "0x6b1bb4ce664Bb4164AEB4d3D2E7DE7450DD8084C",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"testRecipient": "0xa3AB7E6cE24E6293bD5320A53329Ef2f4DE73fCA",
"testTokenRecipient": "0xc76E477437065093D353b7d56c81ff54D167B0Ab",
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
"timelockController": "0x0000000000000000000000000000000000000000",
"validatorAnnounce": "0x527768930D889662Fe7ACF64294871e86e4C2381"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
},
"sepolia": {
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
"aggregationHook": "0xe3147d5618f5e2e100690B50ec923009a4cde14A",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"blockExplorers": [
{
"apiUrl": "https://api-sepolia.etherscan.io/api",
"family": "etherscan",
"name": "Etherscan",
"url": "https://sepolia.etherscan.io"
}
],
"blocks": {
"confirmations": 1,
"estimateBlockTime": 13,
"reorgPeriod": 2
},
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"chainId": 11155111,
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"displayName": "Sepolia",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"domainId": 11155111,
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": "0x3F100cBBE5FD5466BdB4B3a15Ac226957e7965Ad",
"fallbackRoutingHook": "0x17Dc724B7a2F09141C13b8AC33B396073785c2BC",
"index": {
"from": 4517401
},
"interchainAccountIsm": "0x83a3068B719F764d413625dA77468ED74789ae02",
"interchainAccountRouter": "0x8e131c8aE5BF1Ed38D05a00892b6001a7d37739d",
"interchainGasPaymaster": "0x6f2756380FD49228ae25Aa7F2817993cB74Ecc56",
"interchainSecurityModule": "0x958124472b14B7940Ed5317C44a2508791dB1d48",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"isTestnet": true,
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
"mailbox": "0xfFAEF09B3cd11D9b20d1a19bECca54EEC2884766",
"merkleTreeHook": "0x4917a9746A7B6E0A57159cCb7F5a6744247f2d0d",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"name": "sepolia",
"nativeToken": {
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"decimals": 18,
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"name": "Ether",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"symbol": "ETH"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
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
"pausableHook": "0xa68022e53Fd28119D07C8336a8eC84A298Fd38Fd",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"protocol": "ethereum",
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
"protocolFee": "0x13AC3349Cb159fE86A22cf42DdA803D9f7309DB5",
"proxyAdmin": "0x97Bbc6bBaFa5Ce3b2FA966c121Af63bD09e940f8",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"rpcUrls": [
{
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"http": "https://ethereum-sepolia.publicnode.com"
DomainRouting and FallbackDomainRouting hooks deployer (#2825) ### Description Add deployer for routing and fallback routing hooks ### Drive-by changes None ### Related issues ### Backward compatibility Yes ### Testing Manual
1 year ago
},
{
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"http": "https://ethereum-sepolia.blockpi.network/v1/rpc/public"
DomainRouting and FallbackDomainRouting hooks deployer (#2825) ### Description Add deployer for routing and fallback routing hooks ### Drive-by changes None ### Related issues ### Backward compatibility Yes ### Testing Manual
1 year ago
},
{
"http": "https://rpc.sepolia.org"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
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": "0x160C28C92cA453570aD7C031972b58d5Dd128F72",
"staticAggregationIsmFactory": "0xC83e12EF2627ACE445C298e6eC418684918a6002",
fix: proxy factory impl names (#3471)
8 months ago
"staticMerkleRootMultisigIsmFactory": "0x0a71AcC99967829eE305a285750017C4916Ca269",
"staticMessageIdMultisigIsmFactory": "0xFEb9585b2f948c1eD74034205a7439261a9d27DD",
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
"storageGasOracle": "0x71775B071F77F1ce52Ece810ce084451a3045FFe",
feat: deploy ETH warp route between `plumetestnet` and `sepolia` (#3285) ### Description PlumeTestnet <> Sepolia (Synthetic vs Native) ### Drive-by changes Added artifacts to core deployment for sepolia for adding plume which I missed in the original core deployment PR. ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1014 ### Backward compatibility Yes ### Testing Manual
9 months ago
"testRecipient": "0xeDc1A3EDf87187085A3ABb7A9a65E1e7aE370C07",
"testTokenRecipient": "0x031AD9c560D37baC7d6Bd2d27A2443bAfd10101A",
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
"timelockController": "0x0000000000000000000000000000000000000000",
"validatorAnnounce": "0xE6105C59480a1B7DD3E4f28153aFdbE12F4CfCD9"
Deploy eclipse testnet (#3172) ### 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: Trevor Porter <trkporter@ucdavis.edu>
10 months ago
},
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 months ago
"solanatestnet": {
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
"blockExplorers": [
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 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
"apiUrl": "https://explorer.solana.com?cluster=testnet",
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
"family": "other",
"name": "Solana Explorer",
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
"url": "https://explorer.solana.com?cluster=testnet"
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 months 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
"blocks": {
"confirmations": 1,
"estimateBlockTime": 0.4,
"reorgPeriod": 0
},
"chainId": 1399811150,
"displayName": "Solana Testnet",
"displayNameShort": "Sol Testnet",
"domainId": 1399811150,
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 months ago
"index": {
"from": 1,
"mode": "sequence"
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
},
"interchainGasPaymaster": "9SQVtTNsbipdMzumhzi6X8GwojiSMwBfqAhS7FgyTcqy",
"isTestnet": true,
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 months ago
"mailbox": "75HBBLae3ddeneJVrZeyrDfv6vb7SMC3aCpBucSXS5aR",
"merkleTreeHook": "75HBBLae3ddeneJVrZeyrDfv6vb7SMC3aCpBucSXS5aR",
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
"name": "solanatestnet",
"nativeToken": {
"decimals": 9,
"name": "Sol",
"symbol": "SOL"
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 months 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
"protocol": "sealevel",
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 months ago
"rpcUrls": [
{
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
"http": "https://api.testnet.solana.com"
Separate agent chain configurations, re-add some chains to infra, fix eclipsetestnet & solanatestnet configs (#3327) ### Description - solanatestnet and eclipsetestnet were accidentally moved in the agent JSON to not be in the `chains` object. This moves them back to the right place, and adds a test in `infra` to make sure that the agent JSON chains exactly match the environment chain names. There's opportunity for future improvement for exact consistency between TS artifacts / chain metadata and what exists in the agent JSONs, this is tracked here https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3325 - Adds back eclipsetestnet, solanatestnet, and mumbai to the list of testnet4 chains. These seem to have been accidentally removed - I guess we never deployed to mainnet3 since we started writing to aw-multisig.json. So this writes mainnet chains for the first time - Made some modest fixes to the address persistence logic: - Previously, it didn't handle AWS & GCP keys for the same role well. For non-EVM chains, we have a GCP version of a key for submitting transactions. These exist for relayers, kathy, and validators. This resulted in contention for the relayer key - sometimes the GCP key would get written, sometimes the AWS key. For validators, we'd write both the validator checkpoint signer (AWS) and the chain signer (GCP). Now we just flat out prefer the AWS key. We already only wrote the address persistence with EVM keys in mind, so this isn't a regression - Moves to very explicitly specifying which chains will be ran on the `hyperlane` context agents - Instead of sharing a list of chains for both agents and all contract management, now it's separate. This avoids us making quick fixes and removing e.g. non-EVM chains to make ethereum-specific contract tooling happy, but accidentally removing agent support for these chains - Each chain must be specified for each role in an `AgentChainConfig` indicating whether that chain is enabled. This being consistent with the environment's chain names is enforced at runtime & in a test that's ran in CI. Explicitly indicating whether a chain is supported or not and keeping this consistent will hopefully result in fewer unintentional changes to sets of configured chains - This also allows us during partner integrations to merge a PR with the contract deploy but without necessarily running agents yet. We can just set the chain as disabled to not deploy to it ### Drive-by changes - Removes the `disabled` property for chains in our infra - this is no longer a thing and isn't needed anymore ### Related issues Fixes #3326 Fixes #2572 ### 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 -->
9 months 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
"validatorAnnounce": "8qNYSi9EP1xSnRjtMpyof88A26GBbdcrsa61uSaHiwx3"
Stash deploy progress (#2783) ### Description - Deployer changes and artifacts from testnet4 deployment ### Drive-by changes - a single external-secrets instance lives on the cluster, and we are running testnet3 and testnet4 on the same cluster - json parsing errors were silently swallowed, moved to `mustFromJson` to prevent this ### Drive-by changes ### Backward compatibility Yes ### Testing Manual --------- Co-authored-by: Trevor Porter <trkporter@ucdavis.edu>
1 year ago
}
},
"defaultRpcConsensusType": "fallback"
feat:deploy on Plume testnet (#3260) ### Description Finished core deployment on Plume testnet following the run book NB: - The fork tests doesn't use SmartProvider which gives slight discrepancies between the actual deployment and forked deployment like different revert reasons - postDeploy doesn't filter out chain if given as a param to the script ### Drive-by changes None ### Related issues - fixes https://github.com/hyperlane-xyz/issues/issues/1011 ### Backward compatibility Yes ### Testing None
9 months ago
}