ERC-1450: ERC-1450 A compatible security token for issuing and trading SEC-compliant securities

Metadata
Status: StagnantStandards Track: ERCCreated: 2018-09-25
Authors
John Shiple (@johnshiple), Howard Marks (howard@startengine.com), David Zhang (david@startengine.com)
Links
GitHub pageDiscussion on Ethereum Magicians

ERC-1450 - A compatible security token for issuing and trading SEC-compliant securities

Simple Summary

ERC-1450 is an ERC-20 compatible token that enables issuing tokens representing securities that are required to comply with one or more of the following Securities Act Regulations: Regulation Crowdfunding, Regulation D, and Regulation A.

Abstract

ERC-1450 facilitates the recording of ownership and transfer of securities sold in compliance with the Securities Act Regulations CF, D and A. The issuance and trading of securities is subject to the Securities Exchange Commission (SEC) and specific U.S. state blue sky laws and regulations.

ERC-1450 manages securities ownership during issuance and trading. The Issuer is the only role that should create a ERC-1450 and assign the RTA. The RTA is the only role that is allowed to execute ERC-1450’s mint, burnFrom, and transferFrom functions. No role is allowed to execute ERC-1450’s transfer function.

Motivation

With the advent of the JOBS Act in 2012 and the launch of Regulation Crowdfunding and the amendments to Regulation A and Regulation D in 2016, there has been an expansion in the exemptions available to Issuers and Investors to sell and purchase securities that have not been "registered" with the SEC under the Securities Act of 1933.

