Community discussion on contracts for STOs.
Thank you @abcoathup
Ready to get started when everyone else is
Howdy folks I think I understand how to keep up with Forums now, and apologies for being remiss - appreciate shout-out
So, to kick things off here:
What do we think are the core technical specifications for a compliant security token?
My thought is that they should make themselves ‘regulate-able’ by having components that respect the typical restrictions on time and purchaser characteristics.
So , let’s say (1) “Table stakes” = admin role should exist in the contract that allows subjective whitelisting of accounts for Security Token transfers based on legal considerations.
We also might eventually reduce dependence on human admins and make these transfer restrictions more trustless and programmatic, based on a reference to a lock period (using OZ
timelock pattern probably…) . . . but, that will likely be more relevant once we have statutes truly codified on chain. Until then, we likely will have humans looking at law, talking to regulators, and making judgments to reflect state changes for Security Tokens that maintain property rights on Ethereum that won’t result in legal sanctions for identified participants.
Welcome back. .
Regulatory compliance is key and hence coding in compliance elements will be important.
Are you still looking at Security Tokens? Have you had a chance to use any or develop any?
Heya @abcoathup :-0))
Yes, I am working with a community of legal engineers, coordinated as
LexDAO on standardizing chunks that are useful for Security Tokens. So far, I have found great utility in adopting the ERC-1404 for whitelisting transfers, and ERC-2222 for dividend distribution/accounting: https://github.com/lexDAO/Security-Token
It would be fantastic to work together among LexDAO and OZ to fashion some core Security Token chunks