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.
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.
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.
ERC-1450 extends ERC-20.
ERC-1450ERC-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.
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.
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.
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.
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.
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 tokens provide the following functionality:
ERC-20 is extended as follows:
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.
Special care and attention must be taken to ensure that the personally identifiable information of Investors is never exposed or revealed to the public.
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.
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.
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).
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.
ERC-1450 maintains compatibility with ERC-20 tokens with the following stipulations:
function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
function transfer(address to, uint tokens) public returns (bool success);
function approve(address spender, uint tokens) public returns (bool success);
function transferFrom(address from, address to, uint tokens) public returns (bool success);
event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
Test cases are available at https://github.com/StartEngine/ldgr_smart_contracts/tree/master/test.
A reference implementation is available at https://github.com/StartEngine/ldgr_smart_contracts.
Copyright and related rights waived via CC0.