Tag: Kiran Garimella

KoreSummit RegA+ 2020

Posted on by Oscar Jofre

KoreSummit is all about education,  We are pleased to be able to offer you the opportunity to receive first-hand knowledge from leading thought leaders to help you in your journey to capital raising.

The KoreSummit RegA+ 2020 online event was a huge success because of you who attended and shared it with your friends.  As promised here are the video segments.

Complete Live Stream

 

RegA+ Verticals

 

Legal RegA+ Global Companies

 

Investor Acquisition/Distribution

 

PR/IR/Social Media/Press

 

Research, Ratings

 

Role of FINRA Broker-Dealer

 

RegA+ Success, the CEO’s

 

The Main Event

 

Digital Securities for RegA+

 

Compliance for RegA+

 

Shareholder Management & Communications

Forbes interview with KoreConX founders

Posted on by Oscar Jofre

Start-Up KoreConX Launches A New Blockchain Network To Connect The Private Capital Market

Robert AnzaloneContributor 

Crypto & Blockchain

Do you know how to invest in the private capital market?  Not many people do.  It is complicated, requires a lot of paperwork, has low transaction volume, comes with risk and volatility, and not very liquid.

Could distributed ledger technology (DLT) be used to reduce back-office fees and expand the market for this asset class?

I interviewed Oscar Jofre, CEO and co-founder of KoreConX, who believes his platform and infrastructure can help.

KoreConX is a company working to change how businesses raise capital.  Mr. Jofre is an advocate for using DLT to bring transparency to a fractured process.  Mr. Jofre mentioned, “There are over 90,000 companies in our platform from around the globe who have raised more than $6.6 billion. Companies who use the KoreConX platform raised capital working with broker-dealers or direct offerings on their own. We are purely providing the technology to make sure they are fully compliant and to manage the entire process.”

What is the private capital market?  What are the problems?

The private capital market represents companies not publicly traded on stock exchanges. Private funds, venture capital investors, and some mutual funds are typically the main buyers.  Investments can be in new start-up enterprises, mature business, or sometimes struggling firms. This type of asset is considered to be highly risky.

One critical problem, the team at KoreConX explained, was the lack of market access for small firms. Dr. Kiran Garimella, KoreConX’s CSO and CTO, said, “The majority of participants in private capital markets are smaller entities who are closely connected with local companies and investors. They cannot afford huge expenses for integrated systems.”  KoreConX specializes in connecting all sizes of firms rather than limiting their scope to more mature enterprises.  Interestingly CEO Oscar Jofre’s background is crowdfunding, which is a driving influence in his business.

Jason Futko, CFO and co-founder, said, “It is often difficult for companies in the private capital markets to identify investors to present their opportunity. The fragmentation in this market can make it difficult to find investors or other professionals to help you grow your business.”

On June 26th, 2019, Broadridge bought from Northern Trust a similar blockchain platform.  There is competition in this space from many players. Mr. Jofre said, “There are companies like Carta, Capshares, ComputerShare, AST, and Link Group that offer some of the features KoreConX provides in our all-in-one platform. We have a much different view of the market. To truly transform it, we need to make sure all participants have all the tools they need. If they don’t, then we will never see any great change in the private capital markets.”

KoreConX launched on October 11th, 2019, their new blockchain ecosystem for fully compliant digital securities worldwide.  Their mission is to ensure compliance with securities regulation and corporate law.  The KoreConX platform includes securitized token issuance, trading, clearing, settlement, management, reporting, and corporate actions.

As explained to me by the management team, the lack of data integrity and regional knowledge of jurisdictional compliance can restrict investment opportunities offered to the public.  Mr. Futko continued, “Obviously part of the solution under KoreConX has to be around connecting document fragmentation, providing access to professionals and creating trust through our blockchain, which ensures both business and regulatory logic.”

Why can blockchain technology help now?

The KoreConX team stated that the private capital markets serve over 450 million private companies worldwide today.  They have a lack of document transparency and high fees. Compare this to public capital markets, which have established listing standards and rules.  Furthermore, open markets are used every day and can handle many transactions.  Dr. Garimella said, “Blockchain offers technology that provides solid mechanisms for trust through immutability and consensus among parties.”

I asked Mr. Jofre to explain why his work was different from larger companies, like Broadridge? He responded, “KoreConX is entering a market with many providers who have a single feature or application. For private capital markets to be as efficient, as public listed markets, it needs an infrastructure layer and an application layer.  KoreConX brings both.  We do not exclude anyone because of size or geography.”

Finality, Settlement, and Validation: The Place to Start

Posted on by Kiran Garimella

One of the most important concepts in capital market transactions is settlement and finality. Even though the payment infrastructure gets the majority of airtime, settlement finality is just as, if not even more, important in the securities markets. In the public markets, the structure of securities and the clearance and settlement process is quite standardized. In the private markets, a segment that is three orders of magnitude larger than the public markets, standardization does not exist. Rather than an issue, this is the strength of the private markets, since both private companies and their investors need flexibility in securities contracts. Regardless of all this, settlement finality is equally important in both markets.

The issue of settlement finality actually applies to all legal contracts in the sense that terms and conditions cannot be stated in probabilistic terms. Would you sign an employment agreement where the fine print says there is a one-in-ten chance that you would not be paid every two weeks?

In justifying Polymath’s latest move to abandon Ethereum as their platform of choice for security tokens, Adam Dossa, Polymath’s head of blockchain, rightly observed, “At the center of contention is ethereum’s consensus mechanism, proof-of-work (PoW), which only offers a statistical guarantee of transaction finality.” As we pointed out early last year in one of our KoreBriefings where we evaluated Ethereum, “Finality [in Ethereum] is probabilistic and not guaranteed.” Probabilistic or even statistical finality in legal agreements just will not do.

In “Principles of Market Infrastructure,” a publication of the Bank of International Settlements, Principle 8 (Settlement Finality) requires that “An FMI [Financial Markets Infrastructure] should provide clear and certain final settlement, at a minimum by the end of the value date. Where necessary or preferable, an FMI should provide  final settlement intraday or in real-time.”

Note the definitive language of “clear and certain final settlement.” This excludes probabilistic or statistical finality. Melvin Eisenberg, Professor of Law at the University of California, Berkeley, says, “The classical law approach to the certainty principle reflects the binary nature of classical contract law. Indeed, this approach is often referred to as the all-or-nothing rule.”1  Prof. Eisenberg goes on to provide examples of the “rejection of a probabilistic analysis.” While much of that treatment is related to damages due to non-performance of contracts, the concept of certain finality is quite relevant for securities transactions. This is a serious issue that has lately garnered a lot of attention.

Settlement finality is a statutory, regulatory, and contractual construct.2  Settlement is actually a two-step process: first is the operational settlement, which consists of all the steps using technology or otherwise to complete the process of trade, transfer, or corporate action. The second step is the legal settlement that happens when the regulatory framework provides the final approval, at which point a transaction is deemed to be fully settled. The problems due to the uncertain nature of operational settlement in Ethereum are well-known, even if generally ignored. The concept of legal settlement, on the other hand, simply does not even exist in the security token protocols based on Ethereum.

Blockchain technology must first achieve operational finality before the regulatory framework can certify legal finality. Public blockchains can only specify probabilistic and statistical finality. Smart contracts have to also provide for legal settlement. A permissioned blockchain such as Hyperledger Fabric is designed for guaranteed finality. The KoreProtocol of KoreChain, a blockchain application built on Fabric for managing the entire lifecycle of private securities, is designed to ensure legal finality also. One example of legal finality is that directors’ approval of private securities trades under certain conditions, as set forth in the shareholder agreement, is necessary before such trades are deemed to be final. The KoreProtocol is designed to capture this requirement and the KoreChain is designed to implement it.

