Payment fixes: Bloat bonds, existential deposits, locks

[Lezek123]

Addresses https://github.com/Joystream/joystream/issues/4162

Currently expected locks behavior: https://gist.github.com/Lezek123/7eb89937fcbffabefe73fede0b336943

┆Issue is synchronized with this Asana task by Unito

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Updated
pioneer-testnet	⬜️ Ignored (Inspect)		Aug 25, 2022 at 6:40PM (UTC)

[Lezek123]

Distinct set of locks to be avoided for distinct costs in the same pallet.

There are valid use cases for this currently, for example, when purchasing tokens on a creator token sale one needs to pay for the purchased tokens + optionally the account bloat bond (if the account does not yet exist):

• Bloat bond is coverable with invitation-locked funds
• The cost of tokens purchased is only coverable with usable_balance

I think in that case this feature is very useful to have.

[bedeho]

I think in that case this feature is very useful to have.

So we have two alternatives here as I see it

1. Current:

• Bloat bond is coverable with invitation-locked funds
• The cost of tokens purchased is only coverable with usable_balance

2. Alternative:

• token purchasing only coverable by usable_balance

The question is now how are these different in terms of functionality? If someone can buy under 2, the same user could buy under 1, however, the converse is not true, but exactly in which cases? It seems those cases are precisely when someone has enough usable $JOY to pay for the $CRTs, but they could not afford the bloat cost, but they do have those funds under an invite lock.

How plausible is this?

I think very implausible, because a) the relative size of the two costs ($CRT cost in $JOY vs bloat bond) is likely orders of magnitude difference, we are after all taking about sub 10c costs for bloat bonds in general, otherwise they make all sorts of publishing prohibitive. b) how much one buys of the $CRT can always be adjusted down in these cases to allow the user to afford the bloat bond, and this would only in fact not be possible in cases where they are trying to buy a quantity of $CRT so small that its priced lower than the bloat bond.

So to me, I think the only difference between the two is one which is of very limited utility. Even independently of the broader complexity it generates across the runtime to have the flexibility to accommodate this, just the added complexity of locally having this nuance seems not worth it.

[ignazio-bovo]

The logic seems correct, altought I'd be more comfortable taking another stab, maybe during the next iteration. I just added a couple of restyling suggestions As @bedeho said these are big changes and the choices you made allow for a very flexible cost management. However since the costs, locks and bonds are pretty much set at this stage of developement. I would go for a more specific approach involving checking only the invitation / vesting locks only. I guess we can have a chat about this approach, during the next infra call