Implications of the Delaware Blockchain Amendments
Kiran K. Garimella
Faculty at USF, Co-Founder, #Kore, technology infrastructure for the world's private capital markets. #KoreChain #digitalsecurities #captable #issuance #RegA+ #RegCF #RegD #Blockchain #Investor #Speaker #Author #Fintech
The Delaware Blockchain Amendments were an outcome of the Delaware Blockchain Initiative. The Amendments were introduced in the Delaware Senate Bill 69 and signed by the Governor on July 21, 2017. This landmark legislation allows Delaware corporations to maintain their stock ledgers on a blockchain.
Andrea Tinianow, the founding director of the Delaware Blockchain Initiative (and ‘Blockchain Czarina’), recently published a very insightful article on the significant gap in the mainstream protocols for security tokens. The gap is in the way the Delaware Blockchain Amendments are interpreted by these security token platforms.
A conservative interpretation of the provision bumps up against one limitation that public blockchains face: performance and scalability. The problem becomes significant when security tokens are involved, since the data payload of securities transactions is larger than that of the data within Bitcoin and other payment-oriented cryptocurrencies and tokens. More importantly, contract execution is way more complicated than technical (or cryptographic) validation of transactions. Even simple contracts can generate a multitude of mini-transactions that need to follow a labyrinth of complex processes in the securities world. All this activity generates more data, exacerbating a problem that currently has no clean solution in fully decentralized public blockchains.
One solution to this problem is to put data generated from securities transactions in an off-chain database and to store the keys on-chain. This can provide some relief for storage but probably have little impact on performance. Even with the limited payload, the Bitcoin blockchain has grown from around 1 MB in 2010 to almost 200 GB nine years later! Transactions speeds continue to be unimpressive. Supporters of Bitcoin deem it unfair to compare its 7 transactions per second with that of Visa (which conducts around 20,000-30,000 or even more transactions per second), since Visa had over 60 years to improve its technology. They might argue that Bitcoin’s transaction speed would match that of Visa if the Bitcoin network too had been able to implement a couple of decades of improvements. But these arguments miss the point: by the time Bitcoin achieves Visa’s throughput, Visa itself could double or treble its own performance. Ethereum too is facing similar issues and currently experimenting with various approaches, including sharding and proof-of-stake.
In any case, putting securities data off-chain goes against the intent of the Amendments. “Thus, although the ERC-884 is designed to transfer shares of stock, the share ownership information is captured in an off-chain database,†says Andrea Tinianow, alluding to a derivative of the ERC-20 protocol. “This arrangement is in stark contrast to what was contemplated by the Delaware Blockchain Amendments….â€
Maintaining all transaction data on-chain is an important factor, both for industry and for regulators. One of the biggest contributors to process inefficiencies is the lack of a definitive, shared ledger (or database, if you will), which would remove the need for reconciliation of accounts. On well-engineered permissioned blockchains, scalability and performance are not issues; in this context, ‘well-engineered’ means no expensive and widespread consensus mechanisms such as proof-of-work that is performed by unknown miners.
The implementation of protocol services is too important to leave it to interpretation and all the subsequent hassle of reconciling varied interpretations. For example, even a most basic sale of security tokens on a secondary market requires up to twenty-five separate sub-transactions and validations involving up to five participants. In order to be robust, real-life implementations demand the ability to handle many more sub-transactions at a more granular level. In current capital markets, all these transactions and sub-transactions do take place, but the majority of them happen after the primary sale transaction occurs. These post-transaction activities fall into various types of activities such as clearance, settlement, reporting, disclosure, and corporate record-keeping. For private companies, the majority of these tasks are performed manually.
There is no debate that the whole process is inefficient, costly, and error-prone. This makes the process an excellent candidate for true smart contracts on a blockchain. But this does not imply that the blockchain makes these tasks unnecessary. From the context of a naive security token protocol, Andrea Tinianow points out in her article, “Tokenized shares do not eliminate many of the types of errors that are symptomatic of a system that relies on third-party intermediaries to manage and control shareholder databases.†A well-engineered chain, including its ecosystem, ensures its digital securities are fully compliant with all the complexities of securities regulation and corporate law, mitigates errors, and creates efficient end-to-end transactions without ignoring the risks.
The Delaware Blockchain Amendments have both direct and indirect implications from a conservative (i.e., safe) perspective:
- All transactions must be on-chain. Off-chain data introduces the risk of data not being in sync among the various participants.
- The complete lifecycle of digital securities must be managed by the chain (if the word ‘chain’ is taken to mean not only the distributed ledger but also its participants). Dealing with only some parts of the lifecycle, such as issuance or trading, and excluding others (such as corporate actions), exposes digital securities to the risk of non-compliance. To emphasize once again, since it bears repetition, compliance is not just about issuance or trading; digital securities spend a majority of their lifetime being subject to, or participating in, corporate actions.
- No one participant in the securities ecosystem can hope to cover all the capabilities required by digital securities transactions. More than the technological and business challenges of one entity doing everything, regulation requires separation of concerns and various types of licenses.
- Without ignoring the valid criticism of regulation being onerous and in many cases unnecessary, we must not forget that the primary reason for much of this regulation is for the protection of investors. The focus of Fintech blockchain pioneers should be on making compliance activities efficient without introducing or propagating risks that the regulation was designed to prevent in the first place.
Regardless of whether the Amendments logically lead to the implications or not (I think they do), it behooves all responsible capital market professionals to ensure the safety, security, compliance, and protection of investors.
Security tokens may be a well-intentioned attempt to overcome the inherent deficiencies of protocols whose roots are in cryptocurrencies and the vision of decentralized public participation. However, open participation by the general public (who generally have no fiduciary responsibilities to the parties of securities transactions), through the medium of an ungoverned public blockchain that comes with the risk of hacking and forking, is a questionable approach.
Digital securities, on the other hand, are fully-compliant and governed instruments that are implemented on permissioned blockchains. If not complete decentralization, they support a much wider decentralized ecosystem than the traditional centralized model. This provides a reasonable, and certainly a more responsible, alternative that also positively impacts performance and scalability. Digital securities, properly engineered, would meet the letter and spirit of the Delaware Blockchain Amendments.
Manager, Customer Success | Intelligent Automation, Cloud Computing, AI
8 个月Kiran, thanks for sharing!
Chief Executive Officer and Co-founder at 044.ai Lab
9 个月Kiran, thanks for sharing!
Consultant, Virtual Speaker, Author at Blockchain Research Institute. Blockchain Instructor for Transformationworx.
5 å¹´A great article.? To add a little more context, all computers wait for input at the same speed, is a simple concept, that is often lost. If you have a thousand (or million computers) synchronizing their ledgers, it will by definition be slow, not because of the speed of the processors, but because of the wait time (latency) between the computers.? Secondly, if two copies of a distributed databases (say) debit an account near simultaneously on two sides of the pond, one of the two transactions,? sidechained need be forgotten or applied in a way that allows for a theoretical double spend. (Read not ACID compliant, the CAP theorem)? So one (obvious) answer to the speed problem is to write most transactions on a sidechain, and write their hash infrequently on the public chain.? In this case, the Blockchain can be considered a cross between a ledger and a log.? ? ? ??
CEO at Silicon Prairie Capital Partners
5 å¹´The myth is that there has to be "one chain to rule them all" -- we don't co-mingle our data with our competitors and there is no reason not have individual chains for each security.? Especially thinly traded issues.? Every company can have it's own chain and use a traditional database system at the exchange.
Great article!? Blockchain is really just a distributed database.? Tired old grey-haired database industry veterans such as myself will recall back in the 80s, when Oracle, Ingres, Sybase & Co were telling us that distributed databases were the future.? Sadly, that turned out not to be the case because the distributed nodes spent more time synchronising with each other than actually performing useful work.? The database vendors quietly scrapped the distributed data model and moved to Big Data models, with data sitting in protected centralised silos in massive data centres.? I can't see any way that Blockchain (in it's current design) can avoid driving itself down the same blind alley that Distributed Databases did, it's just an immutable feature of computer science and data management.? I think I know the answer to the tricky problem of balancing performance, integrity and security in the Blockchain, but I don't think anyone's interested.? Yet...? :)