While Polymath is the latest of the Ethereum advocates that has woken up to the fact that Ethereum isn’t the right blockchain platform for financial securities, they have not been the first. Several private companies, their securities attorneys, broker-dealers, and many other participants have noticed this deficiency and chosen to go with permissioned chains such as the KoreChain.

More significantly, Vitalik himself was the first to point this out way back in May of 2016 (over three years ago—a lifetime in crypto-space) in a blog post on Settlement Finality: “This concept of finality is particularly important in the financial industry, where institutions need to maximally quickly have certainty over whether or not the certain assets are, in a legal sense, “theirs”, and if their assets are deemed to be theirs, then it should not be possible for a random blockchain glitch to suddenly decide that the operation that made those assets theirs is now reverted and so their ownership claim over those assets is lost.”

Advocates of public blockchain also seem to be coming to the realization that when financial securities are exchanged between two parties, independent and unverified miners have no legal authority for validating the transaction. Parties who have no fiduciary responsibilities, no regulatory mandate, or any skin in the game cannot perform business validations. Would you ask a stranger in New Zealand to approve the transfer of your shares in a private company to your friend when you, your friend, and the private company are all domiciled in the USA? As Polymath’s Dossa observers, “How ethereum settles transactions through mining also came into consideration for Polymath. Since miners, who process and sign-off on transactions for a fee, can operate anywhere in the world, institutions could face government scrutiny if fees are traced back to a sanctioned country.” More to the point, securities law does not recognize approvals of securities transactions from parties who are not associated with or have any fiduciary responsibility for securities transactions.

Principles of settlement finality and authoritative validation of transactions remain some of the most important cornerstones of establishing trust in the financial markets infrastructure. It is up to the blockchain application designers to understand the spirit and intent of these principles and select technologies that facilitate the implementation of such principles rather than hinder them. It is up to the business participants (company management, securities attorneys, and broker-dealers) to recognize the importance of these principles and the limitations of some blockchain platforms.

Incentives often have unintended consequences. We see this happen often with children and pets. Public blockchains are all about decentralization, but in fact miners’ incentives have all but centralized the blockchains. In contrast, consider that within KoreChain we have not left the question of decentralization to the vagaries of unknown miners. Instead, the KoreChain is engineered for decentralization. It is an implementation of the Infrastructure of Trust that currently runs in production in twenty-three countries; in barebones minimal cruising mode, it is capable of handling approximately 10 billion transactions per year (~318 tps) with consensus on business validity. KoreChain’s architecture also makes it massively scalable with very little effect on performance. However, as Vitalik rightly points out, finality can never be 100% even if the technology can achieve absolute finality since the ultimate arbiter of finality is the legal system. For this reason, KoreChain includes KoreNodes that are owned and operated independently by regulated entities and regulators worldwide.

If you hold fast to the idea that your powerful car is the only way to cross the ocean, you will be in for a continual hack of trying to make your car float on water. It is much better to recognize that a good ship is the right vehicle for the ocean. Many of the challenges of building a compliant securities application on Ethereum are actually unnecessary. Securities regulation in any one country is complicated enough. Multi-jurisdictional capital markets transactions compound that complexity by several orders of magnitude. Application designers should not be distracted by trying to create their own chains; instead, the real achievement lies in making securities transactions fully compliant in all jurisdictions, promoting innovation in financial markets, enabling flexibility, minimizing process costs, and providing an Infrastructure of Trust to which all regulated entities are welcome. 

1 Foundational Principles of Contract Law, Melvin A. Eisenberg
2 http://yalejreg.com/nc/on-settlement-finality-and-distributed-ledger-technology-by-nancy-liao/

The world’s capital markets are too dispersed, complex, and huge for any one participant to dominate. Revolutionizing the capital markets is only possible through collaboration. 

www.InfrastructureofTrust.com

Blockchain Radio’s one on one with KoreConX Chief Scientist/Technology Officer

Posted on by Oscar Jofre

This is a rare occasion to have our very own Dr. Kiran Garimella interviewed by Blockchain Radio’s Pierre Bourque, a leading talk show host for blockchain enthusiasts.

Kiran highlights the need for trust, compliance, and investor protection in the private capital markets. This is why the participants on the KoreChain and the owners of KoreNodes, launched in 23 countries, are regulated entities who are subject to stringent compliance requirements and who have to take on fiduciary responsibilities. 

Kiran explains how the global private capital markets are fragmented, yet the world is becoming globalized and there is a need for cross-jurisdictional opportunities. KoreChain has a large knowledge base on worldwide regulations to help the participants safely navigate through complex securities transactions.

KoreConX is not in the business of risky disruption and disintermediation. Trying to dominate this ecosystem will not work. KoreConX’s Infrastructure of Trust welcomes all reputable participants, including the regulators. KoreConX has already seeded this Infrastructure with an integrated suite of compliance-related applications that are in active use in thousands of companies. Kiran points out that rather than excluding, all are welcome because the Infrastructure of Trust and the all-in-one platform is ‘all about you.’

Hear the lively dialog between Blockchain.Radio’s Pierre Bourque and Dr. Kiran Garimella:

Many Rights Make the KoreProtocol Right

Posted on by Kiran Garimella

Over the last few weeks, we have seen the highly entertaining farce of Craig Wright claiming to be Satoshi Nakamoto by registering a copyright to the original bitcoin whitepaper and code. He may very well be Satoshi. However, registering a copyright does not confer an official recognition of identity. Wei Lu, CEO of Coinsumer, proved it. Reacting to the press releases and social media statements made by Craig Wright and his supporters, the US Copyright office took the extraordinary step of publicly refuting the claim that a copyright registration is the same as official & proven recognition. This prompted the subject line of Coindesk’s May 23rd Blockchain Bites email: “Wright is wrong.”

The public blockchains provide an endless source of fun. Whatever their faults, one can’t blame them for being boring. The responsible, permissioned chains are, in contrast, boring. KoreChain in particular is relatively dull to thrill-seeking outsiders, while extremely exciting to those who truly understand private capital markets and how the KoreProtocol is spearheading innovation for private issuers and investors.

The KoreProtocol defines many types of shareholder rights in private digital securities. These rights, some mandatory and some discretionary, are well-established in securities law and corporate law. The innovation and complexity of shareholders rights is only limited by the willingness and imagination of the participants. In the absence of automation and a single source of immutable truth, the implementation of rights can become a bureaucratic nightmare. This, more than anything, becomes a limiting factor for innovative contracts. By defining shareholder rights rigorously in the KoreProtocol and implementing the full workflows in KoreChain for their exercise, the KoreProtocol and the KoreChain take away the pain and effort of managing these rights. This opens up private capital markets to very flexible and complex shareholder agreements to suit the needs of the participants.

The KoreProtocol and the implementation within KoreChain include rights such as (to give a few of the more prominent examples):

  1. Voting/non-voting
  2. Financial participation in the form of dividends or revenue
  3. Distribution of revenue or dividends as cash, reinvested securities, or other forms of payment
  4. First right of refusal
  5. Tag-along rights
  6. Drag-along rights
  7. Pre-emptive rights

Each of these rights and their numerous variations have implications and consequences in secondary market trading and in corporate actions. The KoreProtocol provides a structured way to define these rights and their impact on securities transactions. The KoreProtocol implements complete end-to-end management of financial transaction processes, some of which may be very long-running.

