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
Now, as long as the reserve_amount is not zero, even if free_balance is zero, the account will not be dusted.
But reserve operation may fail for provider/consumer:
if an account only free: 2*ED, reserved: 0, its provider,consumer: 1,0
reserve 2ED, the expected result is free: 0, reserved: 2*ED, will inc consumer first, then dec provider. dec provider will fail for ConsumerRemaining.
we can:
use wrapper reserve function, which do inc_provider before call reserve
use wrapper unreserve function , which do dec_provider after call unreserve and check
In this way, regardless of whether free_balance has ED or not,
before reserve step, additional provider additional was provided for dec. It seems a feasible solution, but for these account has reserved already, it should require more judgment to decide whether to inc provider or dec provider.
With paritytech/substrate#12951, reserved balance no longer add provider ref.
Update the module-support to add features to reserve balance and manage provider ref.
Review all pallets that uses reserve and replace the usage with this
This should be fully backward compatible
In future, we should be able to modify those two helpers to migrate to the
fungible
traitThe text was updated successfully, but these errors were encountered: