Define a common standard for cross-chain relaying systems built on Wormhole and a framework xDapps can follow to be composable with each other.
## Background
The Wormhole VAA model only handles attestation of cross-chain messages, but does not provide a system for generalized delivery. This requires users to do delivery on the target chain or dApps to operate independent relaying infrastructure.
Currently, composing between different cross-chain applications often is leading to design patterns where developers are nesting all actions into a common VAA that contains all instructions to save gas and ensure atomic execution.
This pattern is sub-optimal as it often requires multiple composing xDapps to integrate each other and extend their functionality for new use-cases and delivery methods.
This is undesirable as it adds more and more code-complexity over time and slows down integration efforts.
## **Goals**
Define common standards for relaying systems on Wormhole. This should lead to good documentation, low switching costs between systems and make it easier to build indexing services across competing solutions.
Define the primitives that xDapps need to follow to be compatible with these systems and allow them to compose with each other.
## Non-**Goals**
This doc does not define economics on how relayers should be incentivised in systems. We want to endorse a multitude of solutions to compete for the best solutions here.
## Overview
Wormhole xDapps as well as relaying systems should be designed to allow for maximal composability.
Thats why we propose a solution leveraging [Batch VAAs](https://github.com/wormhole-foundation/wormhole/blob/whitepaper/batch_vaa/whitepapers/0008_batch_messaging.md). They allow the integrator to perform multiple actions in different xDapps and then append delivery instructions. These delivery instructions are encoded in another VAA, emitted by the relayer contract, with the same nonce.
This delivery VAA caries a payload which can provide context for the receiving contract on what to do with the other VAAs within the batch.
To allow for atomic batch-interactions with different xDapps, xDapps need allow whitelisting of addresses that can trigger the intended actions on the target chain.
This address can then be set to the receiving contract that processes the whole batch that can ensure no VAAs are picked out of the batch and processes individually.
## Detailed Design: Composable xDapp
The integration path for xDapps to be compatible with the Wormhole Relaying blueprint and cross-chain atomic batch transactions boils down to three points to follow:
1. Accept the Wormhole `nonce` as a parameter that the caller can specify.
2. Return `sequence` number returned by the Wormhole contract back to the caller.
If the contract address that is emitting the VAA is different from the callers entry-point, xDapps also need to return the address that is emitting the VAA.
3. Allow the caller to specify which `address` can trigger the intended action on the target chain.
_( E.g. for Portal bridge this means specifying the (contract) address that is the only one allowed to redeem a transfer. )_
## Detailed Design: Relaying system
**Structs:**
```solidity
struct DeliveryInstructions {
// DeliveryInstructions
PayloadID uint8 = 1
// Address of the sender. Left-zero-padded if shorter than 32 bytes
FromAddress bytes32
// Chain ID of the sender
FromChain uint16
// Address of the receiver. Left-zero-padded if shorter than 32 bytes
The `relayerParams` payload can be freely designed by the relaying system and should contain all data internally required by the relaying system to handle economics and safely deliver.
This could be the amount of gas to call the target contract on deliver, data related to the payment of the relayer on the target chain et cetera.
A relaying system that handles payment on the source chain could have minimal Relaying parameters containing just the target gas amount, lets look at two examples:
- Check the delivery hash (`hash(batchHash, AllowedEmitterSequence)`) against already successfully delivered ones and revert if it was successfully delivered before
- Parse and verify VAAv2 at Wormhole contract with caching enabled
- Check if the emitter of the `DeliveryInstructions` VAA is a known and trusted relaying contract
- Check if the `DeliveryInstructions.ToChain` is the right chain
- If a whitelist is specified, check if all specified VAAs are in the delivered VAAv2, if no whitelist is specified check that the full batch was delivered