The definition of protocol functions to handle all the complex scenarios in securities transactions is not a trivial undertaking. However, it is much easier than the actual implementation of the protocol since that requires handling long-running processes and making tradeoffs between manual and automated processes, data sharing mechanisms, and choice of endorsers. Every step of the process must be fully compliant with securities laws, corporate laws, and the provisions of the underlying contracts.

Trying to shoehorn securities transactions into inadequately defined protocols and delegating the implementations to someone else is to do the worldwide financial community a huge disservice. Implementing the rights of issuers and investors is a very complicated undertaking. For example, ERC-1404, in the words of its creators, “…solves for the compliance challenges that are part of the issuance process and beyond.”

How does ERC-1404 solve the problem of whether senders can send tokens to a receiver and whether receivers can receive tokens from a sender? By defining two functions: CanSend() and CanReceive(). The github code itself shows one function:

detectTransferRestriction(fromAddress, toAddress, numTokens) //I made it a bit readable.

With no trace of irony, the authors of this protocol point out that: “The specific logic covering who can send and receive can be configured outside the token contract itself.”

It is easy enough to write protocols as long as we leave the messy details of implementation to someone else!

In reality, the transfer of digital securities in a fully-compliant way is quite complicated. It is not just a matter of “who can send and receive”, but also a question of the circumstances under which securities can be transferred or not. There are complex workflows and numerous checks that need to be followed before any transfers, whether P2P, beneficial, or trade-related, can occur. The checks relate to the jurisdictions and exemptions under which the securities are issued, domicile of the participants, securities laws that govern all subsequent inter- and intra-jurisdictional securities transactions, corporate laws, the rights spelled out in the shareholders’ agreements, and the presence or absence of various types of events such as corporate actions, regulatory actions, and economic events.

To be fair, the creators of simplistic protocols may very well be aware of these complexities; however, the fact remains that they come nowhere near expressing the richness and complexity of global private capital markets. Also, they offer no guidelines for implementation or even a hint of the treacherous complexities.

At KoreConX and in KoreChain, knowing the business as we do by being an SEC-registered transfer agent, we chose to not only develop a comprehensive protocol but also implement it in all its complexity. Tapping into our worldwide partner network of securities lawyers, secondary market operators, broker-dealers, academics, and other thought-leaders, we tackled the problem by creating a legal base that incorporates much of the complexity of securities law and corporate law worldwide. This includes inter-jurisdictional transactions, Blue Sky laws in the US, Canadian provincial laws, etc.

Private capital markets provide enormous flexibility for creating complex shareholders’ agreements. We have so far not seen two offerings or agreements that are similar. The public markets are relatively standardized, which can be a strength in terms of offering liquidity at the expense of flexibility of contracts. Private companies and their investors want more control and flexibility.

By incorporating the various types of rights (some mandatory, some optional, and some that are negotiated) into the KoreProtocol and implementing through the KoreChain, our mission is to create the right infrastructure to preserve and foster innovation in global private capital markets while also furthering the cause of efficient liquidity.

www.koreconx.com

www.KoreConX.io

Who do you trust with your Crypto?

Posted on by Kiran Garimella

“The great thing about trustless cryptocurrency systems is just how many incompetents you have to trust along the way.” – David Gerard, author of Attack of the 50 Foot Blockchain.

Lately, I’ve stopped reading fiction because real life drama with public blockchains is way more entertaining. The fun never stops.

For example, one tragi-comedy began when the CEO of QuadrigaCX allegedly passed away a few months ago. Unfortunately, he never put the private keys to the company’s crypto millions into safe custody. In a traditional banking system, this would have been a mild inconvenience at worst, if even that. Bankers, like all humans, pass away, retire, or move on. When was the last time you went into conniptions because your bank manager quit?

The QuadrigaCX soap opera was just getting started. After going into regulatory protection (which in itself is a bit ironic for those “investors” who are using crypto as a statement against regulation), QuadrigaCX manages to lose some more by “inadvertently” transferring some money into another wallet from where the money cannot be retrieved. In the traditional banking system, when you sign up for direct deposit or do a wire transfer, considerable verification happens upfront to make sure the numbers and recipients are valid; further, both parties agree that deposits made in error can be reversed by the financial institution.

In another episode, Ernst & Young, appointed by regulators, discovered that six of the cold wallet addresses used by QuadrigaCX apparently haven’t had any balances in them since one year.

I realize many investors lost money in this and similar ventures when common sense suggests they should have stayed away. While this is unfortunate, I don’t believe these investors are ‘main-street’ investors, but reckless risk-takers for whom I have less sympathy. That’s why I’m looking forward to future episodes; this is entertainment at its best!

Public blockchains have been popularly known as the ‘trustless system.’ Strictly speaking, they should have been called ‘the system where you don’t have to trust authoritative institutions, government, central bankers, or any individual of the establishment’, though that lacks marketing pizzaz.

Instead of reposing trust in centralized institutions and in humans with traditional roles, public blockchains transfer that trust to the mathematical algorithms that power cryptocurrency operations such as mining.

Cryptography is an excellent trust mechanism and practically unbeatable, but only under specific conditions and only up to a point. Cryptography cannot undo the actions of those who operate crypto-exchanges, online capital-raising platforms, the crypto-majority (i.e., 51%, or whatever constitutes the quorum for making changes), the software writers, wallet makers, wallet operators, public addresses that are fronts for scammers, and so on. Most of these participants are not fraudulent, but that’s beside the point. Storing your life savings in Fort Knox is of no use if you lose your keys! To the end user, the effect of fraud, incompetence, or error in cryptos is the same and equally disastrous.

Traditional finance has a number of interlocked trust mechanisms: reputation, credentialing, registration, regulatory filings, auditing, established operational procedures, and various checks and balances. Does this make fraud impossible? Hardly. Does this prevent the consequences of incompetence? Not at all.

Fraud, incompetence, and mistakes are here to stay for the foreseeable future. In addition to all this, there’s technology risk. Generally speaking, it is very tough to eliminate risk entirely. The best we can do is to disperse the risk in a way that it becomes economically unrewarding to engage in criminal activity by the vast majority of participants. For the remaining risk that just cannot be eliminated (given the unending human penchant for mischief), the parties are protected through a variety of safety nets. As in all meaningful things, available trade-offs redistribute advantages and disadvantages. In the case of cryptos, the questionable advantage of censorship-resistance comes at the price of increased risk. Increased security in the case of permissioned financial blockchains comes at the price of complying with regulations.

In the real-world, trade-offs are unavoidable and blockchains expand the available trade-offs. Unfortunately, that includes the ability to choose to trust unsavory and incompetent participants at the entry and exit points of the public blockchain.

In securities, permissioned blockchains offer increased process efficiency, facilitate liquidity (but cannot create it), and enable stronger compliance across multiple participants. As far as securities are concerned, both types of blockchain offer strong cryptographic basis for technical validations. But you do have a choice. You can choose to trust that unknown participants are not out to scam you, CEOs have kept all private keys safely, no founder is going to perform an unorthodox exit, that transactions are meaningful (and not just the same scam artists moving stuff around continually to create artificial trading volume or manipulating prices), that miners will continue to mine and validate transactions even when crypto prices tank, that some miners won’t collude to obtain majority hashing power and create an adversarial fork (the new ‘F’ word in crypto-world), and that some dictator won’t fund a hashing takeover. You also have to trust the technology to scale properly and that it will continue to thrive and improve, and that the software programmers won’t make any major mistakes that will cause all your crypto to vanish into la-la land.

The alternative is to trust the verification of identities and KYC/AML checks, the registrations of broker-dealers and ATS operators (with SEC, FINRA, etc.), the registration of the transfer agent, money transmitter licenses, regulatory filings, securities lawyers (and their registrations and bar memberships), etc.

