Allow marker admin to prevent transfer of restricted coin with deny list on send

[leeduan]

Summary

Allow a marker admin to sanction or add specific addresses to a deny list to prevent that address from transferring that coin to another address.

Problem Definition

With the introduction of RequiredAttributes in the marker module for restricted coins allowing anyone to use the bank module send functionality to any to address with those respective attributes, we can't prevent a from address that the marker admin(s) wants to sanction from transferring that coin to another address with those attributes.

Some example use cases:

• a fiat or stablecoin provider may want to prevent a blockchain address from being able to transfer coin that was minted in relation to an ACH deposit that was later claimed fraudulent.
• a court order notifies a TA to reissue a security token to a new address because old coin is held in an account that is no longer accessible due to lost keys

Proposal

Allow some kind of marker-specific sanction or deny list so that we prevent bank send on restricted marker with required attributes on from addresses.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[iramiller]

This might be straight forward to build now that we have the updated restriction system... A related concern that could arise form this though is that some accounting processes need to know the supply of a token that is not "dead/burned" ... so we should consider some sort of method for tallying dead tokens and subtraction them from the overall supply that is reported for a marker based on the bank module total. Related to supply/value - #1470

[nullpointer0x00]

Yes, I was wondering about this case as well. For example, if an address is added to the deny list. We will probably have to look at the account and see if they have any of the restricted markers and do something house keeping if they do. If they don't, we can just add the address. We could do this issue without that to begin with. Just have the ability to add the deny list on marker creation. That way the denied addresses would not have any markers yet. Then do all the logic of denying a send.

The next issue would be to make an Update deny list tx. That could would do all that work. Since, the address added could have those markers.

[iramiller]

After some discussion with Figure about market place restrictions for bilateral settlement we should consider a generic restriction module function for this implementation.

In the examples discussed in that meeting it is desired that the tokens being exchanged be escrowed in the user’s wallet with a hold placed on committed tokens. This is preferable to a situation with tokens moved into a contract for escrow.

Along this same line the ability to stop transfer of tokens out of a wallet neatly solves the vesting account setup where there are multiple vesting claims. With a proper hold function that implemented lockups as a service for other modules the marker module could issue a hold, vesting systems could do the same… even a future exchange module could issue and cancel holds for in place escrow of funds.

[SpicyLemon]

I feel like we want an account's "Spendable Balance" to change when a hold is placed on some tokens. I'm pretty sure the only way to do that is through custom account types (e.g. vesting accounts). That might be problematic when an account then needs to be two types (e.g. a vesting account and marker hold account). I'll do some digging on that.

If we don't care about the "Spendable Balance" then we can have the marker module record state for held coins and enforce it using a SendRestriction.

[SpicyLemon]

Did some digging on "Spendable Balance" and locked coins. Currently, the only way to utilize the bank module's concept of "locked coins" is through vesting accounts. We could implement our own custom vesting account type to handle the management of locked funds, but that comes with extra headaches since an account can only be one type. E.g. an account can't be two different types of vesting account.

It'd probably be better to have the marker module manage the state of escrowed funds. The funds would remain in the original account and the marker module would record that they're in escrow. The marker's SendRestriction function would be updated to ensure that escrowed funds aren't moved.

One down-side to that is the SpendableBalance query would still report that the escrowed funds are spendable. If that's a problem, we could add an injectable GetLockedCoins function to the bank module so that the marker module can tell the bank module that some funds are locked.

[leeduan]

@iramiller should I open anther ticket for escrowed in the user’s wallet with a hold placed on committed tokens feature? did a quick scan of issues but didn't see anything there and assume the deny list feature here will be built separate from a more extensive hold feature?

[iramiller]

Sure @leeduan, you could open another issue to formally start tracking that. I have some detail I can add from my exchange module notes but it would be easy to ship separately since it seems you might want this feature sooner than later.

[leeduan]

#1607