Warn user when destination lack Eth native collateral
The problem and exact requirements are unclear but here's the reported issue: https://discord.com/channels/935678348330434570/1191494055448817737/1291040060178960384
@bertux can you share a bit more about what you'd like to see, e.g. given x scenario, when a user does y, UI should do Z
- given scenario where there is native ETH warp route and there is low ETH liquidity in the destination reserve managed by owner of this warp route.
- when a user tries to bridge more than available liquidity at the destination
- UI should warn the user that there's not enough liquidity to bridge all the amount requested and should refuse to bridge until the amount requested is lower than available liquidity
- Ideally it should display the maximum available to bridge so the user can choose easily an amount lower than this maximum. For example that's what Connext displays in their dashboard.
@avious00 is it clearer this way?
I am interested to investigate it as I have done before for the CLI because I feel that's what is missing in so many bridges UI to avoid many potentially stuck bridging because of lack of liquidity. It would also bring more confidence in the reliability of the bridge if it can warn when it detects it would fail at the destination even when not failing at the source.
yorhodes — Yesterday at 4:31 PM https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/74a592e5867a375f1705654c1112d7c9ac784ddf/monorepo/typescript/sdk/src/token/TokenStandard.ts#L100 it appears like we check it here https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/3c8c68856d241ea787dcb71810fc5c9a428bc336/monorepo/typescript/sdk/src/warp/WarpCore.ts#L474 the support thread indicates the tx originated from https://app.cryptorank.io/hyperlane/token-bridge which is not a UI we maintain
I've fixed the links: https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/74a592e5867a375f1705654c1112d7c9ac784ddf/typescript/sdk/src/token/TokenStandard.ts#L100 https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/3c8c68856d241ea787dcb71810fc5c9a428bc336/typescript/sdk/src/warp/WarpCore.ts#L474 But this is only in the SDK so it should be working in the template UI and every UI calling correctly the SDK ?
@bertux
The current behavior is by design. The check happens in the SDK's WarpCore. The change must be made in the SDK and be done carefully to ensure it doesn't break anything and works for all the Evm, Cosmos, and Sealevel adapters that can be involved here.
thanks @jmrossy for the precision, so if I understand correctly you confirm a change is needed in the SDK but it's very impactful change because it can break anything so I should focus first on finishing my current bounty on integrating Ansible support.
Good idea