You actually can have both! Here’s how:

Public blockchain: Crypto Kitty

Permissioned blockchain: Family Kitty.

Now, was that so difficult?

The Right Technology – The Case of Mercury Cash

Posted on by Kiran Garimella

Nothing proves the wisdom of choosing the right technology for the right job than the case of Mercury Cash, a hosted-wallet solution for real-time liquidation and transfer of cryptocurrency and fiat assets. Recognizing the importance of being prepared for a new cryptoworld, Mercury Cash set out to explore various blockchain protocols to find the one that can stand the test of the real world.

The real world is full of messy complexities. We may think the mess is unnecessary and we should sweep it all away and usher in a new world order, but we do have to recognize that regulation and corporate law make it possible to protect investors and shareholders.

As someone pointed out regarding the tragic debacle of QuadrigaCX, Canada’s own Mt. Gox, “When was the last time your banker died and you lost access to your money?”

I’d add, “When was the last time you forgot your bank account password and your money became irretrievable?”

Can regulation and corporate legal processes be more efficient? Yes.

Are some of the regulatory requirements onerous or unnecessary? Yes.

But pretending that all regulation is unnecessary is like pretending that protections are unnecessary. Disruption with technology is good, as long as it doesn’t lead to destruction!

Click here to download Mercury Cash Case Study.

Many issuers are finding out the hard way two fundamental truths about how the real world works:

One, transactions don’t exist in atomic silos, least of all in securities; every transaction is connected with others and impacts multiple entities at various points in time in an ever-expanding ripple effect. One buy/sell securities trade requires validation of participants, ensuring protection for all parties, recording changes to captables, distribution of dividends, exercise of rights, filing reports, getting notifications of corporate events, voting, etc., all of it over a long time cycle.

Two, choosing a technology based on hype, popularity, and promise is not the way to go; instead, understand the characteristics of the problem and then identify the technology to solve it effectively.

In the case study, Mercury Cash describes the capabilities that will keep their business processes humming in a fully compliant manner. Most importantly, they found that ERC20-based protocols are inadequate for full lifecycle management of securities. This is not a knock against Ethereum, which is a fine platform for many types of DApps; much of the technology work is praiseworthy. But a Ferrari, no matter how shiny or powerful, cannot sail the high seas.

Many of our clients are coming to the same realization. Interestingly enough, a company could conduct its main business using public blockchain, while managing its security tokens on KoreChain. There is nothing wrong with that – it’s just like transporting a car on a ship. In many conversations with some of these technologists, I point out that the issue is not that ERC is inadequate for securities, just that it’s not the right tool. The same can be said if someone tries to use KoreChain for building cryptokitties.

When many companies are coming to us abandoning ERC20 protocols for various reasons, it validates our own approach to technology: first understand the problem you are trying to solve, then carefully pick the technology stack to solve it. In doing so, some of us have to leave our technology egos behind to move forward.

Click here to download Mercury Cash Case Study.

Decentralized vs Distributed Systems Part I

Posted on by Kiran Garimella

Blockchain per se is not about decentralization; rather, it is a distributed system technology. The two terms, decentralized system and distributed system, are often confused, so much so that the term ‘blockchain’ seems almost synonymous with a public, decentralized system.

The usual picture used to show the distinction between decentralized versus distributed systems is the one below:

This picture is inadequate since it doesn’t draw a clear distinction between decentralized and distributed systems. The differences in the pictures are rather arbitrary. A slight re-arrangement of the layout of the nodes might convert a decentralized picture to a distributed one or vice-versa.

Decentralization should be rightly used in the context of decision-making, power, authority, and control. Distributed systems are about geographical diversification of storage or processing. The terms ‘centralization’ and ‘decentralization’ come with the baggage of value judgment and philosophy, while the phrase ‘distributed systems’ has a purely technical connotation.

Centralization is about power, control, authority, accountability, and risk management. Distributed systems are about partitioning, dispersing, or part ownership of storage or computational capacity.

All decentralized systems are distributed practically by definition. However, not all distributed systems are decentralized. Enterprise systems at large companies can be distributed, but the company holds all power and decision-making centrally.

The other point to note is that centralization is not automatically evil and decentralization is not automatically good. It depends on the context and the way an application is implemented.

Similarly, distributed systems are not automatically efficient. Poor architectural choices may provide none of the benefits of distributed systems and may increase vulnerabilities.

Centralization becomes a problem only if participants have an incentive to take unfair advantage and the system—by whatever name we call it—allows such manipulation. We also have to recognize that not all problems can be solved through technology alone. If that were true, there would be no need for partnerships, service-level agreements, intermediaries, and so on. So, the real challenge is to create an architecture that leverages technology in a cost-effective way while delegating the rest of the problems to the human institutions or social networks.

In a subsequent post, I’ll point to different ways of understanding the nuances between the two, including references from both the public blockchain and academic communities. I’ll also discuss the challenges of designing incentives in decentralized and distributed systems.

 

Technologies of Blockchain Part 4: Conclusion

Posted on by Kiran Garimella

In parts 1, 2 and 3, we briefly touched on some of the historical foundations of blockchains from computer science and mathematics, including their sub-topics such as distributed systems and cryptography. Specific topics in either of these categories were consensus mechanisms, fault-tolerance, scaling, zero-knowledge proofs, etc.

Obviously, this brief series doesn’t do justice. The history of computing and mathematics is rich, with many interconnections and dependencies. The goal of this series was to provide just enough to make the point that the technologies that power blockchain (whether public or private) were built on a well-established foundation of various topics with contributions from real scientists in both industry and academia. The graphic below depicts the broad brush-strokes of development, clearly showing how current blockchain technologies are based on a wide spectrum of historical developments.

Technologies of Blockchain – Historical Timeline

Conclusion
As you can see, a tremendous amount of development that took place for almost half a century made the modern blockchain possible. Bringing these technologies together—almost all of them based not on just techniques but deep mathematical foundations—into a cohesive whole in the form of a bitcoin application was no doubt a tremendous achievement in itself

Moving forward, we need to keep in mind the initial motivation for each of these technologies, their strengths, their limitations, and determine how to create different architectures based on business needs. A good example of this is to relax the requirements of anonymity, strengthen safety, incorporate recourse, improve security, and incorporate the enormous complexity of regulatory compliance in securities transactions. Making such trade-offs doesn’t detract from the need for public, decentralized blockchains. On the contrary, this strengthens the use of the blockchain technology ‘horizontally’ across many industries and use cases.

In the near future, we expect to see some innovation in blockchains to improve performance and scalability, which is a special challenge for public blockchains. Along the same lines, there will be new consensus mechanisms going mainstream (such as proof-of-stake). For consensus and validation, blockchain researchers are investigating efficient implementation of zero-knowledge proofs and specific variants such as zkSNARKs.

Read Part 1: The Foundations, Part 2: Distributed Systems and Part 3: Cryptography, Scaling, and Consensus

Technologies of Blockchain Part 3: Cryptography, Scaling, and Consensus

Posted on by Kiran Garimella

In Part 2, we saw how a simple concept of a linked list can morph into complex, distributed systems. Obviously, this is a simple, conceptual evolution leading up to blockchain, but it’s not the only way distributed systems can arise. Distributed systems need coordination, fault tolerance, consensus, and several layers of technology management (in the sense of systems and protocols).

Distributed systems also have a number of other complex issues. When the nodes in a distributed system are also decentralized (from the perspective of ownership and control), security becomes essential. That’s where complex cryptographic mechanisms come into play. The huge volume of transactions makes it necessary to address performance of any shared or replicated data, thus paving the way to notions of scaling, sharding, and verification of distributed data to ensure that it did not get out of sync or get compromised. In this segment, we will see that these ideas are not new; they were known and have been working on for several decades.

