To support SubstrateHosts. We would need

• HyperbridgeDispatcher - for dispatching requests to hyperbridge
• SubstrateHostManager - for managing the HostParams from hyperbridge
• ismp-grandpa - for standalone chains and parachains on the sister relay chain
• ismp-beefy - for standalone chains and parachains on the sister relay chain
• ismp-parachain - for parachains

In the account abstraction paradigm, user accounts will no longer be tx.origin. This is as a result of moving their assets from an EOA to a smart contract account. Consequently, the EvmHost should be reworked to support smart contract accounts which hold assets in msg.sender instead of tx.origin.

Some ideas

• Don't charge tx.origin by default when dispatching requests, instead allow the application to choose who should pay for fees.
• Investigate if relayers will use account abstraction. Won't fix

Much like how the IsmpHost and Gateway should be governable by hyperbridge. So also must the ERC6160 tokens that are integrated into Gateway be governable. This governance action should allow modifying it's allowed minter & burners, eg adding new roles or deleting existing ones.

contract GovernableToken is IIsmpModule, ERC6160Ext20 {}

The HostExecutive module is responsible for tracking the HostParams for each individual host on a connected chain. This host may be a Substrate or Evm host.

The manager is responsible for dispatching parameter updates to these hosts over ismp. This should allow for securely updating the host either through sudo, a council motion or governance. The manager can also be used to withdraw protocol revenue that has been accrued by each host.

Gateway should be able to support the ERC6160 standard as well as the ERC20 standard through token swaps. If a user bridges an ERC20 token that has no ERC20 counterpart on the destination chain, they should get an ERC6160 token. On the other hand if a counterpart exists, the relayers should double as liquidity providers and facilitate the token swap. Relayers after providing liquidity should get the ERC6160 counterpart that they can use to withdraw the ERC20 token locked on the source chain.

onRequestTimeout we should either refund the custodied ERC20 or mint the ERC6160 asset back to the user. Allowing them retry the cross-chain teleportation.

Because ISMP charges protocol fees in it's configured feeToken, Gateway should allow users swap either the native asset or an ERC20 for the feeToken asset through some local AMM required to cover their fees.

Coordinating a decentralized pool of relayers will be necessary for the scalability and robustness of the Hyperbridge protocol. Our chosen design is one where relayers race to deliver ISMP requests to their respective destinations for a fee. This fee is paid ahead of time by the user on the source chain. This also means that if the request/response is never delivered then a user should be refunded the fees they paid ahead of time for delivery since it was never used.

Given these considerations we should introduce a new module that lives on the hyperbridge aptly named, RelayerManager. This module should track the cumulative sum of requests & responses that have been delivered by 3rd party relayers, through the verification of state proofs of their delivery.

Relayers, at the end of a days of work (or at their own discretion) should be able to issue a signed request to the RelayerManager asking to withdraw all the funds they are entitled to on the respective chains.

Spec is described here https://www.notion.so/polytopelabs/Optimism-Support-for-Beacon-Consensus-Client-03a82c7b85404435b48f1a8e93b02722

This task specs out requirements for adding optimism support to the sync committee updates
We create a new struct that contains the LightClientUpdate alongside an optional optimism update field optimism_payload that holds Option as defined below.

struct BeaconClientUpdate {
	pub consensus_update: LightClientUpdate,
  pub optimism_payload: Option<OptimismPayloadProof>
}

struct OptimismPayloadProof {
	/// Actual state root of the optimism execution layer
	pub state_root: [u8; 32],
  /// Storage root hash of the optimism withdrawal contracts
	pub withdrawal_storage_root: [u8; 32],
  /// Optimism Block hash at which the values aboved were fetched
	pub l2_block_hash: [u8; 32],
	/// L2Oracle contract version
	pub version: [u8; 32],
  /// Membership Proof for the L2Oracle contract account in the ethereum world trie
  pub l2_oracle_proof: Vec<Vec<u8>>,
  /// Membership proof for Output root in l2Outputs array
  pub output_root_proof: Vec<Vec<u8>>,
  /// Index of the output root that needs to be proved in the l2Outputs array
  pub output_root_index: u64
}

Contract Properties
For testnet L2Oracle contract address is 0x47bBB9054823f27B9B6A71F5cb0eBc785692FF2E

Slot index for the l2Outputs array in the contract is 3

To verify an optimism update

1. Extract L2Oracle storage root hash from the l2_oracle_proof , the root hash to be used for this step is the execution_payload_root from the LightClientUpdate.
2. Use the extracted storage root hash to verify membership for the output_root as constructed below in the output_root_proof

Contract Properties
For testnet L2Oracle contract address is `0x47bBB9054823f27B9B6A71F5cb0eBc785692FF2E`

Slot index for the l2Outputs array in the contract is `3`

To verify an optimism update

1. Extract `L2Oracle` storage root hash from the `l2_oracle_proof` , the root hash to be used for this step is the `execution_payload_root` from the `LightClientUpdate`.
2. Use the extracted storage root hash to verify membership for the `output_root`  as constructed below in the  `output_root_proof`

Create a file for exporting beacon consensus client constants.
Feature flag testnet config parameters.