Tokenising Shares: Introducing ERC-884
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
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.
The Technicalities: Extending ERC-20
The ERC20 token provides the following basic features, presented here in Solidity code:
contract ERC20 {
function totalSupply() public view returns (uint256);
function balanceOf(address who) public view returns (uint256);
function transfer(
address to,
uint256 value
) public returns (bool);
function allowance(
address owner,
address spender
) public view returns (uint256);
function transferFrom(
address from,
address to,
uint256 value
) public returns (bool);
function approve(
address spender,
uint256 value
) public returns (bool);
event Approval(
address indexed owner,
address indexed spender,
uint256 value
);
event Transfer(
address indexed from,
address indexed to,
uint256 value
);
}
This is extended by ERC-884 as follows:
/**
ERC20 compatible Token that conforms toname - for use by wallets and exchanges.symbol - for use by wallets and exchanges.ERC20 function MUST be defined.decimals — MUST return 0 as each Token represents/
contract ERC884 is ERC20 {
/*
* This event is emitted when a verified address
* and associated identity hash are added to the contract.
*
* 
*
*
* to be added.
/
event VerifiedAddressAdded(
address indexed addr,
bytes32 hash,
address indexed sender
);
/*
* This event is emitted when a verified address and its
* associated identity hash are removed from the contract.
*
*
*
* to be removed.
/
event VerifiedAddressRemoved(
address indexed addr,
address indexed sender
);
/*
* This event is emitted when the identity hash associated
* with a verified address is updated.
*
*
*
* with the address.
*
*
* be updated.
/
event VerifiedAddressUpdated(
address indexed addr,
bytes32 oldHash,
bytes32 hash,
address indexed sender
);
/*
* This event is emitted when an address is cancelled and
* replaced with a new address. This happens in the case
* where a shareholder has lost access to their original
* address and needs to have their share reissued to a new
* address. This is the equivalent of issuing replacement
* share certificates.
*
*
*
*
* to be superseded.
/
event VerifiedAddressSuperseded(
address indexed original,
address indexed replacement,
address indexed sender
);
/*
* Add a verified address, along with an associated
* verification hash to the contract. Upon successful
* addition of a verified address, the contract must emit
* VerifiedAddressAdded(addr, hash, msg.sender).
* It MUST throw if the supplied address or hash are zero,
* or if the address has already been supplied.
*
*
* by the supplied hash.
*
* verified information.
/
function addVerified(address addr, bytes32 hash) public;
/*
* Remove a verified address and the associated
* verification hash.
* If the address is unknown to the contract then this
* does nothing.
* If the address is successfully removed, this function
* must emit VerifiedAddressRemoved(addr, msg.sender).
* It MUST throw if an attempt is made to remove a
* verifiedAddress that owns Tokens.
*
*
/
function removeVerified(address addr) public;
/*
* Update the hash for a verified address
* known to the contract.
* Upon successful update of a verified address
* the contract must emit
* VerifiedAddressUpdated(addr, oldHash, hash, msg.sender).
* If the hash is the same as the value already stored then
* no VerifiedAddressUpdated event is to be emitted.
* It MUST throw if the hash is zero, or if the
* address is unverified.
*
*
* represented by the supplied hash.
*
* updated verified information.
/
function updateVerified(address addr, bytes32 hash) public;
/*
* Cancel the original address and reissue the
* Tokens to the replacement address.
* Access to this function MUST be strictly controlled.
* The original address MUST be removed from the
* set of verified addresses.
* Throw if the original address supplied
* is not a shareholder.
* Throw if the replacement address is not
* a verified address.
* Throw if the replacement address already holds Tokens.
* This function MUST emit VerifiedAddressSuperseded.
*
*
* This address MUST NOT be reused.
/
function cancelAndReissue(
address original,
address replacement
) public;
/*
* The transfer function MUST NOT allow transfers
* to addresses that have not been verified and
* added to the contract.
* If the to address is not currently a shareholder
* then it MUST become one.
* If the transfer will reduce msg.sender's balance
* to 0 then that address MUST be removed from the
* list of shareholders.
/
function transfer(
address to,
uint256 value
) public returns (bool);
/*
* The transferFrom function MUST NOT allow transfers
* to addresses that have not been verified and added
* to the contract.
* If the to address is not currently a shareholder
* then it MUST become one.
* If the transfer will reduce from's balance to 0 then
* that address MUST be removed from the list of shareholders.
/
function transferFrom(
address from,
address to,
uint256 value
) public returns (bool);
/*
* Tests that the supplied address is known to the contract.
*
*
* 
/
function isVerified(address addr) public view returns (bool);
/*
* Checks to see if the supplied address is a shareholder.
*
*
*
/
function isHolder(address addr) public view returns (bool);
/*
* Checks that the supplied hash is associated with
* the given address.
*
*
*
*
* with the address in addVerified, or
* updateVerified.
/
function hasHash(
address addr,
bytes32 hash
) public view returns (bool);
/*
* The number of addresses that hold tokens.
*
*
/
function holderCount() public view returns (uint);
/*
* By counting the number of Token holders using holderCount
* you can retrieve the complete list of Token holders,
* one at a time.
* It MUST throw if index >= holderCount().
*
*
*
* the given index.
/
function holderAt(uint256 index) public view returns (address);
/*
* Checks to see if the supplied address was superseded.
*
*
*
* superseded by another address.
/
function isSuperseded(address addr) public view returns (bool);
/*
* Gets the most recent address, given a superseded one.
* Addresses may be superseded multiple times, so this
* function needs to follow the chain of addresses until it
* reaches the final, verified address.
*
*
*
* holds the stock.
*/
function getCurrentFor(
address addr
) public view returns (address);
}
Test Cases and Reference Implementation
Test cases and a reference implementation are available at github.com/davesag/ERC884-reference-implementation.
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, but the reference implementation offers a simple form of access control which could easily be extended.
Backwards Compatibility
The ERC-884 standard offers as minimal an extension as possible over the existing ERC-20 standard in order to conform to the requirements of The Act, while maintaining compatibility with ERC-20 itself.
The standard is designed to maintain compatibility with ERC-20 tokens with the following provisos:
The decimals function must return 0 as the tokens must not be divisible.
The transfer and transferFrom functions must not allow transfers to non-verified addresses, and must maintain the list of stockholders.
Shareholders who transfer away their remaining tokens must be pruned from the list of shareholders.
Proviso 1 does not break compatibility with modern wallets or exchanges as they all appear to use that information if available.
Proviso 2 will cause a transfer 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. It is accepted that this will make ERC-884 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.
In addition, rather than return a bool for successful or unsuccessful completion of state-changing functions such as addVerified, removeVerified, and updateVerified, ERC-884 requires that implementations throw an error (preferably by using the forthcoming require(condition, 'fail message') syntax).
Conclusions
ERC-884 tokens offer a mechanism by which a Delaware corporation can maintain an official share register using an Ethereum smart-contract, hosted on the Ethereum blockchain, rather than using a traditional mechanism.
By maintaining compatibility with ERC-20 tokens, ERC-884 tokens can be traded via any cryptocurrency exchange that supports the trading of ERC-20 tokens, thus allowing the company to sidestep the use of a traditional stock exchange, share registry, or transfer agent.
A reference ERC-884 implementation has been published under the MIT open-source license. Interested developers are encouraged to experiment with this as they see fit.
Thanks
I would like to thank Harrison Perl and Tigran Avakyan of C4Coin for their valuable input into the creation of erc-884, as well as Dr Ross Williams, and also Adrian Andreacchio from Industrie&Co for their detailed proofreading of this article.