Cryptography

One important requirement in distributed systems is the security of data and participants. This motivates the introduction of cryptographic techniques. Ralph Merkle, for example, introduced in 1979 the concept of a binary tree of hashes (now known as a Merkle tree). Cryptographic hashing of blocks was implemented in 1991 by Stuart Haber & W. Scott Stornetta. In 1992, they incorporated Merkle trees into their scheme for efficiency.

The hashing functions are well-researched, standard techniques that provide the foundation for much of modern cryptography, including the well-known SSL certificates and the https protocol. Merkle’s hash function, now known as the Merkle-Damgard construction, is used in SHA-1 and SHA-2. Hashcash uses SHA-1 (original SHA-0 in 1993, SHA-1 in 1995), now using the more secure SHA-2 (which actually consists of SHA-256 and SHA-512). The more secure SHA-3 is the next upgrade.

Partitioning, Scaling, Replicating, and Sharding

Since the core of a blockchain is the database in the form of a distributed ledger, the question of how to deal with the rapidly growing size of the database becomes increasingly urgent. Partitioning, replicating, scaling, and sharding are all closely related concepts. These techniques, historically used in enterprise systems, are now being employed in blockchains to address performance limitations.

As with all things blockchain, these are not new concepts either, since large companies have been struggling with these issues for many decades, though not from a blockchain perspective. The intuitively obvious solution for a growing database is to split it up into pieces and store the pieces separately. Underlying this seemingly simple solution lies a number of technical challenges, such as how would the application layer know in which “piece” any particular data record would be found, how to manage queries across multiple partitions of the data, etc. While these scalability problems are tractable in enterprise systems or in ecosystems that have known and permitted participants (i.e., the equivalent of permissioned blockchains), it gets trickier in public blockchains. The permutations for malicious strategies seem endless and practically impossible to enumerate in advance. The need to preserve reasonable anonymity also increases the complexity of robust solutions.

Verification and Validation

Zero-knowledge proofs (ZKP) are techniques to prove (to another party, called the verifier) that the prover knows something without the prover having to disclose what it is that the prover knows. (This sounds magical, but there are many simple examples to show how this is possible that I’ll cover in a later post.) ZKP was first described in a paper, “The Knowledge Complexity of Interactive Proof-Systems” in 1985 by Shafi Goldwasser, Silvio Micali, and Charles Rackoff (apparently, it was developed much earlier in 1982 but not published until 1985). Zcash, a bitcoin-based cryptocurrency, uses ZKPs (or variants called zkSNARKs, first introduced in 2012 by four researchers) to ensure validity of transactions without revealing any information about the sender, receiver, or the amount itself.

Some of these proofs and indeed the transactions themselves could be implemented by automated code, popularly known as smart contracts. These were first conceived by Nick Szabo in 1996. Despite the name, it is debatable if these automated pieces of code can be said to be smart given the relatively advanced current state of artificial intelligence. Similarly, smart contracts are not quite contracts in the legal sense. A credit card transaction, for example, incorporates a tremendous amount of computation that includes checking for balances, holds, fraud, unusual spending patterns, etc., with service-level agreements and contractual bindings between various parties in the complex web of modern financial transactions, but we don’t usually call this a ‘smart contract’. In comparison, even the current ‘smart contracts’ are fairly simplistic.

Read Part 1: The Foundations, Part 2: Distributed Systems and Part 4: Conclusion

Technologies of Blockchain – Part 2: Distributed Systems

Posted on by Kiran Garimella

We saw in Part 1 that linked lists provide the conceptual foundation for blockchain, where a ‘block’ is a package of data and blocks are strung together by some type of linking mechanism such as pointers, references, addresses, etc. In this Part 2, we will see how this simple concept gives rise to powerful ideas that lay the foundation for distributed systems.

What happens when one of the links in the linked list or one of the computers (aka, ‘nodes’) in a distributed system falls sick (and responds slowly), gets taken down (‘hacked’), or dies? How does the full list (or chain) recover from such tragic events? This brings us to the notion of fault tolerance in distributed systems. Once changes are made to the data in one of the nodes (blocks), how do we ensure that the same information is consistent with other nodes? That introduces the requirement for consensus.

Pushing the analogy of the linked list a bit further, algorithms that manage linked lists are carefully designed not to break the list. Appending links to the end or the front, for that matter, is an easy operation (we just need to make sure that the markers that indicate the start and end of the list are updated correctly). However, removing a link (or member of the chain) or adding one is a bit trickier. When it is necessary to remove or insert into the middle of the list, it’s a bit more complicated, but a well-understood problem with known solutions. We won’t go into the specifics in this article because the intent is not to describe these operations but to convey a high-level historical perspective.

In distributed systems, fault tolerance becomes a very important topic. In one sense, it is a logical extension to managing a linked list on a single computer. Obviously, in real-world applications, each of the nodes in a distributed system are economic entities that depend on other economic entities to achieve their goals. Faults within the system must be minimized as much as possible. When faults are inevitable, recovery must be as quick and complete as possible. Computer scientists began studying the methods of fault tolerance in the mid-1950s, resulting in the first fault-tolerant computer, SAPO, in Czechoslovakia.

Besides fault tolerance, when information needs to be added to the distributed system (a bit like adding, deleting, or updating the elements of a linked list), the different parties must agree. The reason for agreement is that the data that goes into the ‘linked list’ is data that arises out of transactions between these parties. Without agreement, imagine the chaos! My node would record that I sent you $90 while your node would record only $19! Or, if I send you payment for a product, I expect to receive the product. There should be agreement, settlement, and reconciliation between the transacting parties. A stronger requirement in distributed systems is that once the parties agree to something, the data that is agreed upon cannot be changed by one of the parties without the concurrence of the other party or parties. The strongest version of this requirement is ‘immutability’, where it is technically impossible to make any changes to data that is agreed to and committed to the chain.

Fault-Tolerance and Consensus

Distributed systems, therefore, require fault-tolerance, consensus, and immutability in varying degrees, depending on the needs of the business. Mechanisms for fault-tolerance and consensus evolved since the early days. Notable developments are:

  • Byzantine Fault Tolerance (BFT) by Lamport, Shostak, and Pease in 1982, to deal with situations where one or more of the nodes in the distributed system become faulty or malicious.
  • Proof-of-Work (POW), first described in 1993 and the term coined in 1999, which is a technique for providing economic disincentives for malicious attacks. A precursor idea of POW was proposed in 1992 by Cynthia Dwork and Moni Naor, as a means to combatting junk mail—a problem that was already a significant nuisance way back in 1992!* Their solution was to require a sender to solve a computational problem that was easy enough for sending emails normally but becomes computationally expensive for sending massive amounts of junk emails.
  • Hashcash, a POW algorithm, was proposed by Adam Back in 1997. This was used as the basis of POW in bitcoin by Satoshi Nakamoto in 2008, which brought awareness of POW to a much wider audience.
  • A high-performance version of BFT, called Practical Byzantine Fault Tolerance (PBFT), by Miguel Castro and Barbara Liskov, in 1999; and so on.
  • Paxos**, a family of consensus algorithms, has its roots in a 1988 work by Dwork, Lynch, and Stockmeyer, and first published in 1998 (even though conceived several years earlier) by Leslie Lamport.
  • Raft consensus algorithm was developed by Diego Ongaro and John Ousterhout. Published in 2014, it was designed to be a more understandable alternative to Paxos.

