Skip to content
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

Generic non-native token warp route fees #4750

Open
nambrot opened this issue Oct 24, 2024 · 0 comments
Open

Generic non-native token warp route fees #4750

nambrot opened this issue Oct 24, 2024 · 0 comments

Comments

@nambrot
Copy link
Contributor

nambrot commented Oct 24, 2024

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.

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 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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

1 participant