Warp Route deployment should be smoother

[nambrot]

Catch all issue

• Configuration
  • Example Config default on docs and readme is out of date (no gas)
  • Do some basic config validation, for example I did not set domainID (instead I did ID), and that had some downstream effects
  • Example config in the UI is not 1:1 copyable from the new chain metadata (requires ID to be set instead of domainID)
• Small things
  • Router output is generic, not which ones is native vs which one is synthetic
  • When deployer does not know about chain because forgot flag, script should indicate that
  • Warp UI docs do not show chain customization
  • balance does not seem to update (the state does seem to update, just not the UI)
  • UI seems to assume 18 decimals, the collateral one i have is 0xdC0583C90705e720956dE6b22E9B1D2d3BB020b8 on goerli (https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/1997)

Ultimately, you should be able to deploy a warp route yourself and not run into issues.

• ok to be out of scope for now, but can fix if easy:
  • When the deploy errors, no output of the routers
  • DEBUG env wouldn’t be set from the yarn command and thus log lines don’t show up

[asaj]

Wondering if we should build them in the interoperable router pattern instead of these bandaids

[nambrot]

I'm not sure that interopable router pattern solves all of these (i.e. config still needs to be validated, docs should indicate what the options are), so I would still suggest to fix these as relatively low-hanging fruit and then observe what difficulties people experience when actually doing this.

This does bring up the question, how do interopable router patterns pay for gas? I guess that's ultimately up to the user of the router?

[asaj]

This does bring up the question, how do interopable router patterns pay for gas? I guess that's ultimately up to the user of the router?

I would imagine that, similar to the other fields (e.g. router, ism) there are defaults (probably per-destination) that can be overridden by users.

[nambrot]

Other issues folks are running into:

Unclear what type to use in config https://discord.com/channels/935678348330434570/961710804011458621/1088469754500612158

All the outputs of the deployment are just router, not clear what hypCollateralContract and synthetic contracts are, or where to use those https://discord.com/channels/935678348330434570/1088447897319776266/1088497431953547365

Unclear what the actual flow is for a transfer https://discord.com/channels/935678348330434570/1088447897319776266/1088502845516562533 Probably should split this diagram into a simple and a detailed one, maybe i'll try to do it, especially since i had been prodding @yorhodes for the simplify, but should have said to keep a detailed one as well

[nambrot]

https://discord.com/channels/935678348330434570/935678477246554132/1088552463700869141

Unclear where to add a new chain for the UI

[asaj]

It feels like you need to specify a bunch of redundant info rn.

Feels like type/name/symbol/totalSupply are all unnecessary, we can infer the type from the presence of "token", and name/symbol/totalSupply can all be pulled from the token contract on the collateral chain.

[asaj]

Mailbox and IGP can/should also default to what's present in the SDK, so you only need to put them for PI chains

[asaj]

@nambrot wdyt?

[nambrot]

Another comment about the lack of clarity of what you have to do for the UI

https://discord.com/channels/935678348330434570/961710804011458621/1088867745673777212

[nambrot]

It feels like you need to specify a bunch of redundant info rn.

Feels like type/name/symbol/totalSupply are all unnecessary, we can infer the type from the presence of "token", and name/symbol/totalSupply can all be pulled from the token contract on the collateral chain.

Yes, that was the intention behind https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/1867, sounds like i should be able to get to it now that your hyperlane-deploy PR has stabilized and then from there we can determine better config/artifact handling?

[nambrot]

https://discord.com/channels/935678348330434570/961710804011458621/1088876856620626040

We should consider making chains.json and tokens.json not jsons but .ts files that allow for comments for context. In this case, they likely thought they have to put default chain metadata in there and set it incorrectly.

[asaj]

yes if you look at my hyperlane-deploy PR configs are in ts files. when we move warp route deployment into hyperlane-deploy we presumably will do the same

[jmrossy]

We should consider making chains.json and tokens.json not jsons but .ts files

The advantage of JSON is it's more natural to have one script output JSON which a user then picks up as the config to the next step (e.g. configure UI)

[nambrot]

But we are doing neither right now :P

[nambrot]

This is quite out of date, so closing in favor of other tickets capturing things not already fixed