Scope: deploy Warp Routes without interacting with contracts

[nambrot]

Context

• Partners perceive us as a blocker right now for warp route deployments.
• Competitors allow arbitrary warp routes through Wormhole's Portal and Axelar's ITS
• We sometimes have friction internally with warp route deploys, e.g. the ⁠viction launch and ⁠USDC/T for injective

Router Pattern

• With ICAs, we have found an approach to make them "interoperable" to continue to not require users of ICAs to have to touch anything on the remote chain.
• Warp routes on the other hand need the "classic" router deployment approach of deploying contracts on every chain, so that remote routers can be enrolled. Even a generic contract deployment mechanism over hyperlane messages cannot solve this, since you wouldn't be able to know what the remote router addresses going to be at dispatch time.

Solution

From Nam: "We probably should continue the convo on one of those tickets, but IMO there are multiple paths open with different tradeoffs to make the creation of warp routes more accessible:

1) Create a warp route factory contract + UI https://github.com/hyperlane-xyz/issues/issues/1005 Notion spec 2) Make the existing CLI command more accessible 3) Improve our internal posture to deploying warp routes 4) Deputize somebody like hyperlane-india

These options have drastically different scope and it's critical for us to understand the longer-range implications of the paths we want to go down. I would suspect that we all share the same end goal of having one-click interop, but how to get there is just as important if not more"

from Nam in Discord: "i was thinking that that an intermediate step could be to have the relayer pass msg.value and then use it as a cross-chain faucet effectively"

### Related issues
- [ ] https://github.com/hyperlane-xyz/issues/issues/1005
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/1879
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3498

[asaj]

You could imagine defining a warp route config that specifies:

• The canonical token address
• The list of supported domains
• For each domain, the router address
• For each domain, the ISM address

The hash of this config is the warp route ID.

Each WarpRouteRouter could have an init() function that:

• sets supportedDomains[ID][domain] = router for each remote domain
• Create2 deploys a metaproxied HypERC20Canonical contract using the warp route ID as the salt, with the ID and ISM as the metadata (the router address would be immutably set in the implementation)
• Sends a message to each remote router with the config

The init function could have an init and initWithOverrides. For the former you use the default routers/ISMs, for the latter you override them

Upon receipt of this message, the remote routers:

• set supportedDomains[ID][domain] = router for each remote domain
• Create2 deploys a metaproxied HypERC20 contract using the warp route ID as the salt, with the ID and ISM as the metadata (the router address would be immutably set in the implementation)

ERC20.transferRemote(destination, value, recipient) would:

• Burn tokens
• Calls router.transferRemote(ID, ism, destination, value, recipient), which verifies that msg.sender is the expected address (by deriving the bytecode hash using the ID and ism) and sends a mint message to supportedDomains[id][destination]

The warp route router ISM would be a routing ism:

• For init messages, uses the corresponding ISM from the message
• For mint messages, derives the token contract address and uses its ISM

Something like this would allow us to preserve essentially the existing Warp Route API but with the following advantages:

• Users can deploy a warp route with a single function call, potentially just taking a token address and supported domains (vs deploying contracts on multiple chains, making multiple function calls to configure them)
• "canonical" WarpRouteRouter addresses allows for a single frontend with minimal config (hardcode the WarpRouteRouter addresses into the frontend and then the token list is just a list of Warp Route IDs (i.e. config.hash())

With this design I'm not sure how exactly you would allow expansion of a warp route to incorporate e.g. a new chain but I imagine it can be done, I haven't given this design a ton of thought. There is also probably a better design, this comment is mainly intended to be illustrative.

Gas payments are also not in scope for this design

[nambrot]

Very cool, i can see the strokes of what you have been working on with ICAs in here. This does kinda remind me that I think it would probably be helpful to have documentation and diagrams for both ICAs and then something like WarpRouteRouter because it's a bit harder for me to build all these entities in my head and build a mental model.

I assume that is fine for now, but if you are looking for more specific feedback, I can try to wrap my head around and probably ask more thoughtful questions

[asaj]

I'm not looking for specific feedback on this design, I'm sure there's a better way to do it.

I'm sharing a strawman more to illustrate the advantages of rebuilding Warp Routes in the "interoperable router" pattern, in the hopes that we will choose to prioritize design and implementation.

[nambrot]

From a different issue (can't remember which one): how do you set IGPs on the remote chain?

[asaj]

From a different issue (can't remember which one): how do you set IGPs on the remote chain?

While I have ideas, I want to avoid this devolving into a design discussion. That sounds like a good problem for whomever winds up working on this to solve.

[nambrot]

From a different issue (can't remember which one): how do you set IGPs on the remote chain?

While I have ideas, I want to avoid this devolving into a design discussion. That sounds like a good problem for whomever winds up working on this to solve.

Gotcha makes sense. Do you think that someone should do a design first (i.e. this ticket), and then an implementation later (a different ticket after the design is socialized), or is this one where it should just be done in one swoop? In either scenario, what would you currently estimate the complexity in engineering days to be?

[asaj]

I don't care whether it's one ticket or two, but design should probably come before implementation. Estimate depends on the scope of what we consider "implemented" to be

[nambrot]

KK, i made this the design/investigate ticket then. Do you think 1 day is a reasonable estimate?

[asaj]

Thought a bit more about this on a walk and made some clarifications to the design

[jmrossy]

The list of supported domains The hash of this config is the warp route ID.

@asaj Would this prevent adding/removing domains to a warp route deployment?

[nambrot]

Gas payments are also not in scope for this design

Do you mean that they should not be in scope, i.e. payments should be considered a separate problem, or more not in scope as in "not yet part of the design", but something to figure out?

I also wonder if it would help to reduce the scope to be able to make some simplifying assumptions. IMO, it actually would be useful to maintain that warp route contracts are ownable everywhere to do things like upgrades, ISM changes, router enrollments, IGP changes. IMO the thing to optimize for over the current state is the deployment experience, where ideally you only need a single origin chain tx. A related simplification we imo could make is to have path independence betewen the synthetics, the primary use case is still for the PI chain deployer. (router enrollment could always be done separately) Could we avoid the need for the ID/config hashing in that case?