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

Pay Fees on Sending Side of Teleportation #99

Open
joepetrowski opened this issue Nov 10, 2021 · 0 comments
Open

Pay Fees on Sending Side of Teleportation #99

joepetrowski opened this issue Nov 10, 2021 · 0 comments
Labels
I5-enhancement An additional feature request. T6-XCM This PR/Issue is related to XCM.

Comments

@joepetrowski
Copy link
Contributor

Right now, teleports pay fees on both sides of the teleportation: the signed extrinsic fee is taken pre-dispatch on the sending side (as usual), and a fee on the receiving side is deducted from the teleported amount. This leads to a few UX issues like trying to teleport too little (fee >= amount) causing nothing to arrive, or just the inability to have an exact amount land in some receiving account. Paying fees on the sending side would allow for a behavior similar to transfer(dest, amount) where the amount arrives at dest, and any fees are taken from the account outside of the function's arguments.

Since teleportation only occurs between trusted chains (e.g. Kusama <> Statemine), the receiving chain could trust the sender to take enough of a fee. This means that teleporters would need to know about fees on their interlocutors. For example, if a teleport from Statemine to Kusama will be writing to Relay Chain state, it should pay the higher transaction fee of the Relay Chain.

(Fees and deposits on Statemine are generally 1/10th of the Relay Chain value, so a teleport under this system would take fee(send_teleport()) + 10 * fee(receive_teleport()). Such a feature could be limited to chains that share the same XCM version such that a sending chain can use the weight of its receive_teleport() as a proxy for the weight of the same function on the destination.)

The weight info would still need to be passed in the message so that block authors can account for it in block fullness. One idea would be that Unlimited would mean "just pay fees on the destination side and debit them from the amount" while Limited: u64 would mean "pay the destination's WeightToFee of this amount and have the exact amount arrive".

@KiChjang KiChjang added the T6-XCM This PR/Issue is related to XCM. label Dec 24, 2021
@joepetrowski joepetrowski transferred this issue from paritytech/polkadot Aug 24, 2023
@the-right-joyce the-right-joyce added I5-enhancement An additional feature request. and removed J0-enhancement labels Aug 25, 2023
jonathanudd pushed a commit to jonathanudd/polkadot-sdk that referenced this issue Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I5-enhancement An additional feature request. T6-XCM This PR/Issue is related to XCM.
Projects
None yet
Development

No branches or pull requests

3 participants