-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warp Routes should allow LPs to front the liquidity #2690
Labels
Comments
@nambrot I will work on this! |
RohanShrothrium
pushed a commit
to RohanShrothrium/hyperlane-monorepo
that referenced
this issue
Sep 8, 2023
RohanShrothrium
pushed a commit
to RohanShrothrium/hyperlane-monorepo
that referenced
this issue
Sep 13, 2023
RohanShrothrium
pushed a commit
to RohanShrothrium/hyperlane-monorepo
that referenced
this issue
Sep 14, 2023
RohanShrothrium
pushed a commit
to RohanShrothrium/hyperlane-monorepo
that referenced
this issue
Sep 15, 2023
nambrot
added a commit
that referenced
this issue
Sep 26, 2023
### Description This PR introduces a feature to warp routes such that LPs can fill transactions on local chains and get a fee for doing this. ### Drive-by changes No. ### Related issues #2690 ### Backward compatibility No ### Testing Added Unit tests. --------- Co-authored-by: Rohan Shrothrium <[email protected]> Co-authored-by: Nam Chu Hoai <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Warp Routes are secured by ISMs, i.e collateral that is stored on let's say
HypERC20Collateral
is only redeemable if the configured ISM attests to the corresponding instruction from the permissioned contract on the remote chain. When using a relatively slow ISM (like an Optimistic ISM or an underlying canonical optimistic rollup bridge), the latency in transferring via a warp route could be not ideal. This bounty proposes a proof of concept that allow users to specify an optional fee to have LPs provide the underlying token before the ISM "finalizes". To implement this, you would do the following:fastFee
that can be called via atransferRemote
variantfillFastTransfer(recipient, amount, fastFee)
which takes the tokens (amount - fastFee) frommsg.sender
and gives them to therecipient
. Store evidence of the action in storage.handle
of the message, check thatfastFee
was set in the metadata, check if somebody has indeed filled the transfer previously, and if so, actually transfer the tokens to the LP. Otherwise, completely the transfer as normally.To close out this ticket, create unit tests with the mocks that illustrate this behavior
The text was updated successfully, but these errors were encountered: