Hello,
I’ve been trying to learn about STO’s , and i am trying to use ERC1400 for an implementation.
I downloaded the code(https://github.com/ConsenSys/ERC1400) but i am still struggling with some points that are not clear:
Looking at the constructor of erc1400.sol , it does not have a totalSupply parameter, i thought that when you are launching an STO you should specify the totalSupply , (like in erc20)
Also erc1400 inherits from erc1400Raw.sol which has the parameter totalSupply to specify in the constructor but it’s used as if the totalSupply is specified by token holder. Not the total supply of all the tokens circling.
So that got me really confused and i would appreciate it if someone clarifies this for me.
Also in the constructor of erc1400.sol we specify “defaultPartitions” , i didn’t quit catch what those are , in erc1400Test.js it is specified that they can be (reserved in hex/issued in hex or locked in hex) but what are they concretely ? are they smart contract addresses ? And at the launch of your sto you have to specify the securities that are issued, locked and reserved from the beginning ?
In terms of Security Tokens, one has to consider several aspects that comes into the game here:
KYC
Custody-Services
Operator roles for issuers, custody and exchanges
and many more depending on the issuer region and their law
Following European Legal aspects, Security tokens are handled like Bonds that will be paid back / refund to the investor eventually. Since there is a onchain/offchain communication happening, the issuer might be able to burn the token on the behalf of the investor then and needs therefor a burnable feature on investors behalf.
Also, a direct transfer of a token from Investor A to Investor B might require a offchain-KYC process. Therefor, a whitelisting mechanism is required that will control the transfer()-method or even make it only transferable between an organisation like a Exchange or a custody service provider.
Currently ERC777 goes quiet far, and also ERC 1400 and its successor 1411 which acts more as a roof standard, try to cover different aspects here. We are heavily discussing here with legal partners and financial authorities which of these Sub-ERC’s that are mentioned under ERC 1400/1411 might be worthful to consider.
@Sarah can you tell us your specific requirements? We are currently also working on Security Token contracts and it would be cool to define base contracts here under the Openzeppelin umbrella. But nowadays, nobody really knows the final requirements when it comes to talks with Custody, Financial Authorities and even banks or exchanges. Therefor we need many discussions all together and open standards that could be defined further in upcoming months and years
I wish i could provide some more requirements but we are just starting the specs for this POC and a lot of stuff are still not clear.
However, after some more discussions , i believe in our use case since we are only dealing with fungible tokens, then it will be easier and faster if we go with erc777. We are also thinking of dealing with KYC process for the investors off chain.
In the beginning i thought of using erc1400 because it is THE standard capable of handling all possible situations from document management to error signaling and so on … An investor’s balance can have both fungible and non-fungible tokens … so it seemed to me like it got everything covered up.
But now i think erc777 is a better suited,
Today I’ll have a phone call with a crypto bank and their custody service department to discuss token standardizations and their inbound requirements for that.