Enforcing a limit on ERC721 tokens held by an account

Support
1

We are providing a Gnosis multisig wallets to our users and a market place where users can purchase/sell/transfer ERC721 tokens with other users. The ERC721 contract will also have a Blacklist registry in which all the addresses will be put, who were trying to be nostalgic. New addresses can only be added/removed by an Admin multisig wallet.

This is how we have figured out to solve this problem.
Make use of balanceOf mapping in ERC721 standard. Every transfer will check this mapping and refuse to execute a new transaction if the token limit is breached. Will this change the ERC721 standard?. This will also not take account of cumulative ERC721 tokens, A user purchases and then transfers his/her token to some other dummy addresses repetitively to avoid the token limit.a new mapping be kept in a storage to keep track of token limit of addresses? The token limit of different addresses is different and will be updated by admin

was just wondering if this is a common practice? Is there any other platforms that have implemented the same strategy? I have seen some platforms which allows more tokens to be held only when they complete their KYC, How do they impose such a limit or they all are custodian wallets?

1 Like
2

Hi @GraphicalDot,

Welcome to the community :wave:

I'm curious why you need to have a limit on the number of ERC721 tokens a user can hold? Is this only for one specific ERC721 contract or multiple ERC721 contracts?

No, the standard specifies the conditions when the transaction MUST throw on a transfer but you are allowed to throw in other situations.

See the standard for details https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md

The transfer and accept functions' documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results:

  • Disallow transfers if the contract is paused — prior art, CryptoKitties deployed contract, line 611
  • Blacklist certain address from receiving NFTs — prior art, CryptoKitties deployed contract, lines 565, 566
  • Disallow unsafe transfers — transferFrom throws unless _to equals msg.sender or countOf(_to) is non-zero or was non-zero previously (because such cases are safe)
  • Charge a fee to both parties of a transaction — require payment when calling approve with a non-zero _approved if it was previously the zero address, refund payment if calling approve with the zero address if it was previously a non-zero address, require payment when calling any transfer function, require transfer parameter _to to equal msg.sender , require transfer parameter _to to be the approved address for the NFT
  • Read only NFT registry — always throw from unsafeTransfer , transferFrom , approve and setApprovalForAll

I have mostly only come across simple ERC721 tokens, and haven't looked at any dealing with KYC, so I don't know how others have dealt with this.

Have you got any more details on this?

3

Lets say a company provides a unique ERC721 token which represents some real physical world asset. These real world physical assets are really expensive and regulatory bodies requires proof of income or some other documents from a customer, if they really want to buy these assets.

for an example, for basic KYC completion they can buy x ERC721 tokens, but if they want to buy x+y ERC721 tokens, they must provide additional kyc documents.

1 Like
4

Hi @GraphicalDot,

I haven’t come across this sort of thing before.

What about having a KYC NFT, which is a non-transferable (but burnable) ERC721. If an address doesn’t hold the KYC NFT then they are limited to what they can purchase?

1 Like