-
Notifications
You must be signed in to change notification settings - Fork 6
feat: transfer tx fees to treasury #42
Conversation
Codecov Report
@@ Coverage Diff @@
## main #42 +/- ##
==========================================
- Coverage 77.06% 76.46% -0.60%
==========================================
Files 16 16
Lines 933 973 +40
==========================================
+ Hits 719 744 +25
- Misses 214 229 +15
Continue to review full report at Codecov.
|
|
One notable change is that we replaced withdraw and deposit with one transfer. The consequence is that we can't use |
|
i would suggest to keep the original implementation where the native is withdrawn and refunds are deposited. and introduce new one with fees transferred to selected account. in this way - it will be easily to swap back if needed. |
|
@apopiak Could you have a look at this ? the reason is that it seems that this PR introduces something similar to what you'd need for xcm trader ( see the TransactioPaymentDataProvider). Also, review of the PR by you would be appreciated too. |
transaction-multi-payment/src/lib.rs
Outdated
| match paid { | ||
| PaymentInfo::Native(paid_fee) => { | ||
| let refund_amount = paid_fee.saturating_sub(corrected_fee); | ||
| C::transfer(&fee_receiver, who, refund_amount, ExistenceRequirement::KeepAlive) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing a transfer up above in withdraw and then doing another one here means that the fees could have moved from the fee receiver account in the mean time so you won't be able to refund.
It's probably fine but if that edge case ever happens it'll be one hell of a thing to debug ;-)
Also: you might want to skip the transfer in case refund_amount is zero?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How else would be possible to withdraw fee and avoiding such scenarios? Would reserve some balance instead of transfer work ?
i mean, you'd first reserve and then only transfer the actual fee and unreserve the remaining balance ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The MultiCurrency trait offers withdraw and deposit which could be used together similar to how Substrate's transaction payment is implremented
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that Currency and MultiCurrency traits are inconsistent. Currency returns Imbalance type, MultiCurrency returns Balance type, and it's impossible to combine them. We can't create an imbalance from some balance and we also can't get rid of imbalance without calling it's drop implementation. This is the main reason why we are using transfers in our implementation. We can handle each currency type separately and use withdraw methods, but then in case of any error during execution of an extrinsic, tokens are burned instead of deposited because correct_and deposit_fee is not called. And I'm not sure if we want this behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is skipping the deposit in case refund is zero really needed? Both deposit methods (native and non-native) have a check for zero balance at the beginning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷 good point, that's a fair assumption for the most common implementations.
|
|
||
| pub struct DepositAll; | ||
|
|
||
| impl DepositFee<AccountId, AssetId, Balance> for DepositAll { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Roznovjak can you please provide this implementation in pallet (or mby even as default), so it doesn't have to be implemented in the runtime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you like to have it implemented for the unit type () or just to have DepositFee struct publicly available from the pallet?
enthusiastmartin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
we just need to make sure that no tokens are lost ( after the withdraw and deposit_fee).
| /// Account to use when pool does not exist. | ||
| #[pallet::storage] | ||
| #[pallet::getter(fn fallback_account)] | ||
| pub type FallbackAccount<T: Config> = StorageValue<_, T::AccountId, OptionQuery>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for migration to delete the storage ? only if upgraded after it is already in use.
|
you'll also want 1de7570 to allow Basilisk to compile |
|
and to add the feature |
|
As you remove the |
Co-authored-by: Alexander Popiak <[email protected]>
Yes. We will also need another PR for hydra-parachain. |
|
Is this ready for merge? |
I would like to resolve first this question It just looks to me bit unnecessary. i would simplify it. Let's wait for Richard to give his opinion. Other than that - it is ready for merge. |
|
He removed the iterator |
No description provided.