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
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".
The text was updated successfully, but these errors were encountered:
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 totransfer(dest, amount)
where theamount
arrives atdest
, 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 itsreceive_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" whileLimited: u64
would mean "pay the destination'sWeightToFee
of this amount and have the exact amount arrive".The text was updated successfully, but these errors were encountered: