Hyperlane Teller

[junkim012]

Goal

• Create a Teller that can use hyperlane as its underlying messaging protocol.

Requirements

• Bridge Security
  • The destination chain teller should receive the message only from its counterpart teller on the source chain.
  • Only the mailbox should be able to call handle.
  • Users should be refunded overpaid gas for bridging.
  • When users define gas limit, this is in the destination chain's token, not the source chain's token.
• Test
  • Each message must have its own guid.
  • Perform bridging to and from testnets.
• Deployment
  • HyperlaneTeller deployment scripts
  • HyperlaneTeller configuration files

Discussions

Hyperlane Configurations

• Using default ISMs vs. custom ISMs.
• Gas refund address override
• gas limit override

Slow Path vs. Fast Path (Not Implemented)

• Slow Path (bus)
  • User can queue a bridging message for it to be processed later.
• Fast Path (taxi)
  • User initiates an instant bridging message.
  • When the queue is non-empty, should the fast path initiator process the queue? Or should the fast path initiator not be responsible for paying for the looping costs of multiple vault.enters.
• How to process multiple requests.
  • The queue data—an array of share amounts and recipients—can be sent over in one transaction, and the receiving leg needs to loop and call multiple vault.enters.