Support for Tokens Restricted with Attributes

[iramiller]

Summary

Support for restricting tokens created by a marker which require accounts to possess certain attributes before allowing the tokens to move.

Problem Definition

Currently the restricted marker system has a common use case of requiring attributes such as KYC records to exist on accounts before tokens can be sent. This is implemented with extra steps using smart contracts to broker transfers. While this is a workable process it prevents more complex workflows such as exchange functions from using these tokens without adding in auth grant steps. These auth grant steps allow the checks to be bypassed which while workable is less than ideal.

Proposal

With the bank transfer authorization hooks being added to the bank module it will be possible to support new authorization flows during any transfer of tokens between accounts. With these hooks we should be able to look up a token marker registration and determine if there are restrictions in place. If we added support for defining a set of attributes that must be present on the destination account then these hooks could allow the constraints to be easily enforced in a universal way. This would mean that exchange functions and other smart contracts could start accepting these tokens while the marker admin can ensure that their attribute assertions are uniformly and consistently applied.

1. Update the marker module with a method for defining bank transfer restriction rules
2. Update the bank module send authorization hooks with a method that checks the marker module to ensure that any require checks are performed before approving a transfer of tokens between accounts.

Requires: cosmos/cosmos-sdk#14224 and associated development of the hooks that are registered.

---

For Admin Use

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

[iramiller]

The ideas here overlap a bit with this Ethereum proposal: https://eips.ethereum.org/EIPS/eip-3643

[iramiller]

More detail:

• Restrictions can be added to the existing Restricted Coin type.
• A repeated list of name/value elements can be added to the Marker Account proto to specify the restrictions
• Values for the name should support wildcards (e.g. - *.kyc.passport.pb)
• The bank hooks for restrictions on transfer can be used so that normal bank transfers can occur and deprecate the Transfer method on the marker.
• Transfer access-grant can be checked as an override to the additional restrictions
• The Transfer access-grant can be used for controlling the transfer process ... so by extension this role should be required for requests that add/remove/modify restrictions on a marker

[iramiller]

One more related transfer concept that is less restriction and more control... it should be possible to specify that a transfer authority has "clawback" capability ... this is a somewhat sensitive issue in the blockchain world as it indicates that the owning account doesn't have full control over their assets and they could be removed without their signature. However, when a token is modeling a real-world asset such as a bank deposit there can be cases where funds are transferred without the account holder's permission. In order to model these use cases digitally a corresponding capability should be possible on chain as well.

Proposed: an additional flag on the marker for "restricted" tokens that indicates if clawback is allowed. If set to true then the check for the source account signature on the transfer request should be skipped. This would provide a lasting use for the Transfer method and prevent it from being deprecated as mentioned above.

[iramiller]

See #1368 for the clawback piece.