Specialized Relayer
Last updated
Was this helpful?
Last updated
Was this helpful?
Wormhole is compatible with many and integration is straight forward.
The way a message may be received depends on the environment.
On EVM chains, the message passed is the raw VAA encoded as binary.
It has not been verified by the core contract and should be treated as untrusted input until parseAndVerifyVM
has been called.
Emitter: Is this coming from an emitter address and chain id I expect? Typically contracts will provide a method to register a new emitter and check the incoming message against the set of emitters it trusts.
Sequence: Is this the sequence number I expect? How should I handle out of order deliveries?
Outside of body of the VAA, but also relevant, is the digest of the VAA which can be used for replay protection by checking if the digest has already been seen.
Since the payload itself is application specific, there may be other elements to check to ensure safety.
After enough Guardians have signed the message (at least 2/3 + 1
or 13 of 19 guardians), the VAA is available to be delivered to a target chain.
Regardless of the environment, in order to get the VAA we intend to relay, we need:
The emitter
address
The sequence
id of the message we're interested in
The chainId
for the chain that emitted the message
Fetching the VAA
Once we have the VAA, the delivery method is chain dependent.
On EVM chains, the bytes for the VAA can be passed directly as an argument to an ABI method.
In order to send and receive messages between chains, some are important to understand.
To send a message, regardless of the environment or chain, the core contract is invoked with a message argument from an .
This emitter
may be your contract or an existing application such as the , or .
Using the IWormhole
interface (), we can publish a message directly to the .
More details in
More details in
Once the message is emitted from the core contract, the will observe the message and sign the digest of an Attestation (). We'll discuss this in more depth in the section below.
By default, VAAs are . This means there is no default target chain for a given message. It's up to the application developer to decide on the format of the message and its treatment on receipt.
More details in
More details in
In addition to environment specific checks that should be performed, a contract should take care to check other such as:
Consistency Level: For the chain this message came from, is the enough to guarantee the transaction wont be reverted after I take some action?
In order to shuttle messages between chains, some are involved. The observe the events from the core contract and sign a .
Once the VAA is available, a may deliver it in a properly formatted transaction to the target chain.
A relayer is needed to deliver the VAA containing the message to the target chain. When the relayer is written specifically for a custom application, it's referred to as a
A specialized relayer might be as simple as an in browser process that polls the for the availability of a VAA after submitting a transaction and delivers it to the target chain. It might also be implemented with a coupled with some daemon listening for VAAs from a relevant chainID
and emitter
then taking action when one is observed.
With these three components, we're able to uniquely identify a VAA and fetch it from the .
Using the getSignedVAAWithRetry
function provided in the , we're able to poll the Guardian RPC until the signed VAA is ready.
See the for a detailed walkthrough.
Read more about the architecture and core components