ERC-884: DGCL Token

Metadata
Status: StagnantStandards Track: ERCCreated: 2018-02-14
Authors
Dave Sag (davesag@gmail.com)
Links
GitHub page

Delaware General Corporations Law (DGCL) compatible share token

Ref: proposing-an-eip-for-DGCL-tokens

Simple Summary

An ERC-20 compatible token that conforms to Delaware State Senate, 149th General Assembly, Senate Bill No. 69: An act to Amend Title 8 of the Delaware Code Relating to the General Corporation Law, henceforth referred to as 'The Act'.

Abstract

The recently amended 'Title 8 of the Delaware Code Relating to the General Corporation Law' now explicitly allows for the use of blockchains to maintain corporate share registries. This means it is now possible to create a tradable ERC-20 token where each token represents a share issued by a Delaware corporation. Such a token must conform to the following principles over and above the ERC-20 standard.

  1. Token owners must have their identity verified.

  2. The token contract must provide the following three functions of a Corporations Stock ledger (Ref: Section 224 of The Act):

    1. Reporting:

      It must enable the corporation to prepare the list of shareholders specified in Sections 219 and 220 of The Act.

    2. It must record the information specified in Sections 156, 159, 217(a) and 218 of The Act:

      • Partly paid shares
      • Total amount paid
      • Total amount to be paid

    3. Transfers of shares as per section 159 of The Act:

      It must record transfers of shares as governed by Article 8 of subtitle I of Title 6.

  3. Each token MUST correspond to a single share, each of which would be paid for in full, so there is no need to record information concerning partly paid shares, and there are no partial tokens.

  4. 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 the tokens re-issued to a new address.

Motivation

  1. Delaware General Corporation Law requires that shares issued by a Delaware corporation be recorded in a share registry.
  2. The share registry can be represented by an ERC-20 token contract that is compliant with Delaware General Corporation Law.
  3. This standard can cover equity issued by any Delaware corporation, whether private or public.

By using a DGCL compatible token, a firm may be able to raise funds via IPO, conforming to Delaware Corporations Law, but bypassing the need for involvement of a traditional Stock Exchange.

There are currently no token standards that conform to the DGCL rules. ERC-20 tokens do not support KYC/AML rules required by the General Corporation Law, and do not provide facilities for the exporting of lists of shareholders.

What about ERC-721?

The proposed standard could easily be used to enhance ERC-721, adding features for associating tokens with assets such as share certificates.

While the ERC-721 token proposal allows for some association of metadata with an Ethereum address, its uses are not completely aligned with The Act, and it is not, in its current form, fully ERC-20 compatible.

Specification

The ERC-20 token provides the following basic features:



This will be extended as follows:




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 from this standard, though the standard does support the requirements.


For example: The SEC requires a crowdsale's website display 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 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 the Identity hash value


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 should maintain an off-chain private database that records the owner's name, residential address, and Ethereum address. The implementer must then be able to extract the name and address for any address, and hash the name + address data and compare that hash to the hash recorded in the contract using the hasHash function. 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




to enable third party auditors to verify that a given Ethereum address is known to the implementers as a verified address.


How the implementers verify a person's identity is up to them and beyond the scope of this standard.


Handling users who have lost access to their addresses


A traditional share register 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 that 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.


Permissions management


It is not desirable that anyone can add, remove, update, or supersede verified addresses. How access to these functions is controlled is outside of the scope of this standard.


Rationale


The proposed standard offers as minimal an extension as possible over the existing ERC-20 standard in order to conform to the requirements of The Act. Rather than return a bool for successful or unsuccessful completion of state-changing functions such as addVerified, removeVerified, and updateVerified, we have opted to require that implementations throw (preferably by using the forthcoming require(condition, 'fail message') syntax).


Backwards Compatibility


The proposed standard is designed to maintain compatibility with ERC-20 tokens with the following provisos:


    

  1. The decimals function MUST return 0 as the tokens MUST NOT be divisible,
    2. 

  2. The transfer and transferFrom functions MUST NOT allow transfers to non-verified addresses, and MUST maintain a list of shareholders.
    3. 

  3. Shareholders who transfer away their remaining tokens must be pruned from the list of shareholders.
    4. 



Proviso 1 will not break compatibility with modern wallets or exchanges as they all appear to use that information if available.


Proviso 2 will cause transfers to fail if an attempt is made to transfer tokens to a non-verified address. This is implicit in the design and implementers are encouraged to make this abundantly clear to market participants. We appreciate that this will make the standard unpalatable to some exchanges, but it is an SEC requirement that shareholders of a corporation provide verified names and addresses.


Proviso 3 is an implementation detail.


Test Cases and Reference Implementation


Test cases and a reference implementation are available at github.com/davesag/ERC884-reference-implementation.


Copyright


Copyright and related rights waived via CC0.