Hyperlane

We express our gratitude to the Hyperlane team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Hyperlane is a modular interchain protocol.

The system users should acknowledge all the risks summed up in the risks section of the report

This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.

The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.

There are two different repositories in the project, the repository for the main protocol and the repository for the token standard.

1-Token repository - Warp API

Developers can use Hyperlane's Warp API to permissionlessly deploy "Warp Routes", contracts that allow ERC20 and ERC721 tokens to move effortlessly between chains. Unlike other token wrapping protocols, Warp Routes are secured by a sovereign consensus.

2-Hyperlane Monorepo

Hyperlane is a modular interchain protocol, with various parts:

• Mailbox: Mailbox is the low-level part of the messaging protocol. It is the place where the message arrives and departs from. Relayers are watching the mailbox at all times to look for new messages to route to another chain. Relayers will invoke the Mailbox contract on the target chain to deliver an interchain message.

• Router: The router is the high-level part of the messaging protocol. It is used to interact with the Mailbox contract, and can be extended to offer many capabilities like messaging, bridging tokens and making calls to another chain. The protocol offers Router implementations providing these functionalities: InterchainQueryRouter, InterchainAccountRouter, LiquidityLayerRouter. Routers are built according to a structure that allows them to be deployed to multiple chains without code changes. \-InterchainQueryRouter: used to query the state on remote chains via interchain view calls. \-IterchainAccountRouter: used to create an account on a remote chain, and use that account to call smart contracts. Remote accounts are owned by the protocol. \-LiquidityLayerRouter: used to wrap around several token bridges to allow developers to send tokens alongside their message.

• HyperlaneConnectionClient: mix-in contract that maintains pointers to the three contracts Hyperlane developers may need to interact with: Mailbox (required), InterchainGasPaymaster (optional), InterchainSecurityModule (optional).

• Validators: Validators create the signMailbox merkle roots and make their signatures available to relayers.

• ISM: Interchain security modules (ISMs) are smart contracts that define the security model for an application. They can be user defined or the protocol default ones can be used. At the moment the only ISM provided by the protocol is MultisigIsm, a t-of-n security module. ISMs must implement the verify() interface, which gets called by the Mailbox before delivering a message. If verify() does not return true, the transaction will revert.

• Relayer: aggregates the off-chain metadata needed to deliver messages (e.g. validator signatures and merkle proofs) and submits them to Mailboxes by calling Mailbox.process(), which in turn will invoke IMessageRecipient.handle() on the destination chain Router.

• Watch towers: observe the network for validator fraud. If detected, watchtowers submit evidence to the source chain, slashing the fraudulent validator(s). The slashing process is frictionless because each validator only validates on the chain they are staking on.

This is the execution flow of a general message between chains:

Privileged roles

• Protocol deployer - onlyOwner: the owner of the protocol can set the mailbox, interchain gas payment and interchain security module in the hyperlane connect client, set the default interchain security module in the mailbox, and also pause and unpause the mailbox, enroll a new router in the router contract, enroll, unenroll and set thresholds for validators in the interchain security module, set a liquidity layer adapter in the liquidity layer router contract, and add a domain and add/remove a token in the adapter contract.

• Mailbox - onlyMailbox: can call the handle function in the router.

• Router - onlyRemoteRouter: can be the original sender of a message dispatched to the handle function in the router.

• LiquidityLayerRouter - onlyLiquidityLayerRouter in CircleBridgeAdapter.sol: can send and receive tokens.

The total Documentation quality score is 10 out of 10.

• The documentation is overall clear and complete.

The total Code quality score is 10 out of 10.

• The development environment is configured.

Code coverage of the project is 100% (branch coverage).

• Deployment and basic user interactions are covered with tests.

Upon auditing, the code was found to contain 0 critical, 4 high, 7 medium, and 10 low severity issues. Out of these, 10 issues have been addressed and resolved, leading to a security score of 8 out of 10.

All identified issues are detailed in the “Findings” section of this report.

The comprehensive audit of the customer's smart contract yields an overall score of 8.6. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

hknio/severity-formula →