How to prevent ERC20 token to be traded publically?

Question

I am creating ERC20 tokens for real state products where investors can buy/sell tokens but we want to oversee buy/sell process. For example, when investor want to sell tokens to other persons, it should not happen unless we approve that transaction.

Is it possible technically to do that on ethereum or should we go with private ethereum network

Answer 1

In your case, you must implement smart contracts on top of your ERC-20.

What you're doing is more like a Security Token; in this case, you can use different standards such as:

• ERC-1400 or ERC-1404 (Polymath)

• ERC-3643 T-REX (Tokeny)

ERC-1404 is another standard for security tokens, supposed to be more 'user-friendly',

Know Your Token Holders: "Know who your token holders are at all times and maintain a whitelist of investor addresses. [...] the simple restricted token standard helps token issuers manage their compliance requirements."

The ERC-1400 is a standard for security tokens with thorough guidelines and functions which include:

• Incorporation of differentiated ownership model.

• Error signaling.

• Document references.

• Gatekeeper (operator) access control and issuance or Redemption semantics. (where you can validate the wallet)

T-REX includes the following three core pillars:

• Identity Management System

• Validation Certificates

• Transfer Manager

Utility tokens can be transferred or exchanged very easily, but security tokens are subject to typical securities laws, they can only be issued to eligible investors, which can be retail, accredited/qualified, or institutional. T-Rex solutions provide, inter alia:

• Digital onboarding & initial token allocation

• Token supply control (mint/burn/freeze)

• Permissioned security tokens (T-REX standard)

Answer 2

ERC20 is just a standard. It gives us interfaces which need to be implemented and that's it - it doesn't state how the interfaces should be implemented. In theory the transfer function can do whatever it wants and it doesn't actually even need to transfer anything but in practice it's expected to do what the name says.

So you can take some standard ERC20 implementation (OpenZeppelin for example) and add your own logic there. So you will probably add some conditions in the transfer functionality, for example.

Answer 3

Yes, it is easily possible. One way is to write a low level _transfer() function (which internally will serve both the erc20 transfer() and erc20 transferfrom()) which, instead of transferring the tokens, write the relative request in a queue FIFO and both a checkTransferRequests() which returns queue information and an approveTransfer() which will made the actual token transfer.

A drawback of this is some gas to be spent by the approved as well. A possibility to analize is to maintain the ability to reverse a transfer made by any user, or to leave it done. In this case the approved spend gas if and only he need to send back some transaction he does not approve. This depends on your aim.