The home for Hyperlane core contracts, sdk packages, and other infrastructure

blockchain hyperlane interchain monorepo

History

Trevor Porter 9fcd592878 feat: refactor warp monitor to use WarpCore config (#4835 ) ### Description - Removes the warp monitor specific config format and all the handcrafted yamls from infra - Massive refactor to warp monitor to accommodate this -- tried to make it a bit easier to work work by splitting it into a few files. The changes are generally backward compatible with some small exceptions, like now the metrics use the `TokenStandard` instead of `TokenType` (the former is present in the warp core config, the latter isn't, and there's no way atm to map from the former to the latter) - The warp monitor now takes in a warp ID and gets its config from the registry (recall this is the registry version defined in `.registryrc` if running in the monorepo image) - Deploying the warp monitor now lets you do many at a time and select the ones to deploy interactively. This makes it a bit easier to work with the warp IDs - The names of the warp deploys are based on the warp IDs. Because warp IDs can change as new chains are added, this may cause issues in the future - we'll just need to be cautious of removing the old release to avoid accidentally having 2 of them. For now I think this is fine. The helm release names are also capped at 53 chars so they needed to be truncated - Some changes to the SDK to get the necessary data here. Happy to pull some of these into the warp monitor if people feel they're inappropriate for the SDK (like the `getBridgedSupply`) - Added a test to make sure any warp route IDs in infra are found in the registry - Corresponding PR to the registry here https://github.com/hyperlane-xyz/hyperlane-registry/pull/370 ### 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 -->		3 weeks ago
..
scripts	feat(cli): add submit functionality support to warp apply (#4225 )	3 months ago
src	feat: refactor warp monitor to use WarpCore config (#4835 )	3 weeks ago
.eslintrc	Graduate to yarn 4 🧶 (#2899 )	1 year ago
.gitignore	Update sdk gitignore	2 years ago
.mocharc.json	Convert packages from CJS to ESM (#3531 )	8 months ago
.npmignore	Remove abacus- prefix from directories (#267 )	3 years ago
CHANGELOG.md	Version Packages (#4830 )	3 weeks ago
README.md	chore: Merge branch 'main' into cli-2.0 (#3863 )	6 months ago
hardhat.config.cts	Convert packages from CJS to ESM (#3531 )	8 months ago
package.json	Version Packages (#4830 )	3 weeks ago
tsconfig.json	Convert packages from CJS to ESM (#3531 )	8 months ago

README.md

Hyperlane SDK

The Hyperlane SDK helps developers create and manage interchain applications.

For more details on Hyperlane concepts, see the documentation

Install

# Install with NPM
npm install @hyperlane-xyz/sdk

# Or with Yarn
yarn add @hyperlane-xyz/sdk

Note, this package uses ESM Modules

The SDK includes various classes for building, deploying, and testing multi-chain applications. Different abstractions serve different use cases. A few common utilities include:

MultiProvider / MultiProtocolProvider: A utility for managing chain metadata, and RPC providers.
HyperlaneApp / MultiProtocolApp: A base to extend for a multi-chain app.
HyperlaneCore / MultiProtocolCore: A class for common interactions with Hyperlane core deployments.
HyperlaneDeployer: The base class for executing multi-chain contract deployments.
Token & WarpCore: Utilities for interacting with Warp Route deployments.

License

Apache 2.0

README.md

Hyperlane SDK

Install

Contents

License