This package contains Solidity Smart Contract code for the Hashflow protocol. This code is compatible with EVM chains (e.g. Ethereum, Arbitrum).
Compiling the code:
yarn hardhat compile
Running unit tests:
yarn hardhat test
HashflowWormholeMessenger contract takes the following two parameters for deployment:
- the Hashflow Chain ID (this is different from the EVM Chain ID and the Wormhole Chain ID)
HashflowRouteraddress on the specific chain
Hashflow Chain IDs should be configured as such:
|Chain||Hashflow Chain ID|
wormhole-messenger:deploy task can be used to deploy the contract.
Every Wormhole message is created by making a call to an endpoint contract deployed by Wormhole. The address of the endpoint contract for each chain is as follows:
wormhole-messenger:initialize:wormhole task can be used to initialize the Wormhole contract.
Wormhole Guardians use the consistency level to determine when to emit the VAA. Different consistency levels come with different risks / guarantees. We set the consistency levels to the safest possible values in order to avoid running the risk of re-orgs.
For the following chains, safe levels are often too long for a good user experience:
For those chains, we set a "fast" consistency level, which emits VAAs much faster, while running the risk of re-orgs.
In order to mitigate that risk, relaying "fast" messages is only possible via specific relayers, which are configured at the contract level. These relayers use heuristics to decide which messages are safe to relay faster than usual.
Relaying regular ("slow") messages can be done by anyone.
wormhole-messenger:initialize:consistency task can be used to initialize the consistency level.
wormhole-messenger:initialize:fast-consistency task can be used to initialize the "fast" consistency level.
Hashflow Chain IDs differ from Wormhole Chain IDs. This is because Hashflow is agnostic to the interoperability protocol it uses under the hood (i.e. Wormhole).
In order to properly send cross-chain trades, we need to initialize the mapping between Hashflow and Wormhole Chain IDs for both the current chain and its peer chains.
wormhole-messenger:initialize:chain-id-mapping task can be used to initialize these mappings.
The messenger needs to know what its peers (remotes) on other chains are. This is very important when verifying the messages it receives. Only authenticated senders should be allowed to communicate with this messenger.
Remotes are updated based on their Hashflow Chain ID (and NOT Wormhole Chain ID). Their addresses must be prepended with 0 bytes up to 32 bytes. This is especially important for EVM remote addresses, which are 20 bytes on their native chains.
wormhole-messenger:initialize:remotes task can be used to initialize the remotes.