You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #3060, which is about charging the "mandatory" IGP fee from a users warp token balance (vs. as the local gas token). This issue is somewhat related, in that there are use cases where a non-native fees are charged independent of the IGP fee itself. For example the owner may want to charge a fee for all bridge transfers. Additionally, #3060 is limited in its quoting transparency, i.e. the amount parameter of transferRemote is not what is actually getting transferred and a UI like the warp template UI would be unable to display a quote to the user.
This issue tries to lay out a potential solution to this by adding a new additional quoting behavior for warp routes.
quoteTransferRemote returns the amount of token(s) that this warp route will pull from the amount that is passed to transferRemote before embedding the amount in the TokenMessage. This allows these warp routes to be "backwards compatible" with warp route tooling like previous warp template UIs that don't know about this new quoting (and it will just not display the full quote).
quoteTransferRemote can also be extended with CCIP-read like behavior to make the client fetch a quote from an off-chain source. This would work well for intent protocols where the fee is very dynamic and depends on off-chain quotes from solvers. The downside of this option would be that the contract wouldn't be able to revert if not enough was passed.
You can also imagine this as kind of an experiment for alternative quoting mechanisms for the mailbox. I.e. a new kind of IGP can be used that emits the GasPayment event inside transferRemote instead of postDispatch.
open question:
what other context should be passed into the quote?
The text was updated successfully, but these errors were encountered:
Related to #3060, which is about charging the "mandatory" IGP fee from a users warp token balance (vs. as the local gas token). This issue is somewhat related, in that there are use cases where a non-native fees are charged independent of the IGP fee itself. For example the owner may want to charge a fee for all bridge transfers. Additionally, #3060 is limited in its quoting transparency, i.e. the
amount
parameter oftransferRemote
is not what is actually getting transferred and a UI like the warp template UI would be unable to display a quote to the user.This issue tries to lay out a potential solution to this by adding a new additional quoting behavior for warp routes.
struct Amount { address token; uint256 amount; }
function quoteTransferRemote(uint32 destination, bytes32 recipient, uint256 amountOrId) returns Amount[]
quoteTransferRemote
returns the amount of token(s) that this warp route will pull from theamount
that is passed totransferRemote
before embedding the amount in theTokenMessage
. This allows these warp routes to be "backwards compatible" with warp route tooling like previous warp template UIs that don't know about this new quoting (and it will just not display the full quote).quoteTransferRemote
can also be extended with CCIP-read like behavior to make the client fetch a quote from an off-chain source. This would work well for intent protocols where the fee is very dynamic and depends on off-chain quotes from solvers. The downside of this option would be that the contract wouldn't be able to revert if not enough was passed.You can also imagine this as kind of an experiment for alternative quoting mechanisms for the mailbox. I.e. a new kind of IGP can be used that emits the
GasPayment
event insidetransferRemote
instead ofpostDispatch
.open question:
The text was updated successfully, but these errors were encountered: