Today we talking with Ron Gierlach from Tokensoft about ERC-1404, an open source standard for security tokens.
Hello! What’s your background, and what are you working on?
Ron Gierlach, ERC-1404 proponent here. I became interested in cryptocurrency by way of independent economic study during college. After school, I moved into software development and kept the cryptosphere in my periphery. In the weeks after the DAO hack, the space became too exciting to ignore and I left my previous engineering role to dive in. After a few months of learning and building, I joined up with the team at TokenSoft.
To put our objective simply, TokenSoft provides myriad services all with the aim of furthering DeFi’s adoption. These are products for institutions which include KYC / AML screening, investor on-boarding, token issuance, self-custody, as well as strategic assistance in the form of consulting, security training, and advocacy for open standards. A large part of this effort has been developing ERC-1404, an open standard for enforcing restrictions on token transfers.
What’s ERC-1404 backstory?
Helping issuers manage restrictions for token transfers is a huge part of what we do. Our clients need to comply with securities laws and abide by the SEC’s private placement rules. Security tokens, in particular, must trade under restrictions to prevent a counterparty from inadvertently assisting a bad actor in laundering money or worse, directly funding illicit activities.
As other token-issuance service providers began to develop their own transfer restriction approaches we noticed an alarming trend of vendor lock-in. It quickly became apparent that if this trend were to continue, would-be token issuers might find themselves in a deadlock – waiting for exchanges to announce which implementations they intended to support while, at the same time, exchanges waited for issuers to launch sales and add assets to the marketplace.
In response to this concern, we met with issuers, exchanges, regulators, and a range of DeFi infrastructure providers to collect feedback on what was needed to move the industry forward. ERC-1404 is the result of this information gathering: A simple two-function interface, minimally invasive enough that it could sit beneath virtually any issuer’s transfer restriction logic, regardless of the complexity underlying their smart contract(s).
What went into developing ERC-1404?
ERC-1404’s design boasts the following abilities.
- Defining the standard entry point for detecting restrictions on a token’s transfer.
- Allowing for cost-free validation as to whether or not a transfer will succeed, avoiding reverted transactions and wasted gas.
- Providing error messages that are both human-readable and capable of being referenced on-chain.
The scope of the standard has been kept purposefully simple, just two functions. Nevertheless, we have developed a handful of example contracts that support restrictions based on criteria such as the number of token holders, percentage of token ownership, token divisibility, and others.
One limitation of ERC-1404’s approach is that transfer validation must be made as synchronous assessments of on-chain data. This is to say, no oracles or API calls may factor into validating a single transfer call. To do so would require external contract calls and is a deviation of the current ERC-20 standard.
That being said, there is nothing stopping an issuer from implementing additional non-standard functionality, say a method named “transferWithExternalValidation”. Still, I believe it is unlikely that this sort of enforcement of restrictions will be popular in the grand scheme of things.
What’s your business model?
ERC-1404 is an open standard that neither requires an issuer to use TokenSoft products or services nor disqualifies them from employing another company’s smart-contract framework to enforce their transfer-restrictions. It is truly unopinionated in this regard and will remain as such. As a result, the issuer will always have full control of their token’s implementation. I feel strongly that any standard finding itself attached to a business model is not only contrary to the interests of issuers and developers but also out of favor with the spirit of DeFi.
What’s your position on the regulatory landscape today?
I’ll be honest here, it is what it is right now – less than optimal. I do not expect regulators to move at the pace of innovation. Ultimately I believe, given some time, the marketplace’s behavior will inform new policy. However, as regulation veers around the midpoint of sane human coordination, we will likely see any number of measured and crass policies emerge (“You wouldn’t steal a car?”). Regardless, TokenSoft is dedicated to keeping our clients compliant in the eyes of today’s regulators.
What are your goals for the future?
At TokenSoft we have multiple active clients getting ready to launch their ERC-1404 compliant tokens and several more in the pipeline. Additionally, we are in coordination with exchanges to support the anticipated trading and custody of these restricted tokens. As a company, we provide several products and tools to make token administration a better experience for the issuer.
To make building on the standard easier for developers, we are providing and auditing modular implementations of transfer-restricted token contracts. As members of the open-source community, we feel it is our responsibility to build out the future of DeFi and work alongside our fellow journeymen in the process of realizing this vision for the industry.
What are your future thoughts for the DeFi market?
I anticipate and hope for the following:
- Increased focus on transaction privacy; shielded transfers, darkpools, etc.
- Further emphasis on the importance of self-custody and superior tools emerging to support it.
- Overall better language and educational materials to guide public investors into the space.
The future is bright!
Where can we go to learn more?
An informational splash page with high-level explanation of the standard can be found at erc1404.org
For anyone interested in taking a deep-dive into some of our transfer-restricted token implementations, the main repository where supporting work is being done is here on github.
Issue submissions and pull requests are encouraged!
