Issues while trying to work with ERC1400

I’ve been trying to learn about STO’s , and i am trying to use ERC1400 for an implementation.
I downloaded the code( 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 ?

I looked into erc777 ( which seemed a lot simplier but it’s missing document management so i am trying to understand better erc1400.

Thank you


Hi @sarah,

Welcome to the community :wave:.

I haven’t really looked into ERC1400.

@itinance is there some good background information on STOs?


@Sarah welcome to the community – I have some background and can potentially assist.

Securities flow is much different to ERC20 token issuance.

I am guessing you’ve already watched this CoFi Demo

In the Securities world, an Issuer bears the initial heavy lifting along with the asset Owner, unless they own it out right.

In the above demo, the Issuer creates the asset and invites the Investor to purchase it at a predetermined token prices and offer subscription.

Looks like the security token is un-capped, so that might explain why totalSupply parameter is not required.

The partitions concept is to capture which lifecycle stage the token is currently in.

Based on the demo, a token goes through 3 stages:

  • Locked
  • Reserved
  • Issued

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


@itinance thanks for your comments …helpful!

@Sarah this might be handy for your research EIP-Spec

  • ERC1410
  • ERC1594
  • ERC1643
  • ERC1644

@itinance ++ on defining the base contracts.

I have a similar requirement for a different industry and currently researching and building as we speak.

How do you propose we collaborate on defining and building the base contracts?

@Sarah thanks for getting this convo started


@itinance thanks for the answer,

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,

1 Like

@Sarah, I created a Simple ERC777 token example

@pkr, @itinance, @sarah I have created a topic so that you can kick off discussions for how you want to do this: Discussion: Contracts for STOs ERC1400/ERC1410


Thank you @abcoathup for getting us organised …I might have an update on Terminal + oz SDK later in the week, please stand by.

@Sarah when you’re ready to share, you know we are all ears

@itinance where are you based mate, happy to jump on a quick call

1 Like

Thank you @abcoathup ! i have already found it , but i will some more into it ! Appreciate it ! :smiley:

1 Like

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.

I will report later.