State machine replication (SMR) is a framework for fault-tolerance and consensus is a way to resolve conflicts or achieve agreement on the state values. SMR’s beginnings are in the early 1980s, with an influential paper by Leslie Lamport, “Using Time Instead of Timeout for Fault-Tolerant Distributed Systems” in 1984.

In Part 3, we will do a high-level review of mechanisms designed to keep distributed systems secure, consistent, and able to handle large volumes of transactions.

Read Part 1: The Foundations, Part 3: Cryptography, Scaling, and Consensus, and Part 4: Conclusion

*Their paper, “Pricing via Processing or Combatting Junk Mail”, begins with a charming expression of exasperation: “Some time ago one of us returned from a brief vacation, only to find 241 messages in our reader.”

**No known relation to the blockchain company, Paxos.com

Technologies of Blockchain – Part 1: The Foundations

Posted on by Kiran Garimella

Blockchain is not just a single technology but a package of a number of technologies and techniques. The rich lexicon in the blockchain includes terms such as Merkle trees, sharding, state machine replication, fault tolerance, cryptographic hashing, zero-knowledge proofs, zkSNARKS, and other exotic terms.

In this four-part series, we will provide a very high-level overview of each of the main components of technology. In reality, the number of technologies, variations, configurations, and considerations of trade-offs are numerous. Each piece in this puzzle was motivated by certain business requirements and technical considerations.

In this first part, we look at the origins of the ‘chain’ and the most important technological advancement that makes blockchain (and all e-commerce) possible, i.e., the Internet.

While there have been genuine innovations within the last decade, blockchain’s underlying technologies are mostly quite old (in computer science time scale). Let us unpack a typical blockchain to trace out the origins of the constituent technologies. In this short post, I’ll only point to a very small (some may say, infinitesimally small) subset of the historical origin of technologies that make the modern blockchain possible. I’ll make no attempt to trace the development of these concepts from origin to the present time (that would fill up several books). The fact that blockchain’s technologies have a long and respectable history should help us gain confidence that blockchain, as a technology, is not some fly-by-night, newfangled idea cooked up by the crypto fandom.

What is less certain and much more controversial is the economic justification for blockchain (or at least some types of blockchain), ranging from the unrealistic expectation that it is a panacea for all of humankind’s ills (most optimistically, for social and economic inequities), to the total and premature dismissal of blockchain in its entirety.

The Beginnings

At the conceptual heart of blockchain is the ‘chain’. By definition, the links of the chain are, well, linked. It’s a list of data elements or packets of information (in blockchain, these are called ‘blocks’) that are linked. A blockchain is, therefore, a type of linked list.

The concept of a linked list was defined by pioneers of computer science and artificial intelligence, Alan Newell, Cliff Shaw, and Herbert Simon, way back in 1955-56.

In the early days of computer science, data and processing power lived on individual computers. Soon, people wanted these computers to ‘talk’ to each other. The grand idea of an Intergalactic Computer Network was put forth by J. C. R. Licklider as early as 1963. Unfortunately, even after half a century of rapid development, we have achieved only a planetary-wide Internet so far. An ‘intergalactic’ network is still a few years away!*

These ideas and the need to connect dispersed computers gave rise to wide-scale distributed systems in the 1960s-70s, with the advent of ARPANET and Ethernet. Technically, these linked computers are not necessarily treated in the same way as a traditional linked list that lived on one computer, but the conceptual idea is similar. When data and computational power get dispersed, layers of management, coordination, and security become increasingly important.

Blockchain would not exist without the Internet, which itself would not exist without TCP/IP, developed by Bob Kahn and Vint Cerf in the 1970s and ‘80s. Along the way, some scientists managed to have some fun too. They carried out an April Fools prank in 1990 by issuing an RFC (1149) for IPoAC protocol (IP over Avian Carriers, i.e., carrier pigeons). The punch line was delivered in April 2001 when a Linux user group implemented CPIP (Carrier Pigeon Internet Protocol) by sending nine data packets over three miles using carrier pigeons. They reported packet loss of 55%. A joke that takes a decade to pull off is practically Saturday night live comedy in Internet time scale!

In part 2, we will see how the extension of the concept of linked list on the Internet leads to distributed systems, the attending challenges, and their solutions.

Read Part 2: Distributed Systems, Part 3: Cryptography, Scaling, and Consensus, and Part 4: Conclusion 

*We first need to take care of a minor detail: find or colonize alien planets in this and other galaxies.

The Three Fallacies of Smart Contracts

Posted on by Kiran Garimella

Smart contracts have become popular due to the extensibility of the Ethereum blockchain beyond its main foundation as a cryptocurrency platform, where it competes with Bitcoin. The phrase ‘smart contract’ caught on in the popular imagination. After all, contracts are important mechanisms for transacting business, and what better than to make our contracts smart with computers and artificial intelligence.

Unfortunately, the glib phrase ‘smart contracts’ hides the ugly truth, which consists of three fallacies:

  1. Smart contracts are smart
  2. Smart contracts are contracts
  3. Smart contracts are comprehensible

Smart contracts are approximately dumb

There’s nothing smart about smart contracts. Perhaps ‘smart’ is a matter of definition, so let me rephrase. If a simple “Hello, World!” program is considered smart, then so is a smart contract ‘smart.’ Maybe we can raise the bar one notch. Let us consider a simple program that, when you access it, determines the time of day (wherever the server on which the program runs or perhaps the browser from which a user invokes it). The code in the program implements the following logic:

If Time >= 6:00 am AND Time < 11:30 am THEN say “Hello, good morning!”

If Time >= 11:30 am AND Time < 3:00 pm THEN say “Hello, good afternoon!”

If Time >= 2:00 pm AND Time < 9:00 pm THEN say “Hello, good evening!”

If Time >= 9:00 pm AND Time <= 12:00 am THEN say “Good night, sleep well!”

If Time > 12:00 am AND Time < 6:00 am THEN say “Hi, you are up late – or did you get up early?”

The above are examples of what is called an IFTTT or “If This Then That” code. This is a bit more intelligent, but just barely. However, this is not necessarily smart enough in the financial world. The ERC-20 and its derivatives in the Ethereum world would have, one hopes, a bit more complicated IFTTT ‘rules’. For example, the protocol has a function that checks to see if the sender of the cryptocurrency actually has the amount in their account. This check is obviously important and a ‘smart’ thing to do. But, this type of check is performed by your bank when you use your bank’s debit card or credit card. However, banks don’t call their cards ‘smart cards’, even though there is more intelligence built into card processing than we give credit for.

In the age of artificial intelligence and machine learning, calling the above types of simple functionality ‘smart’ is an insult to the definition of ‘smart’. Even the earliest examples of AI software of the 60s were smarter. So, calling these ‘smart contracts’ smart is a throwback to prehistoric days of software engineering.

Incidentally, the moniker “IFTTT” is a bit of intellectual plagiaristic packaging passing off as a recent innovation. In reality, IFTTT has been around ever since the very first days of computing. All programmers know this, as well as it’s cousin, IFTTTE, which is “If This Then That Else.” Enough of this remarketing of old and well-known programming constructs.

Smart contracts are not contracts

Technologists who drool over smart contracts are obviously unfamiliar with what constitutes a contract. A loose definition of ‘contract’ may be fine for most casual applications, but for the financial world, the definition has to be legal and enforceable. Legally enforceable contracts have certain specific characteristics without which they don’t stand a chance of being defensible or enforceable. These characteristics include offer and acceptance, competence, unforced, mutual consideration, legal intent, and enforceable.

