Prevent verification of contract addresses

[everhusk]

Contracts owning security tokens could potentially open the door for non-verified people to pseudo-trade tokens.

1) Alice submits documentation to prove she is a US accredited investor, and submits a contract address. KYC provider verifies Alice and she purchases 10,000 security tokens to her contract address. 2) The contract allows people to contribute ether and get added to a ledger on the contract which determines who owns what percentage of the security token 3) These contributors could skip the verification process and own some security tokens

Of course this would likely be illegal, and Alice would be liable for setting up such a service, but is it worth restricting verifications to only single addresses? @adamdossa @pabloruiz55 @bshevchenko, what are your thoughts?

[pabloruiz55]

But in the case described above a person contributing ether to this contract would never be able to get a hold of his share of tokens or use them somehow.

Say Bob puts 1 eth in Alices contract that holds 10,000 ST, he has 10% of the contract's funds, theoretically.

The moment he wanted to withdraw them, he wouldn't be able to do so since transfer/transferFrom would have to be called on that ST, which enforces that the receiving end is on the ST's whitelist.

The only alternative would be to check that the address is an EOA by making sure the address does not contain code, but that would limit the use of multisig wallets, for example.

[adamdossa]

I agree with @pabloruiz55 that Bob would not be able to withdraw his tokens. It is possible however to imagine a smart contract which allowed Bob to sell ownership (in terms of the collective contract registered by Alice) of his tokens for some ETH (which he could withdraw) or profit from dividends (proportionally) sent to Alice's contract.

Some ICOs have restricted initial offerings to non-contract addresses, but restricting trading in this way for all tokens will have issues (DEX's, multi-sigs). I see this as a similar category of problems as Alice just selling the private key of her account, which would equally be "illegal" for Alice to do (although setting up a smart contract like the above could be done in a more trustless manner than selling a private key which has lots of trust issues for the buyer).

[pabloruiz55]

Yes, indeed, Bob could profit from dividends being paid to Alice's contract. But in no case, Bob would own the tokens from the ST contract, so I don't really know how "illegal" that is. Nevertheless, the only way to prevent that would be restricting everything to EOA, which leaves out multisigs and that would certainly piss off many people. I guess we could also add something to the Terms and Conditions that specifies that only EOA should be used to invest, but we certainly can't enforce that.

[adamdossa]

One approach would be to push this out to the (off-chain) KYC process. i.e. a KYC organisation could have a two track process, one track for approving EOA, and another for approving smart contract addresses. In the latter case they could have a higher fee and insist that the code is verified (on e.g. etherscan) or provided to the KYC organisation for a sanity check (i.e. to make sure it is a multi-sig type contract rather than something like the above).

[pabloruiz55]

I don't think they would be prepared for that and they would not accept the liability that entails. It's not as simple as "checking that the photo/data provided matches the ones on a Passport", and there's still many ways to fool this process. Contracts that use delegatecall, upgradeable contracts, etc.

[everhusk]

Yeah I agree with this. Pushing the check off-chain and recommending a disclaimer seems to be the best approach here. We could also add in some tools to polymath.js for KYC providers to check if the address is a EOA or not.