Managing the ownership and transfer of Security Tokens with Finhaven
Towards technical standards and interoperability of securities on the Ethereum blockchain
Blockchain technology provides the potential to fulfill many of the functions of traditional securities management. It has a built in identification system (each account has a unique address), every transaction is publicly logged (an immutable audit trail), and a smart contract layer (transfer restrictions or other business logic can be automated).
On the other hand, the past 18 months have been characterized by a proliferation of entrepreneurs bringing utility tokens to market. On closer inspection, many of them should be classified as securities, and we are beginning to see the first warnings and de-listing from utility token exchanges.
Finhaven believes that security tokens are part of the next wave. We think we can take some of the regulatory nature of existing securities and upgrade them with the digital first, automation first nature that goes beyond the concept of paper agreements, and sets a framework for global governance.
Tokens on the Ethereum Blockchain
Tokens are themselves smart contracts, or thought of more simply, “apps” or “decentralized apps” (dapps) — code that executes on the public Ethereum blockchain.
Ethereum and other open source blockchain projects follow an open process for submitting standards and changes to the functioning of the software. In the Ethereum community, these are called “Ethereum Improvement Proposals” or EIPs. Before being accepted or approved, they start as “Ethereum Request for Comments” or ERCs, so that the community and other interested parties can review, extend, make comments, and generally improve the proposal.
The acceptance of EIPs follows a very fluid open source collaboration model. But since the work is done out in the open, a pre-standard model can be adopted and turned into working code even without being approved.
The most infamous pre-standard is the ERC 20 “token standard”. It is what has powered Ethereum to host roughly 40 of the top 100 crypto assets globally. This has led to technical standardization among websites, apps, wallets, and exchanges. It has also led to large amounts of unregulated activity, at least some of which is more correctly classified as a security.
From the commonly known ERC 20 phrase, one can see adoption even at the request for comments stage. This standard has now been approved and is officially EIP 20.
There are numerous other ERCs in progress relating to tokens. Notable ones include:
- ERC 223, an attempt to upgrade security and apply other fixes to EIP 20
- ERC 721, a standard for non-fungible tokens supporting everything from land titles to digital cats (authored by another local BC company, Axiom Zen)
- ERC 777, an even newer token standard that likely supersedes and improves on 20 & 223, that Finhaven is looking to base its security tokens on
It is Finhaven’s intent to propose an ERC (internally we call this 999 since the final number is unknown) that begins the process of technical standard setting around what features Security Tokens support.
ERC 999 Restriction of Ownership & Transfer of Tokens
We believe that having a record of token ownership on the public blockchain is valuable for many use cases.
While most people think of tokens or coins as “in” an owners account, they are actually recorded as a balance in a token smart contract. The token contract lists each owner’s addresses and the balance of tokens that that address controls.
A transfer of tokens between two addresses actually calls the “transfer” function of the token contract. The source address (the address “from” which the funds are being transferred) calls the smart contract transfer function. In its base form, this function has a destination address, plus an amount to transfer. If the source contains enough to satisfy the transfer amount, the tokens are debited from one address and credited to the destination.
Our core proposal is that Security Tokens have a check function. Another function is added that contains a list of whitelisted address.
When a transfer request is made, the transfer function additionally checks the destination address to see if it is on the whitelist. If it is not, the transfer fails.
This function could additionally be used to make tokens completely non-transferable.
Token creators could use a variety of on- or off-chain processes to update the whitelist.
Finhaven Token Holder KYC to Support Security Needs
The technical details described above form the starting point for thinking about security tokens.
Another feature of securities is knowing — and oftentimes vetting — the owner of a security either as an individual or corporate entity.
From a regulation point of view, Know Your Customer (KYC) is one way to think of this.
Finhaven’s Platform helps with the technical details of token creation, issuance, and management. Many of these activities happen in a standard web app, before a security token and its accompanying smart contracts are deployed to the public Ethereum blockchain. After deployment, the platform continues to help with on- and off-chain management features — like a friendly web interface to the blockchain — while transfers and other functions can still be publicly inspected and audited on-chain by anyone.
Finhaven’s model will collect KYC information from users on the platform who buy, sell, or transfer tokens. We provide users on the platform with a standard Ethereum address, and link it off chain, in our private database, with their KYC’d identity. Only addresses which have been KYC’d can be on a token whitelist, but anyone can sign up on the platform to be added to the whitelist in order to buy, transfer or otherwise receive these security tokens.
Initially we will need to provide this KYC process with our platform, but this is another area of standardization — a way of protecting privacy of off-chain identities while also sharing claims about nationality, accreditation, or other identity aspects in a decentralized way.
Some examples of organizations and solutions include:
- Decentralized Identity Foundation
- The Civic platform is handling both identity and KYC services
- Coinfirm is targeting AML/CTF, which is important for tracking incoming funds
Emerging Work in Decentralized Security Tokens
We’ve been pleased to see other organizations beginning to come forward and launch open source efforts of standardization. Read the Introduction to Harbor, and check out their R-Token on Github.
We are prepping our own Github releases and will work with the wider community to collaborate on technical and regulatory interoperability. On the regulatory side, we are starting from Canada, which we think is a very good base for broad investor and company appeal. Specifically, the Province of British Columbia (BC) is kind of like the Delaware of Canada — it’s easy and inexpensive to create corporations online with non-resident directors. We are hoping to work with the government on making it a crypto-friendly domicile.
Upcoming Events
We are hosting a Security Token community meetup in Toronto on Tuesday, February 13th.
We will host a similar event in Vancouver in March.
We will be speaking at Monage in April, so we are looking at planning a community meetup in SF on April 16th.
EDCON is in Toronto in early May, and we are tentatively planning a large technical interoperability test and one day Security Token Working Group. Please sign up to save the date. Other events we are hosting, attending, or promoting are listed on our events calendar.
If you want to get involved in the technical and/or regulatory aspects of decentralized Security Token interoperability, please get in touch.
