Merged
Conversation
…ne-xyz#6148) ### Description Build and submit transaction for EVM chains - Serialise data required to build a ContractCall into byte vector in EthereumMailbox - Desialise data required to build a ContractCall into transaction precursor - Submit transaction to chain using ContractCall ### Drive-by changes - Reformat of workspace Cargo.toml ### Backward compatibility Yes ### Testing None --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description Fix validator announce by pointing to the new `ethers-rs` fork <!-- 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 -->
…old 1.14.20 version (hyperlane-xyz#6158) ### Description Solana CLI releases were migrated from https://release.solana.com to https://release.anza.xyz, but along the way some old versions weren't ported over. This includes 1.14.20, which is the version we require to build the programs. A couple alternatives were considered (trying to use brew to find an older version, more directly querying github, etc), but in the end I think the best approach is to just try to emulate their old installation script and make sure that it fetches from the right github release. This PR adds the installation script adapted from https://release.anza.xyz/v1.18.18/install with the following changes: - The version is hardcoded to 1.14.20 - The URL is hardcoded to read from the old solana-labs repo - All agave references are replaced with solana It also moves away from using the old release.solana.com url to release.anza.xyz when installing newer versions (like 1.18.18). ### 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 -->
…hyperlane-xyz#6143) ### Description This PR updates the `EvmERC20WarpRouteReader` to correctly derive the type of a fiat collateral warp route deployment that was incorrectly inferred as collateral. ### Drive-by changes - Refactors the `fetchTokenConfig` to delegate token config derivation to a separate function instead of having the whole derivation logic in one place with nested if statements ### Related issues - Fixes [ENG-1552](https://linear.app/hyperlane-xyz/issue/ENG-1552/add-derivation-support-for-fiat-collateral-in-the-sdk) ### Backward compatibility - YES ### Testing - Manual - e2e - unit
### Description Implement `GasLimitEstimator` component, by refactoring logic out of `rust/main/chains/hyperlane-ethereum/src/tx.rs` ### Drive-by changes - The logic for the `TxStatusChecker` and `GasLimitEstimator` is moved into their own modules. The motivation is to use dependency injection for ease of testing in the future - The logic for building a `ContractCall` from its subcomponent fields is refactored and reused ### Related issues - Fixes hyperlane-xyz#6134 ### Backward compatibility Yes ### Testing Not yet --------- Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
### Description - deploy to nobletestnet, megaethtestnet, basecamptestnet, bepolia - remove berabartio, camptestnet, treasuretopaz ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues hyperlane-xyz/hyperlane-registry#831 ### 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 manual - base -> megaeth -> op -> basecamp -> monad -> bepolia -> base
### Description Fix message status not being stored correctly. Turns out, instead of storing the new message status, we store the old message status, but set it to the new message status in memory. ### Related issues - fixes: https://linear.app/hyperlane-xyz/issue/ENG-1024/bug-relayer-messages-are-loaded-with-the-wrong-operation-status-from ### Drive-bys - move some dummy test code to be public so other tests can also use them ### Backward compatibility Yes ### Testing - added a test with a temp dir rocksdb to make sure `PendingMessage.set_status()` works as expected
… to fix issue with Neutron chain (hyperlane-xyz#6157) ### Description Scraper is not indexing payments and delivered messages for Neutron chain since it gets serde parsing error when it attempts to request a block by height. The issue was reproduced using unit tests with Neutron RPC and particular block. The issue was fixed by downgrading `CompactMode` from latest version (0.38 at the time of this commit) to version 0.37. HttpClient fails to get block 22488720 from Neutron when `CompactMode::latest()` is used. Latest compact mode at the moment is `V0_38`. It succeeds with `CompactMode::V0.38`. HttpClient succeeds to get block 15317185 from Osmosis when `CompactMode::latest()` is used. Actually, any compact mode works for Osmosis. ### Backward compatibility Yes ### Testing - Unit test of pure parsing of JSON - Unit test of HttpClient to request a block from Neutron - Unit test of CosmosFallbackProvider to request a block from Neutron. --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description Upgraded `@hyperlane-xyz/registry` from v11.1.0 to v14.0.0 across multiple packages and updated warp route config API usage to match the new version requirements. ### Drive-by changes None ### Related issues hyperlane-xyz#5244 ### Backward compatibility Yes ### Testing Manual
### Description This PR refactors the warp route configuration functions to use object parameters instead of positional parameters, improving API clarity and flexibility. The main changes include: - Modified `readWarpRouteDeployConfig` to accept an object parameter with named properties - Updated `readWarpCoreConfig` with similar parameter style changes - Added utility functions for handling warp route configuration in various scenarios - Enhanced context types with warp configuration properties ### Drive-by changes - Added new `getWarpRouteDeployConfig` utility function - Added `useProvidedWarpRouteIdOrPrompt` helper function - Improved error messaging and assertions Diff with last PR: hyperlane-xyz/hyperlane-monorepo@upgrade/registry-14.0.0...refactor/warp-config-loading ### Related issues hyperlane-xyz#5244 hyperlane-xyz#5922 ### Backward compatibility Yes - Internal refactoring only, existing CLI commands work the same way ### Testing Manual testing of CLI commands
### Description Add rule for CryptoCrew ### Backward compatibility Yes ### Testing Manual, locally --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
…lane-xyz#6170) ### Description - Generate contract calls to check if a particular message was delivered - Populate payload success criteria with serialized contract calls - Check if success criteria is met at finality stage of Lander ### Backward compatibility Yes ### Testing None --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description Two things: 1. Updates the commit for our fork of the spl lib that's used to include hyperlane-xyz/solana-program-library#4 which fixes compilation 2. Our tooling generally requires Solana 1.18.18 to be used when running our SVM tooling to perform the program deploy. Eclipse used to allow you to deploy programs just fine with this version but Christopher and I experienced this regression recently where the command just hangs indefinitely. The “workaround” seems to be to downgrade to 1.17.31, but this comes at the cost of not being able to use a CLI flag to set the compute unit price when deploying a program As a temporary fix, bc the compute unit price is originally set to 0 on Eclipse anyways, I'm changing the tooling to omit this compute unit price flag if it’s set to 0. But it’s still possible for us to hit issues here because we bid up compute unit prices if there are issues deploying the program (not a rare occurrence). If you do a deploy to Eclipse and hit issues, I’d recommend just commenting out the compute unit price flag at least for the eclipse leg ### 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 - `cargo +1.76.0 install spl-token-cli --git https://github.com/hyperlane-xyz/solana-program-library --branch dan/create-token-for-mint --rev e101cca --force` works - confirmed not providing the flag works
### Description Instead of inserting all the messages we receive in a single db transaction, we chunk it into smaller sizes. This prevents us from running into `Too many arguments` errors from Postgres for exceeding their `u16::MAX` parameter count. ### Related issues - fixes https://linear.app/hyperlane-xyz/issue/ENG-1390/scraper-cannot-insert-too-many-records ### Backward compatibility Yes ### Testing Manual. From Jeff: Tried it locally with a postgres instance with 100k messages and it failed without chunking ``` running 1 test RES: Err(Query Error: encountered unexpected or invalid data: PgConnection::run(): too many arguments for query: 1000000 (sqlx_postgres::connection::executor:215) Caused by: 0: encountered unexpected or invalid data: PgConnection::run(): too many arguments for query: 1000000 (sqlx_postgres::connection::executor:215) 1: encountered unexpected or invalid data: PgConnection::run(): too many arguments for query: 1000000 (sqlx_postgres::connection::executor:215) Location: agents/scraper/src/db/message.rs:320:9) test db::message::tests::test_store_dispatched_messages_real_postgres ... ok ``` Tried it again with chunking + transaction and it didn't have any errors :+1: So we can use the transaction if we want the action to be atomic, but the important part is the chunking.
…#6177) ### Description **When reviewing, make double sure the changes in `build_with_signer` make sense, otherwise this can break prod** Since the new submitter has its own logic for setting tx parameters, so ethers middleware like the gas escalator, nonce manager, etc isn't required. This PR makes the usage of middleware configurable, via an associated const in `BuildableWithProvider` that defaults to `true`. This const is only ever used if `NEEDS_SIGNER` is `true` ### Drive-by changes Cleans up the provider-building logic in `build_with_signer` ### Related issues - Fixes: hyperlane-xyz#6163 ### Backward compatibility **Yes - but make double sure the changes in `build_with_signer` make sense, otherwise this can break prod** ### Testing EVM E2E
### Description Add naive nonce manager: get current nonce of the account and add the current number of transactions in finality stage. ### Drive-by changes Minor rename and imports improvements ### Backward compatibility Yes ### Testing None --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
…z#6187) ### Description <!-- What's included in this PR? --> Update registry version to 15.0.0 ### 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 -->
### Description This PR refactors warp command options to improve flexibility and configuration handling: - Makes warp deployment config optional instead of requiring a default path - Introduces `getWarpConfigs` utility to centralize configuration handling - Adds support for more optional parameters (symbol, warpRouteId) in warp commands - Improves chain resolution logic for warp operations ### Drive-by changes - Rename `readWarpRouteDeployConfig` to `getWarpRouteDeployConfig` - Remove redundant chain resolution logic from MultiChainResolver - Remove hardcoded default config paths Diff with last PR: hyperlane-xyz/hyperlane-monorepo@refactor/warp-config-loading...refactor/registry-based-warp-config ### Related issues hyperlane-xyz#5244 hyperlane-xyz#5922 ### Backward compatibility Yes - This PR improves flexibility without breaking existing functionality. ### Testing Manual
### Description <!-- What's included in this PR? --> ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues hyperlane-xyz/hyperlane-registry#839 ### 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 -->
### Description Upgrade Relayer and Scraper to latest ### Drive-by changes - Update leak configuration ### Backward compatibility Yes ### Testing None --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description Upgrade Relayer RC and Neutron to latest ### Backward compatibility Yes ### Testing Sync with Hyperlane context Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description - chore: re-enable arcadiatestnet2 scraping - chore: re-enable hyperliduidevmtestnet scraping + relaying ### 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 -->
### Description <!-- What's included in this PR? --> Re-add registry commit to `git fetch origin` in docker-entrypoint.sh ### 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 -->
…lane-xyz#6167) ### Description This PR implements https://linear.app/hyperlane-xyz/issue/ENG-1031/cli-warp-check-should-assert-that-contracts-are-verified which allows `warp check` to determine if a contract has been verified. The details are in the Linear issue. In summary, it does this by expanding the onchain config with a VirtualConfig, which compares to a hardcoded ExpectedVirtualConfig. Example ```bash hl warp check --registry ~/Desktop/code/hyperlane/hyperlane-registry --warpRouteId LUMIA/arbitrum-avalanche-base-bsc-ethereum-lumiaprism-optimism-polygon Hyperlane CLI Hyperlane Warp Check ____________________ lumiaprism: contractVerificationStatus: TransparentUpgradeableProxy: true HypNative: true mailbox: "0x0df25a2d59f03f039b56e90edc5b89679ace28bc" owner: "0xa86c4af592ddaa676f53de278de9cfcd52ae6b39" ... ``` ### Drive-by changes - Add collateralUri and syntheticUrisyntheticUri to hypERC20contracts ### Related issues Resolves https://linear.app/hyperlane-xyz/issue/ENG-1031/cli-warp-check-should-assert-that-contracts-are-verified ### Backward compatibility Yes ### Testing Manual. --------- Co-authored-by: Le <leyu@Les-MacBook-Pro.local> Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
…olation [eng-1555] (hyperlane-xyz#6152) ### Description This PR updates the `transformConfigToCheck` the newly implemented `sortArraysInObject` function to reliably sort all the arrays in a given object recursively. Note that there is already an existing `sortArraysInConfig` function, but it is tightly tied to ism structure,s and updating it might have introduced unexpected bugs in the infra package ### Drive-by changes - None ### Related issues Fixes - [ENG-1555](https://linear.app/hyperlane-xyz/issue/ENG-1552/add-derivation-support-for-fiat-collateral-in-the-sdk) ### Backward compatibility - YES ### Testing - Manual - e2e - unit
…tifacts configs [eng-1088] (hyperlane-xyz#6155) ### Description This PR adds the logic to properly compare the hook and ism configuration depending on whether they are set as an address or a partial config. ### Drive-by changes - Exports the `DerivedWarpRouteDeployConfig` and `DerivedTokenRouterConfig` types from the SDK package - Exports the `derivedHookAddress` and `derivedIsmAddress` from the SDK package - Updates the `runWarpRouteCheck` function signature to have the `onChainConfig` to be of type `DerivedWarpRouteDeployConfig` - Updates the `transformConfigToCheck` function to remove the gas property from the config to check because it is not derived from on-chain config, and if specified in the deploy config, caused false positives (it is ok because the destinationGas field covers this) - Updates the EvmIsmReader to expand an ism config if it contains any addresses instead of the full config ### Related issues - Fixes #[ENG-1553](https://linear.app/hyperlane-xyz/issue/ENG-1553/non-expanded-hook-and-ism-configs-make-cli-checker-fail) ### Backward compatibility - YES ### Testing - Manual - e2e - unit
### 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: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
…hecker [eng-1554] (hyperlane-xyz#6168) ### Description Removes symbol and name token metadata checking in the CLI checker and syncs config getters with the current deployed config on chain to avoid failures due to the registry config being incorrect Companion PR in the registry hyperlane-xyz/hyperlane-registry#841 ### Drive-by changes - Implements the `isCosmosIbcDenomAddress` in the utils package ### Related issues - Fixes #[ENG-1554](https://linear.app/hyperlane-xyz/issue/ENG-1554/metadata-checks-might-cause-cli-checker-to-fail) ### Backward compatibility - YES ### Testing - Manual - unit - e2e
…-xyz#6183) ### Description This PR implements the `keepOnlyDiffObjects` function to format checker's violations to only output fields that have mismatches to avoid cluttering the terminal output for big configs ```shell ethereum: hook: hooks: - protocolFee: EXPECTED: "158365200000000" ACTUAL: "129871800000000" type: protocolFee type: aggregationHook type: xERC20Lockbox swell: hook: hooks: - protocolFee: EXPECTED: "158365200000000" ACTUAL: "129871800000000" type: protocolFee type: aggregationHook type: xERC20 zircuit: hook: hooks: - protocolFee: EXPECTED: "158365200000000" ACTUAL: "129871800000000" type: protocolFee type: aggregationHook type: xERC20 ``` ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes [ENG-1612](https://linear.app/hyperlane-xyz/issue/ENG-1612/reduce-verbosity-in-cli-checker-violations-output) ### Backward compatibility -YES ### Testing - Manual - unit
### Description This PR implements and adds the cosmos native signer strategy to the cli context so users can also sign and deploy to cosmos native chains. Following PRs will use this to support the goal of having full cosmos native support in the hyperlane CLI. Note that this is the second PR of hyperlane-xyz#6050 which is being split up in order to make it easier to review ### Drive-by changes - ### Related issues - ### Backward compatibility Yes ### Testing Manual testing with local cosmos chain
### Description This PR adds the new warp route for Bybit Staked SOL (bbSOL) from Solana to SOON. ### Backward compatibility Yes ### Testing - Manual testing via Rust CLI
### Description feat(infra): misc chain deploy fixes - print per-chain deployment plan - when doing the ism updates, we end up with files that are so big that we error out just trying to write the file. to simplify things, and also make per-chain changes easier to review, i've made the deployment plans per-chain instead of per-deployment. - max batch size of 100 for safe multisend txs - tooling and API downstream starts breaking if there are too many things bundled together in a single multisend tx. in most cases we will be below 100, but recent changes like the TGE owner transfer and the incoming ICA migration will require 400-500 individual actions all going through the eth safe. - remove `checkSafeProposalEligibility` - this was originally a nice-to-have, but actually greatly contributes to the API rate limiting that we encounter with the safe APIs. functionally there is no real difference because `checkTransactionSuccess` is the real meat of the check and that is still there. ### 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 all these changes have been tested and used in several rounds of chain deploys, but just not upstreamed
…6415) ### Description fix(infra): filter out testnets for check-warp-deploy ### 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 -->
### Description This PR adds additional features to the CLIs `--key` flag by allowing protocol specific key inputs. The --key flag will stay backwards compatible and will only work for Ethereum chains. To input keys for Cosmos or Starknet chains in the future users have to specify the protocol they want to provide their key for, example: `core deploy --key.cosmosnative=COSMOS_PK --key.ethereum=ETH_PK`. This allows the CLI to handle multiple private keys for multiple VMs which was not possible before and needed with the first non-EVM protocols joining the monorepo. ### Drive-by changes For whatever reason during a core deploy **all** signers in the registry where initiated. This is now limited that only the one chain where the core gets deployed to gets initiated. See changes in `MultiChainResolver.ts` `resolveCoreDeployChains` ### Related issues hyperlane-xyz#6309 ### Backward compatibility Yes these changes are backwards compatbile, the --key flag can be used as before ### Testing e2e tests
### Description This PR adds the `export-svm-config` script to write the registry config based SVM deploy artifacts. Besides this, the `install-solana.sh` script is made dynamically to use it for different versions. ### Drive-by changes N/A ### Related issues N/A ### Backward compatibility Yes ### Testing Reproduces the same config for already deployed warp routes.
### Description chore(infra): misc fixes for safe operations - used when doing hyperlane-xyz#6358 - correctly add xerc20 lockboxes to the tx parser's xerc20 deployments cache - use entirely offline utilities for determining if an address is a safe (quicker, cleaner code, not prone to hitting rate limits) ### 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 - adding bridges to new prod ousdt xerc20s - parsing eth safe tx ``` yarn tsx scripts/safes/parse-txs.ts -e mainnet3 --governanceType abacusWorks -c ethereum bigint: Failed to load bindings, pure JS will be used (try npm run rebuild?) Fetching pending transactions for safe 0x3965AC3D295641E452E0ea896a086A9cD7C6C5b6 on ethereum ┌─────────┬────────────┬───────┬───────────────────┬──────────────────────────────────────────────────────────────────────┬───────┬───────────┬────────┬───────────────┐ │ (index) │ chain │ nonce │ submissionDate │ fullTxHash │ confs │ threshold │ status │ balance │ ├─────────┼────────────┼───────┼───────────────────┼──────────────────────────────────────────────────────────────────────┼───────┼───────────┼────────┼───────────────┤ │ 0 │ 'ethereum' │ 55 │ 'Fri May 30 2025' │ '0xe06c7fbd4ebc952984637825182f2e73dde1f5a5ded2b71a69de8219aa481090' │ 1 │ 4 │ '🔵' │ '0.20000 ETH' │ └─────────┴────────────┴───────┴───────────────────┴──────────────────────────────────────────────────────────────────────┴───────┴───────────┴────────┴───────────────┘ Reading tx 0xe06c7fbd4ebc952984637825182f2e73dde1f5a5ded2b71a69de8219aa481090 on ethereum Finished reading tx 0xe06c7fbd4ebc952984637825182f2e73dde1f5a5ded2b71a69de8219aa481090 on ethereum ✅✅✅✅✅ No fatal errors ✅✅✅✅✅ Results written to safe-tx-results-1748613693179.yaml ``` ``` ethereum-55-0xe06c7fbd4ebc952984637825182f2e73dde1f5a5ded2b71a69de8219aa481090: chain: ethereum insight: Add new bridge 0xCe19f75BCE7Fb74c9e2328766Ebe50465df24CA3 with buffer cap 20000000000000 and rate limit 5000000000 signature: addBridge((uint112,uint128,address)) to: oUSDT (OpenUSDT, EvmHypVSXERC20, 0x1217BfE6c773EEC6cc4A38b5Dc45B92292B6E189) ```
### Description chore: update to ethers v5.8.0 - https://github.com/ethers-io/ethers.js/releases/tag/v5.8.0 ### 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 -->
### Description This PR transfers tUSD warp route to Nucleus owners ### Backward compatibility Yes
### 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 -->
### Description <!-- What's included in this PR? --> Update SMOL route infra gettings to remove arbitrum ### 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 --> Ran checkers for update configs and deploy config
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @hyperlane-xyz/core@7.1.10 ### Patch Changes - 72887f7: Update to ethers v5.8.0. - Updated dependencies [72887f7] - @hyperlane-xyz/utils@13.2.1 ## @hyperlane-xyz/cli@13.2.1 ### Patch Changes - 72887f7: Update to ethers v5.8.0. ## @hyperlane-xyz/cosmos-sdk@13.2.1 ### Patch Changes - @hyperlane-xyz/cosmos-types@13.2.1 ## @hyperlane-xyz/helloworld@13.2.1 ### Patch Changes - 72887f7: Update to ethers v5.8.0. - Updated dependencies [72887f7] - @hyperlane-xyz/sdk@13.2.1 - @hyperlane-xyz/core@7.1.10 ## @hyperlane-xyz/sdk@13.2.1 ### Patch Changes - 72887f7: Update to ethers v5.8.0. - Updated dependencies [72887f7] - @hyperlane-xyz/utils@13.2.1 - @hyperlane-xyz/core@7.1.10 - @hyperlane-xyz/starknet-core@13.2.1 - @hyperlane-xyz/cosmos-sdk@13.2.1 ## @hyperlane-xyz/utils@13.2.1 ### Patch Changes - 72887f7: Update to ethers v5.8.0. ## @hyperlane-xyz/widgets@13.2.1 ### Patch Changes - Updated dependencies [72887f7] - @hyperlane-xyz/utils@13.2.1 - @hyperlane-xyz/sdk@13.2.1 - @hyperlane-xyz/cosmos-sdk@13.2.1 ## @hyperlane-xyz/starknet-core@13.2.1 ## @hyperlane-xyz/cosmos-types@13.2.1 ## @hyperlane-xyz/ccip-server@13.2.1 ### Patch Changes - 72887f7: Update to ethers v5.8.0. ## @hyperlane-xyz/infra@13.2.1 ### Patch Changes - Updated dependencies [72887f7] - @hyperlane-xyz/helloworld@13.2.1 - @hyperlane-xyz/utils@13.2.1 - @hyperlane-xyz/sdk@13.2.1 ## @hyperlane-xyz/github-proxy@13.2.1 ## @hyperlane-xyz/tsconfig@13.2.1 --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
### Description This PR updates Renzo EZETH prod and stage warp route id to match registry ### Backward compatibility Yes
### Description Renzo has updated their fee hooks causing CLI checker violations. This PR updates the Renzo Hook fees to match onchain. Registry PR: hyperlane-xyz/hyperlane-registry#924 ### Backward compatibility Yes ### Testing Checker
### Description Reduce chunk size to avoid RPC errors ### Backward compatibility Yes ### Testing Manual Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description Prompt user if a new agent key will be created ### Backward compatibility Yes ### Testing Manually --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description - Updates ethers-rs to https://github.com/hyperlane-xyz/ethers-rs/releases/tag/2025-05-30, which includes setting a timeout on the AwsSigner - 30s was chosen because we've seemingly only experienced this once, so it's very infrequent, and high enough to not hit false positives on a timeout ### 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 -->
…lane-xyz#6434) ### Description Upgrade Relayer and Scraper in Testnet Hyperlane and RC ### Backward compatibility Yes ### Testing Manual Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
…yperlane-xyz#6378) ### Description Improved NonceManager so that it is able to track the status of nonce and assign proper nonces to transaction. This implementation in the minimal version of NonceManager which allows E2E to pass with Lander. - Add database to NonceManager - Add signer address to NonceManager - Re-enable Lander Prepare and Confirm tasks in SerialSubmitter - Remove unnecessary tracking of unfinalised transactions in Finality stage More advanced NonceManager will be needed for production use. ### Backward compatibility Yes ### Testing E2E Ethereum tests, Unit tests --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description Rome has restarted their testnet with a different chain id ### Backward compatibility Yes ### Testing None --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
### Description - Updates all testnet4 relayer / validator agents (except for testnet4 neutron relayer) - Adds concurrency of 10 to external-secrets, so it can update 10 secrets concurrently instead of the default of 1 - Removes unnecessary chains from validator external-secrets templates, cutting down on the work that external-secrets needs to do - Makes it a bit safer to work with the external-secrets helm chart ### 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: Danil Nemirovsky <ameten@users.noreply.github.com> Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
### Description A little overdue, quite painful, but better to do it now than keep waiting. Renames: - PayloadDispatcher to Dispatcher (as well as its Entrypoint, module name, etc) - ChainTxAdapter to Adapter (as well as its Factory, module name, etc) - the `submitter` crate to `lander` - `SubmitterError` to `LanderError` - we already had submodules called `dispatcher` and `adapter` inside the `payload_dispatcher` and `chain_tx_adapter` respectively. Those are renamed to `core` ### 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 -->
… cursor (hyperlane-xyz#6436) ### Description It will allow us to set the lowest block height for sequence-aware backward cursor and avoid errors when chain RPC does not provide historical blocks. ### Related issues - Fixes https://linear.app/hyperlane-xyz/issue/ENG-1727/configurable-lower-block-height-limit-to-index-for-sequence-aware ### Backward compatibility Yes ### Testing Unit tests and manual --------- Co-authored-by: Danil Nemirovsky <4614623+ameten@users.noreply.github.com>
…yz#6278) ### Description - prevent `from_settings` from crashing - set chain critical error when contract fails to sync ### Related issues - fixes https://linear.app/hyperlane-xyz/issue/ENG-1650/either-remove-or-catch-unwraps-when-initializing-agents ### Backward compatibility Yes --------- Co-authored-by: Trevor Porter <tkporter4@gmail.com>
### Description feat(sdk): support MultiSend in Safe TX Submitter we do this by default in infra all the time and was caught off guard when I saw individual txs being proposed by the cli ### 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 - used this to propose ousdt txs
…perlane-xyz#6228) ### Description Add two endpoints, one for manually inserting messages and one for manually inserting merkle tree insertions - POST `/messages` ```rust #[derive(Clone, Debug, Deserialize, Serialize)] pub struct Message { pub version: u8, pub nonce: u32, pub origin: u32, pub sender: H256, pub destination: u32, pub recipient: H256, pub body: Vec<u8>, pub dispatched_block_number: u64, } /// Request Body #[derive(Clone, Debug, Deserialize, Serialize)] pub struct RequestBody { pub messages: Vec<Message>, } ``` - GET `/messages` ```rust #[derive(Clone, Debug, Deserialize)] pub struct QueryParams { pub domain_id: u32, pub nonce_start: u32, pub nonce_end: u32, } #[derive(Clone, Debug, Deserialize, Serialize, PartialEq)] pub struct Message { pub version: u8, pub nonce: u32, pub origin: u32, pub sender: H256, pub destination: u32, pub recipient: H256, pub body: Vec<u8>, } #[derive(Clone, Debug, Deserialize, Serialize)] pub struct ResponseBody { pub messages: Vec<Message>, } ``` - POST `/merkle_tree_insertions` ```rust #[derive(Clone, Debug, Deserialize, Serialize)] pub struct TreeInsertion { pub chain: u32, pub insertion_block_number: u64, pub leaf_index: u32, pub message_id: H256, } #[derive(Clone, Debug, Deserialize, Serialize)] pub struct RequestBody { pub merkle_tree_insertions: Vec<TreeInsertion>, } ``` - GET `/merkle_tree_insertions` ```rust #[derive(Clone, Debug, Deserialize)] pub struct QueryParams { pub domain_id: u32, pub leaf_index_start: u32, pub leaf_index_end: u32, } #[derive(Clone, Debug, Deserialize, Serialize, PartialEq)] pub struct TreeInsertion { pub leaf_index: u32, pub message_id: String, } #[derive(Clone, Debug, Deserialize, Serialize)] pub struct ResponseBody { pub merkle_tree_insertions: Vec<TreeInsertion>, } ``` ### Related issues - fixes https://linear.app/hyperlane-xyz/issue/ENG-1643/relayer-create-endpoint-for-manually-inserting-messages-and-merkle ### Backward compatibility Yes ### Testing - unittests to test API endpoints work as intended - e2e test --------- Co-authored-by: Daniel Savu <23065004+daniel-savu@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Drive-by changes
Related issues
Backward compatibility
Testing