ERC-884 is an ERC-20 compatible Token that conforms to Delaware State Senate, 149th General Assembly, Senate Bill №69.
The Delaware State Legislature recently passed Delaware State Senate, 149th General Assembly, Senate Bill №69: An act to Amend Title 8 of the Delaware Code Relating to the General Corporation Law, henceforth referred to as ‘The Act’. As a result, Delaware General Corporation Law now explicitly allows for the use of blockchains to maintain corporate share registries.
With this in mind, I am excited to announce that ERC-884 has been accepted as a draft Ethereum token specification.ERC-884 allows for the creation of tradable ERC-20 tokens where each token represents a numberless (or vanilla) share issued by a Delaware corporation. ERC-884 is designed to represent equity issued by any Delaware corporation, whether private or public.
By deploying an ERC-884 token, a firm may be able to raise funds, either via initial public offering (IPO), or by private equity sale, in a manner conforming to Delaware Corporations Law, but bypassing the need for a custom share registry, or the involvement of a traditional stock exchange or transfer agent.
Core Principles
ERC-884 tokens enable conformance with the following principles, over and above the baseERC-20 standard:
Token owners must have their identity verified. Rather than leaving it to a separate crowdsale contract to enforce owner whitelisting, ERC-884 requires that all token owners are whitelisted. The whitelist can be referenced by accompanying crowdsale contracts, to enforce eligibility, but the whitelist remains an integral part of the token contract itself.
The token contract must provide the following three functions of a Corporations Stock Ledger (Ref: Section 224 of The Act):
- It must enable the corporation to prepare the list of shareholders specified in Sections 219 and 220 of The Act.
- It must record the information specified in Sections 156, 159, 217(a) and 218 of The Act.
- It must record transfers of shares as governed by Article 8 of Subtitle I of Title 6.
No Partial ERC-884 Tokens
Each ERC-884 token must correspond to a single unnumbered share, each of which must be paid for in full. There is no need to record information concerning partly paid shares. Similarly there is no requirement for an ERC-884 token to correspond to a specifically numbered share. It is enough to know that a shareholder owns a certain volume of shares. The notion of individually numbered shares is, in this context, needlessly burdensome.
Finally, there must be a mechanism to allow a shareholder who has lost their private key, or otherwise lost access to their tokens, to have their address cancelled and their tokens re-issued to a new address.
Securities Exchange Commission Requirements
The Securities Exchange Commission (SEC) has additional requirements as to how a crowdsale ought to be run and what information must be made available to the general public. This information is, however, out of scope of the ERC-884 standard, though the standard does support such requirements.
For example: the SEC requires that a crowdsale’s website displays the amount of money raised in US dollars. To support this, a crowdsale contract minting these tokens must maintain a USD to ETH conversion rate (via an oracle or some other mechanism) and must record the conversion rate used at time of minting.
Also, depending on the type of raise, the SEC (or other statutory body) can apply limits to the number of shareholders allowed. To support this, the standard provides the holderCount and isHolder functions which a crowdsale can invoke to check that limits have not been exceeded.
Use of an Identity Hash
Implementers of a crowdsale, in order to comply with The Act, must be able to produce an up-to-date list of the names and addresses of all shareholders. It is not desirable to include those details in a public blockchain, both for reasons of privacy, and also for reasons of economy. Storing arbitrary string data on the blockchain is strongly discouraged.
Implementers must maintain an off-chain private database that records the owner’s name, physical address, and the Ethereum address used to own their ERC-884 tokens. The implementer must then be able to extract the name and physical address for any Ethereum address, hash that data, and compare the resulting hash to the hash recorded in the contract using the hasHash function, thus affirming the veracity of their information. The specific details of this system are left to the implementer.
It is also desirable that the implementers offer a REST API endpoint along the lines of
GET https://<host>/<pathPrefix>/:ethereumAddress -> [true|false]to enable third-party auditors to verify that a given Ethereum address is known to the implementers as a verified address.
Exactly how the implementers verify a party’s identity is up to them, and beyond the scope of this standard.
Users Who Have Lost Access to Their Shares
A traditional share registry is typically managed by a Transfer Agent who is authorised to maintain the register accurately, and to handle shareholder enquiries. A common request is for share certificates to be reissued in the case where the shareholder has lost or destroyed their original.
Token implementers can handle this request via the cancelAndReissue function, which must perform the various changes to ensure that the old address now points to the new one, and that cancelled addresses are not then reused.
Source/More: Tokenising Shares: Introducing ERC-884 – Coinmonks – Medium
