The Problematic Role of Computer Code in Initial Coin Offerings

The Initial Coin Offering (ICO) is one of the stranger financial innovations in recent memory. Imagine if Coca-Cola had funded its initial deployment of vending machines through the sale of tokens its machines might one day require. Now replace soda and physical tokens with software-based services and digital (“crypto”) assets. This scenario roughly captures the ICO. If you believe what you read on social media, you might get the impression the ICO form is revolutionary—a “1000x improvement over the status quo,” as one observer put it. But if you trust the Wall Street Journal, you might think the ICO market is “fevered,” and that many offerings bear the “hallmarks of fraud.” Either way, it is clear that the ICO raises pressing questions for scholars, practicing lawyers, and regulators alike.

Our article, Coin-Operated Capitalism, aims to shed light on the legal significance of the innovations at the heart of the ICO, and to examine how it is being used in the current market. We do so by looking at the guts of ICOs: contracts, marketing materials, and—crucially—computer code. We begin by surveying the 50 ICOs that raised the most capital in 2017 and then compare the promises ICO promoters make in their offering documents with the actual function of the crypto-assets they deliver. To make this comparison, we examine the smart contracts—automated, if-this-then-that rules coders design to govern crypto-assets—associated with each ICO, along with the distributed ledger systems through which those smart contracts operate.

Our first contribution is to describe the role of smart contracts within the ICO form in more detail than prior legal literature has done. While akin to venture capital contracting, asset securitization, and (obviously) the Initial Public Offering (IPO), the ICO is not just another way to slice and dice debt, equity, and governance rights via contract and legal entity design. Instead, the presence of a crypto-asset at the heart of the offering enables entrepreneurs to deliver investor protections through computer code rather than legal language. This technological capacity is central to the ideological and practical case that entrepreneurs make for ICOs. They speak of automated, “[d]ynamic [c]eiling[s]” for crypto-asset supply; of placing founders’ crypto-asset allocations in “time-locked smart contracts” to align incentives for productivity; and of “trusted parties replaced with verifiable computation.” Our look at examples of smart-contract design demonstrates that code has the potential to be a substitute and complement for legalistic governance mechanisms in financial contracting.

But “potential” has not become reality. Our second contribution is to show just how far code falls short of expectations for the top 50 ICOs of 2017. We do so through a comparative audit of smart-contract code and paper statements about three offering characteristics. Our audit establishes that:

  • 89 percent of our audit sample[1] made public disclosures about limits to crypto-asset supply. Of those, 24 percent (10 of 41) failed to code limits into their smart contracts.
  • 80 percent of our audit sample made public disclosures about locking up ICO allocations to insiders through a “vesting” or “time-lock” mechanism. Of those, fully 78 percent (29 of 37) did not put the mechanism into effect through smart-contract code.
  • 21 percent of our audit sample retained the ability to modify their smart contracts’ governing structures through a centralized control mechanism built into code. Of these, 60 percent (6 of 10) did not disclose that power to the public.

These results are startling. They demonstrate that ICO code often fails to deliver key investor protections, and sometimes provides founders with significant, undisclosed authority to alter investor rights. While ICOs are promoted by an industrial community that espouses techno-libertarian beliefs in the power of “trustless trust” and carefully designed code, actual ICO practices do not uphold that ideology.

If the code does not protect investors from exploitation, what will? Seeing our results, some advocates of ICOs have suggested that code-disclosure mismatch is not a serious problem. After all, old-fashioned laws—like state unfair, deceptive, and abusive acts and practices rules and the Securities Act of 1933—will ensure that investors are protected. This is a remarkable retreat from the technologically-grounded justifications for ICOs. It is also overly optimistic about current law’s ability to police the new form.

If the ICO form isn’t delivering code-based advantages to parties to the transactions, what justifies its use? One likely answer is regulatory arbitrage. ICOs, like many internet-based phenomena, test the limits of regulation. Issuers can set up shop in a low-regulation jurisdiction and exploit the inherent anonymity of the crypto-asset market. And even for transparent issuances that comply with U.S. law, investor protections are unproven. While a number of class-action suits, largely premised on state law violations, have targeted prominent ICOs, their resolution remains unclear. The deterrent threat of legal penalties is not nearly as strong as in typical markets—and, of course, far weaker than the automated enforcement of code.

How should regulators, legislators, and scholars think about these problems? It depends on who is investing in ICOs, and why. If ICO buyers are self-aware weekend gamblers or shady criminal syndicates, the case for investor protection is weaker than if they are unsophisticated people who have been snared by carefully calibrated social-media ad campaigns. Scholars should, therefore, develop a deeper understanding of the “buy side” of the ICO market. But regardless of who’s buying, our results show that computer code is not doing the job of investor protection.


[1] We report the results of an audit of every smart contract that was in a human-readable programming language called Solidity. Three smart contracts in our sample contained large portions of “byte code,” which is only human-readable after a herculean reverse-engineering effort—an effort we did not undertake.

This post comes to us from Shaanan Cohney, a PhD candidate in computer and information science at the University of Pennsylvania; David A. Hoffman, a professor at the University of Pennsylvania Law School; Jeremy Sklaroff, a graduate of the University of Pennsylvania Law School and the Wharton School; and David A. Wishnick, an academic fellow at the University of Pennsylvania Law School Center for Technology, Innovation & Competition. The post is based on their recent article, “Coin-Operated Capitalism,” available here.