Benefits of Digital Securities for Investors and Issuers

With the emergence and development of blockchain technology, digital securities have seen wider adoption by investors and investment firms. Arising from the need for protection against fraud and as a way for investors to ensure asset ownership, digital securities are a digital representation of traditional securities and follow the same regulatory rules. Since their first appearance, digital securities now include any debt, equity, or asset that is registered and transferred electronically using blockchain technology. 

Digital securities are made possible by blockchain, also known as “distributed ledger technology”. Distributed ledger technology is a database where transactions are continually appended and verified by multiple participants, ensuring that each transaction has a “witness” to validate its legitimacy. By the nature of the system, it is more difficult for hackers to manipulate, as copies of the ledger are decentralized or located across multiple different locations. Changes to one copy would be impossible, as the others would recognize it as invalid.

Distributed ledger technology allows digital securities to be incredibly secure. Ownership is easily recorded and verified through the distributed ledger, a huge benefit over traditional securities. Any transfer of digital securities is also recorded and with each copy of the transaction stored separately, multiple witnesses of the transaction exist to corroborate it. 

Traditional or digital

With traditional securities, investors can lose their certificate of ownership or companies can delete key files detailing who their investors are. Without a certificate, proving how many shares an investor owns would be incredibly challenging. In contrast, digital security ownership is immutable. Investors are protected and always able to prove their ownership since the record cannot be deleted or altered. Additionally, investors can view all information related to the shares they’ve purchased, such as their voting rights and their ability to share and manage their portfolios with both accuracy and confidence. 

Since the record is unchangeable, it also serves as a risk management mechanism for companies, as the risk of a faulty or fraudulent transaction occurring is removed. Digital securities are also greatly beneficial to the company when preparing for any capital activity since the company’s records are transparent and readily available. With traditional securities, the company would typically hire an advisor to review all company documents. If the company has issued digital securities, this cost is eliminated, as it is already in an immutable form.  

Smart contracts made possible

The use of digital securities also makes smart contracts possible, which have preprogrammed protocols for the exchange of this kind of securities. Without the time-consuming paper process, companies can utilize digital securities to raise funds from a larger pool of investors, such as the case with crowdfunding. Rather than keeping manual records of each transaction, the smart contract automatically tracks and calculates funds and distributes securities to investors. 

Companies looking to provide their investors with the ability to trade digital securities must be aware that they are required to follow the same rules set by the SEC for the sale and exchange of traditional securities, such as registering the offering with the SEC. This ensures that potential investors are provided with information compliant with securities regulation worldwide. According to the SEC, investors must receive ongoing disclosures from the issuer so they can make informed decisions regarding ownership of their securities. Companies that are not compliant with the SEC can face severe penalties and may be required to reimburse investors who purchased the unregistered offerings. 

Besides the companies offering securities, broker-dealers must also register with the Financial Industry Regulatory Authority (FINRA). Similarly, platforms on which digital securities can be traded must register as an Alternative Trading System operator with the SEC. Both broker-dealers and ATS operators can face severe penalties if not properly registered. 

Secondary market (ATS) also benefits

Possibly the greatest benefit of digital securities is that it allows for smoother secondary market transactions. With records of ownership clear and unchangeable, an investor can easily bring their shares to a secondary market. Transactions are more efficient and parties have easy access to all necessary information regarding the securities being traded, removing the friction in traditional securities. 

At KoreConX, the KoreChain platform is a fully permissioned blockchain, allowing for companies to issue fully compliant digital securities. Records are updated in real-time as transactions occur, eliminating errors that would occur when transferring information from another source. The platform securely manages transactions, providing investors with support and portfolio management capabilities. Additionally, the KoreChain is not tied to cryptocurrencies, so it is a less attractive target for potential crypto thieves. KoreChain allows companies to manage their offerings and company data with the highest level of accuracy and transparency.

Since digital securities face the same regulatory rules as traditional ones, investors are protected by the SEC against fraudulent offerings. This, together with the security and transparency that blockchain allows, creates a form of investment that is better for investors and issuers alike. Since the process is simplified and errors are decreased without redundant paperwork, issuers have the potential to raise capital more efficiently. They will also be better prepared for future capital activity. For investors, a more secure form of security protects them from potential fraud and losses on their investments. With digital securities still in their infancy, it will be exciting to see how this method of investment changes the industry. 

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

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

The Three Fallacies of Smart Contracts

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!