There are currently no token standards that expressly facilitate conformity to securities law and related regulations. ERC-20 tokens do not support the regulated roles of Funding Portal, Broker Dealer, RTA, and Investor and do not support the Bank Secrecy Act/USA Patriot Act KYC and AML requirements. Other improvements (notably EIP-1404 (Simple Restricted Token Standard) have tried to tackle KYC and AML regulatory requirement. This approach is novel because the RTA is solely responsible for performing KYC and AML and should be solely responsible for transferFrom, mint, and burnFrom.

Specification

ERC-1450 extends ERC-20.

ERC-1450

ERC-1450 requires that only the Issuer can create a token representing the security that only the RTA manages. Instantiating the ERC-1450 requires the Owned and IssuerControlled modifiers, and only the Issuer should execute the ERC-1450 constructor for a compliant token. ERC-1450 extends the general Ownable modifier to describe a specific subset of owners that automate and decentralize compliance through the contract modifiers Owned and IssuerControlled and the function modifiers onlyOwner and onlyIssuerTransferAgent. The Owned contract modifier instantiates the onlyOwner modifier for functions. The IssuerControlled modifier instantiates the onlyIssuerTransferAgent modifier for functions.

ERC-1450 must prevent anyone from executing the transfer, allowance, and approve functions and/or implement these functions to always fail. ERC-1450 updates the transferFrom, mint, and burnFrom functions. transferFrom, mint, and burnFrom may only be executed by the RTA and are restricted with the onlyIssuerTransferAgent modifier. Additionally, ERC-1450 defines the functions transferOwnership, setTransferAgent, setPhysicalAddressOfOperation, and isTransferAgent. Only the issuer may call the transferOwnership, setTransferAgent, and setPhysicalAddressOfOperation functions. Anyone may call the isTransferAgent function.

Issuers and RTAs

For compliance reasons, the ERC-1450 constructor must specify the issuer (the owner), the RTA (transferAgent), the security’s name, and the security’s symbol.

Issuer Owned

ERC-1450 must specify the owner in its constructor, apply the Owned modifier, and instantiate the onlyOwner modifier to enable specific functions to permit only the Issuer’s owner address to execute them. ERC-1450 also defines the function transferOwnership which transfers ownership of the Issuer to the new owner’s address and can only be called by the owner. transferOwnership triggers the OwnershipTransferred event.

Issuer Controlled

IssuerControlled maintains the Issuer’s ownership of their securities by owning the contract and enables the Issuer to set and update the RTA for the Issuer’s securities. ERC-1450‘s constructor must have an IssuerControlled modifier with the issuer specified in its ERC-1450 constructor. IssuerControlled instantiates the onlyIssuerTransferAgent modifier for ERC-1450 to enable specific functions (setPhysicalAddressOfOperation and setTransferAgent) to permit only the Issuer to execute these functions.

Register Transfer Agent Controlled

ERC-1450 defines the setTransferAgent function (to change the RTA) and setPhysicalAddressOfOperation function (to change the Issuer’s address) and must restrict execution to the Issuer’s owner with the onlyOwner modifier. setTransferAgent must emit the TransferAgentUpdated event. setPhysicalAddressOfOperation must emit the PhysicalAddressOfOperationUpdated event.

ERC-1450 must specify the transferAgent in its constructor and instantiate the onlyIssuerTransferAgent modifier to enable specific functions (transferFrom, mint, and burnFrom) to permit only the Issuer’s transferAgent address to execute them. ERC-1450 also defines the public function isTransferAgent to lookup and identify the Issuer’s RTA.

Securities

ERC-1450 updates the transferFrom, mint, and burnFrom functions by applying the onlyIssuerTransferAgent to enable the issuance, re-issuance, and trading of securities.

ERC-20 Extension

ERC-20 tokens provide the following functionality:



ERC-20 is extended as follows:




Securities Exchange Commission Requirements


The SEC has very strict requirements as to the specific roles that are allowed to perform specific actions. Specifically, only the RTA may mint and transferFrom securities.


Implementers must maintain off-chain services and databases that record and track the Investor’s name, physical address, Ethereum address, and security ownership amount. The implementers and the SEC must be able to access the Investor’s private information on an as needed basis. Issuers and the RTA must be able to produce a current list of all Investors, including the names, addresses, and security ownership levels for every security at any given moment. Issuers and the RTA must be able to re-issue securities to Investors for a variety of regulated reasons.


Private Investor information must never be publicly exposed on a public blockchain.


Managing Investor Information


Special care and attention must be taken to ensure that the personally identifiable information of Investors is never exposed or revealed to the public.


Issuers who lost access to their address or private keys


There is no recourse if the Issuer loses access to their address to an existing instance of their securities. Special care and efforts must be made by the Issuer to secure and safely store their address and associated private key. The Issuer can reassign ownership to another Issuer but not in the case where the Issuer loses their private key.


If the Issuer loses access, the Issuer’s securities must be rebuilt using off-chain services. The Issuer must create (and secure) a new address. The RTA can read the existing Issuer securities, and the RTA can mint Investor securities accordingly under a new ERC-1450 smart contract.


Registered Transfer Agents who lost access to their address or private keys


If the RTA loses access, the RTA can create a new Ethereum address, and the Issuer can execute the setTransferAgent function to reassign the RTA.


Handling Investors (security owners) who lost access to their addresses or private keys


Investors may “lose” their credentials for a number of reasons: they simply “lost” their credentials, they were hacked or the victim of fraud, they committed securities-related fraud, or a life event (like death) occurred. Because the RTA manages the Issuer’s securities, the RTA may authorize ownership related changes of securities (as long as they are properly notarized and verified).


If an Investor (or, say, the Investor’s heir) loses their credentials, the Investor must go through a notarized process to notify the RTA of the situation and supply a new Investor address. From there, the RTA can mint the “lost” securities to the new Investor address and burnFrom the old Investor address (because the RTA knows all Investors’ addresses).


Rationale


The are currently no token standards that facilitate compliance with SEC regulations. The closest token is ERC-884 (Delaware General Corporations Law (DGCL) compatible share token) which states that SEC requirements are out of scope. EIP-1404 (Simple Restricted Token Standard) does not go far enough to address SEC requirements around re-issuing securities to Investors.


Backwards Compatibility


ERC-1450 maintains compatibility with ERC-20 tokens with the following stipulations:


    

  • function allowance(address tokenOwner, address spender) public constant returns (uint remaining);

      

    • Must be implemented to always fail because allowance is not a legal, regulated call for a security.
      • 

    

    • 

  • function transfer(address to, uint tokens) public returns (bool success);

      

    • As the token holder initiates the transfer, must be implemented to always fail because transfer is not a legal, regulated call for a security.
      • 

    

    • 

  • function approve(address spender, uint tokens) public returns (bool success);

      

    • Must be implemented to always fail because approve is not a legal, regulated call for a security
      • 

    

    • 

  • function transferFrom(address from, address to, uint tokens) public returns (bool success);

      

    • Must be implemented so that only the Issuer’s RTA can perform this action
      • 

    

    • 

  • event Approval(address indexed tokenOwner, address indexed spender, uint tokens);

      

    • Does not have to be implemented. Approval should never be called as the functions that emit this event must be implemented to always fail
      • 

    

    • 



Test Cases


Test cases are available at https://github.com/StartEngine/ldgr_smart_contracts/tree/master/test.


Implementations


A reference implementation is available at https://github.com/StartEngine/ldgr_smart_contracts.


Copyright Waiver


Copyright and related rights waived via CC0.