Transactions involving cryptocurrency or security tokens do not automatically become contracts because the transactions may violate one or more of the above provisions.

  1. Offer and Acceptance: One of the parties must make an offer; the other must accept it. The offer and acceptance are subject to the other requirements of contracts. For example, if someone comes up to your car when you are stopped at a red light, polishes your windshield without your consent, and demands payment, it does not obligate you, legally or morally, to pay; there was no offer of a service and you did not consent to the polishing of your windshield.
  2. Competence: Both parties must be of sound mind and competent to enter into a contractual relationship. For example, those who are mentally incompetent (in the legal sense) and minors may not enter into contracts. This assumes that the identity of the parties is known to each other and each party – or perhaps an intermediary – can assess competence. This may not be true in a decentralized crypto world.
  3. Unforced: Both parties must have entered into the contract of their own free will and knowledge. This may not be true in the crypto world where cryptocurrency can be stolen, forced at gunpoint, or mistakenly sent to another party. In all cases, the sender (or victim) has no recourse or recovery.
  4. Due mutual consideration: All parties to the contract must receive something in return in this exchange; transactions cannot be one-sided (gifts are not contracts, by definition, but otherwise perfectly legal). In a crypto world, there may not be clarity about exactly what this due consideration is and if it was mutual.
  5. Moral and legal intent: A contract to kill someone or commit an immoral act is null and void. A payment for such an action is illegal and does not constitute a contract. Obviously, this may not be easy to detect in a crypto world.
  6. Enforceable: The performance of the terms of the contract must be enforceable and observable. None of this may be true in the crypto world, because in a decentralized system with no governance, no auditing, and indeed no identity, who could observe and who could enforce?

Smart contracts are incomprehensible

In general, people find regular contracts impenetrable, especially the fine print clauses. The article “Does Anyone Read the Fine Print? Consumer Attention to Standard Form Contracts” (by Yannis Bakos, Florencia Marotta-Wurgler, and David R. Trossen) generally concludes, unsurprisingly, that very few people do so.

In those rare cases when people read contracts, they may not actually understand them fully. Contrary to popular feeling, legal contracts are not obtuse by deliberate intention. If anything, they are as incredibly precise (or at least, strive to be) as possible without the use of mathematics. Despite the attempt at precision, there is still room for miscommunication and misunderstanding, whether that is due to the inexperience of the legal counsel (rare), the inexperience of the participants (very often), or the lack of clarity of the underlying regulation (probably rather common). When the application of the law is unclear in complicated cases, the courts resort to case law. All this points to the difficulty of understanding legal contracts. If that is not persuasive enough, consider that just about in all lawsuits both parties have previously signed contracts that were drafted and reviewed by experienced lawyers on both sides, yet one of the participants had to resort to a lawsuit.

In the case of smart contracts, the primary representation of the so-called contract is not the legal document but the computer program. Even simple transactions, when implemented in code, are very difficult to understand. Computer programmers are notorious for being poor documenters (or for their writing skills in general). What is less well-known is that programmers are deeply reluctant to read other programmers’ code because code is generally impenetrable, even when that code has been written by the same programmer who is reviewing it after a lapse of time.

Lay participants of contracts, such as investors and issuers, are asked to read the code in order to infer the underlying legal provisions! This is several steps removed from the requirement to read the actual legal document itself. Every step in the process has enormous potential for misrepresentation, misinterpretation, information loss, and outright incomprehensibility.

Indeed, the research data shows that many ICOs have “backdoor centralization”, but in the most negative sense of the term (unlike responsibly governed centralization), including pump-and-dump, insider trading, no expression in code of promises made on the website or whitepaper, unauthorized and unadvertised rights of modifiability, and so on. See “New Research Finds Backdoor ‘Centralized Control’ In Many ICOs” for a good summary.

You may think that the situation with smart contracts cannot be direr. But wait, it gets worse! In a 104-page study, “Coin-Operated Capitalism,” by the University of Pennsylvania Law School, “If ICO investors  were scrutinizing smart contract code before buying into an ICO, we would expect to see (all else [being] equal) higher capital raises by teams that faithfully coded supply and vesting protections, and also disclosed their modification powers. We find no evidence of that effect in our sample.”

What this means is that ICO investors are either the dumb money (generally, the uninformed retail investors), highly speculative and risk-tolerant (hopefully in amounts small enough not to matter, or those with intense fear-of-missing-out), or outright criminal in nature with deeper motives. Obviously, this is a general conclusion and does not implicate the legitimate investors who may have invested in ICOs for diversification (though the use of the word ‘invest’ or ‘diversification’ in connection with ICOs is highly suspect).

As far as ICOs go, none of this should paint all ICOs with the same broad brush. But it does call into question the underlying architectural philosophy of smart contracts in general. Smart contracts should be designed by lawyers because smart contracts are primarily contracts. Only when contracts are truly legal contracts can technologists then strive to make them more or less automated and intelligent. All this automation should be wrapped into governance, risk, audit, and manual review functions precisely because even the smartest contracts cannot anticipate all scenarios in the real world.

Now, that’s smart!

Forking – the New ‘F’ Word in Blockchain

Posted on by Kiran Garimella

Forking seems to be an integral part of the Blockchain architecture. This is due to Blockchain’s decentralized nature and the need to establish systemic trust among multiple participants (who are generally unknown to each other and therefore untrustworthy by definition).

To most of the non-technical population and a fair amount of the technical population as well, the forking phenomenon can be baffling and sound like a soap opera. The reasons for forking range from upgrades to the blockchain (for implementing some technical features such as expanded block size), migration of signatures to extended blocks (the SegWit fork on bitcoin), and disagreements on how to handle errors or losses.

To the extent that a chain relies on decentralization, operational forking is inevitable, since all transactions need to be validated and accepted by everybody or by a quorum. The volume of transactions can become huge. The way miners select transactions from the pool to validate and create blocks results in non-determinism. Different validators end up working on different blocks, causing little sub-chains to sprout like weeds in a garden. Eventually, one of the blocks wins out and its branch becomes the official continuation of the chain.

What happens to the other sub-chains? They wither and die. This is an integral part of the technology and perfectly proper, since it is a result of the inherent non-determinism in the generation of transactions and in the selection of transactions to validate. Remember, there is no central authority that coordinates all this, hence the need for a process of continual discovery of the most valid block and the most valid corresponding branch of the chain.

Unfortunately, regardless of the technical necessities, all this sounds like the result of squabbles in the blockchain community. The major forks in the Bitcoin and Ethereum communities, such as Bitcoin Cash and Ethereum Classic, are indeed serious disagreements with proposed changes. Besides the ever-present threat of malicious intent, these disagreements occur between well-meaning participants. In traditional centralized systems (whether software or not), these disagreements also exist, but they get resolved one way or the other before deploying the solution to the users. In some dispersed systems, such as professional associations, the protocol for change management is well-established. However, disputes occur in public blockchains while the chain is “in production” and participants can steer the chain to express their preference. It’s a bit like giving uncooperative front-seat passengers their own steering wheels.

Decentralized systems are double-edged swords, or should we say, spiny hedgehogs? Decentralization brings freedom from central authority. Whether this is viewed as good or bad depends on the issue at hand. But the one thing decentralization guarantees is a lot of debate, some chaos, sometimes no resolution, and (hopefully less often) a break-away of a splinter group in the form of a forked chain.

Decentralization is not necessarily good for everything, every time, and everybody. When pushed to the mat, most people would rather give up privacy for security and safety. Similarly, I suspect most would choose control and certainty over change, chaos, and confusion. As they say in the Six Sigma community, variance is worse than a bad mean. The possibility of forking in blockchains introduces an element of uncertainty that is less in users’ control or understanding than the uncertainty of change driven by a centralized governing body.

Blockchain is not one tool. The right flavor of blockchain must be applied correctly to the appropriate problem. Just as you can’t eat soup with a fork, you can’t deal with the soup of regulated securities with a forked chain, or more accurately, with a spoon that you don’t own or control, and which can splinter into a fork at any time.

A Big Lesson from the Delaware Blockchain Amendments

Posted on by Kiran Garimella

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 the mainstream security token platforms.

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. In making this provision, what the Delaware Bill meant was that all of the stock ledger data should be maintained on the chain, rather than only a portion of the data.

The more accurate interpretation of the provision bumps up against one limitation that public blockchains face. As the number of nodes in the chain grows dramatically—as it should in a truly decentralized system—the performance of the chain suffers. Validation, consensus, and finality take longer and longer. The problem becomes significant when security tokens are involved, since the data payload of securities transactions is much larger than the normal token payment data within Bitcoin and other payment-oriented cryptocurrencies and tokens. More importantly, contract execution is much 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 way around this problem is to put securities data off-chain and store the keys on-chain. This can provide some relief on storage but probably not as much impact on performance. Even with the limited payload, the Bitcoin blockchain has grown from around 1 MB in 2010 to more than 170 GB eight years later! Transactions speeds are even less impressive. Hardcore fans 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. Presumably, Bitcoin fans predict that Bitcoin’s transaction speed would match that of Visa if the Bitcoin network too had 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 violates the provisions 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….”

In contrast, the KoreChain maintains all information on the chain. Scalability and performance are not issues precisely because this is a permissioned chain with functional sharding (a topic for another blog) but no mining, proof-of-work, or proof-of-stake. The KoreToken protocol also addresses the full ecosystem of participants in securities transactions. The implementation of services is too important to leave it to interpretations and all the subsequent hassle of reconciling varied interpretations. For example, even the most basic partial sale of security tokens on a secondary market exchange requires a minimum of twenty-five separate sub-transactions involving upto five participants. In order to be robust, real-life implementations have many more steps. Currently, all these steps do take place, but the majority of them happen after the primary sale transaction occurs. These tasks fall into various groups of activities such as clearance, settlement, reporting, disclosure, and corporate record-keeping.

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 the 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.” KoreChain, engineered carefully to be fully compliant with all the complexities of securities regulation and corporate law, mitigates errors and creates efficient end-to-end securities transactions without ignoring the risks. The KoreChain implements all tasks that are mandated by securities regulation and corporate law.

A Security Token for Full Lifecycle Compliance

Posted on by Kiran Garimella

ICOs suffer from disapproval from not only the SEC but also several media that have banned ICO advertising. This disapproval seems justified, since many of the ICOs had no business plans, no product, no service, no credible team, and no roadmap for generating value. Of the remaining well-intentioned ones, the problem of passing regulatory scrutiny for a utility token is insurmountable since it is a utility in name while a security in intent and form. The only way out is to re-classify it correctly as a security token.

The Responsible Approach of the KoreToken Security Protocol

The ERC-20 protocol and the concept of smart contracts are steps in the right direction for many use cases and great for many applications. However, for the financial markets, we need a protocol that can meet all regulatory requirements. We have taken an approach that originates solidly from securities law. We recognize the paramount need for safety, security, and risk management. We know all parties in a securities transaction must be protected at all times – these are the investors, issuers, directors, officers, lawyers, broker-dealers, transfer agents, secondary exchanges, and secondary token holders. There must be complete traceability and auditability.

Blockchain, in creating an immutable record, guarantees validity and (perhaps eventual) finality. However, this validity is technical validity and finality is the committing of the block to the chain. In the securities world, validity and finality means a lot more. Technical validity is necessary but not sufficient. Validity should include contractual validity and legal validity. Similarly, finality is achieved only upon authorized approval of transactions. KoreChain, our implementation of blockchain using Hyperledger Fabric, addresses this broader and more comprehensive definition of validity and finality. The KoreToken protocol and specification includes modular methods to implement various aspects of business validity and finality.

A Comprehensive Specification and Implementation

The KoreToken’s specification and protocol address the requirements for data and methods for the complete lifecycle of a security token. KoreConX will itself use this specification and protocol to create its own security token as well create security tokens for its issuers. The protocol includes data and methods that fall into three broad categories: public interface layer, business layer, and governance layer. The methods themselves can be invoked by participants in various transactions.

The execution of security transactions, from issuance to corporate actions to exit, cannot happen in a vacuum. Registered entities are accountable for knowing where these securities are, who are their holders, and the state of their compliance. More than issuing a protocol, KoreConX has taken the unique approach of providing a full operational platform as well as partnerships with other participants in the ecosystem such as broker-dealers and secondary market operators. KoreConX itself is an SEC-registered transfer agent, meaning that we can offer full custodianship services for securities.

The KoreToken architecture is modular, allowing security token designers to compose entire securities transactions and implement various use cases. The heavy lifting of blockchain functionality as well as business-related functionality such as event management, transaction management and process management are handled by the KoreChain.

Please see the following Executive KoreBriefing on The KoreToken Specification and Protocol.

We will release the detailed technical whitepaper shortly.

 

Introducing the KoreChain

Posted on by Kiran Garimella

The KoreChain is the first blockchain on a serious industrial-strength infrastructure that is focused exclusively on the complex world of global financial securities. The KoreChain is a permissioned Hyperledger Fabric blockchain. This gives it the native advantage of Fabric, a blockchain platform that has been engineered from the ground up for handling enterprise-class applications. KoreChain is implemented on IBM’s hosting platform since it provides the highest level of security as define by the US National Institute for Standards and Technology.

In electing Hyperledger Fabric to be the foundational blockchain infrastructure for KoreChain rather than Ethereum, we made a clear commitment to good engineering, enterprise-class architecture, and implementation with well-established tools rather than new and untested programming environments.

Hyperledger Fabric Strengthens KoreChain

The following benefits of Fabric come to us practically out of the box:

  1. Membership and access-rights management: The securities world has many complicated rules about data privacy, KYC, AML, need-to-know, etc. Some of these vary by region or by exemption rules. In addition to regulatory constraints, the platform also has to accommodate privacy conditions of participants in various transactions. Fabric provides this flexibility through channels.
  1. High levels of performance and scalability: Securities transactions are more complicated than point-of-sale authentication and authorization. While all securities transactions don’t require response and completion within seconds (as, for example, in trading), the sheer volume of multiple transactions and subsidiary events in capital markets requires a robust infrastructure that can stand up to spikes and also support secondary trading.
  2. Security and safety: The combination of Hyperledger Fabric and the hosting infrastructure at IBM provide a protected environment that includes end-to-end cryptography and the highest level of security defined by the US National Institute of Standards and Technology (NIST), the level 4 of FIPS 140-2, that includes, for example, Hardware Security Modules.

KoreChain’s Specialized Capabilities

In addition to these, KoreChain provides a number of specialized capabilities such as several layers of artificial intelligence, event management, and transaction management for securities.

All this makes the KoreChain an industrial-strength engine for KoreContracts, which are true smart contracts for financial services. One special category of KoreContracts is the  KoreTokenContract, which is the fundamental template for KoreTokens. The KoreChain is carefully designed to ensure a safe and secure environment for security tokens and their management throughout their entire lifecycle, including provision for various corporate actions.

More on these exciting developments in subsequent blogs and articles!
Please see the following introductory Executive KoreBriefing on What is KoreChain?
We will release the detailed technical whitepaper shortly.

Join the all-in-one platform empowering private capital markets.

Free forever, KoreConX makes it easy for participants in private capital markets to manage their investment portfolios, raise capital, and meet global compliance standards along every step of the way.

Sign up, it's free! Book a call