Making Sense of Cryptoeconomics

28 August 2017 |

Note to reader: this piece was also published on Coindesk and Medium.

A few months ago Parker Thompson, a well known Silicon Valley VC, tweeted that "the concept of crypto-economics is stupid. It's economics. Inventing your own word is just an excuse to ignore well-understood concepts."

The term "cryptoeconomics" causes a lot of confusion. People are often unclear on what it is supposed to mean. The word itself can be misleading, as it suggests that there is a parallel "crypto" version of the whole of economics. This is wrong, and Parker is right to mock such a generalization.

In simple terms, cryptoeconomics is the use of incentives and cryptography to design new kinds of systems, applications, and networks. Cryptoeconomics is specifically about building things, and has most in common with mechanism design – an area of mathematics and economic theory.

Cryptoeconomics is not a subfield of economics, but rather an area of applied cryptography that takes economic incentives and economic theory into account. Bitcoin, ethereum, zcash and all other public blockchains are products of cryptoeconomics.

Cryptoeconomics is what makes blockchains interesting, what makes them different from other technologies. As a result of Satoshi's white paper, we have learned that through the clever combination of cryptography, networking theory, computer science and economic incentives we can build new kinds of technologies. These new cryptoeconomic systems can accomplish things that these disciplines could not achieve on their own. Blockchains are just one product of this new practical science.

This article aims to explain cryptoeconomics in clear, simple terms. First, we examine bitcoin as an example of cryptoeconomic design. Second, we consider how cryptoeconomics relates to economic theory in general. Third, we look at three different areas of cryptoeconomic design and research that are active today.

1. What is cryptoeconomics? Bitcoin as a case study

Bitcoin is a product of cryptoeconomics.

Bitcoin's innovation is that it allows many entities who do not know one another to reliably reach consensus about the state of the bitcoin blockchain. This is achieved using a combination of economic incentives and basic cryptographic tools.

Bitcoin's design relies on economic incentives and penalties. Economic rewards are used to enlist miners to support the network. Miners contribute their hardware and electricity because if they produce new blocks, they are rewarded with amounts of bitcoin.

Second, economic costs or penalties are part of bitcoin’s security model. The most obvious way to attack the bitcoin blockchain would be to gain control of a majority of the network's hashing power – a so-called 51 percent attack – which would let an attacker reliably censor transactions and even change the past state of the blockchain.

But gaining control of hashing power costs money, in the form of hardware and electricity. Bitcoin’s protocol intentionally makes mining difficult, meaning that gaining control of a majority of the network is extremely expensive – enough that it would be hard to profit from the attack. As of August 16, 2017, the cost of a 51 percent attack on bitcoin would be around $1.88 billion in hardware and $3.4 million in electricity every day.

Without these carefully calibrated economic incentives, bitcoin wouldn’t work. If mining did not come with a high cost, it would be easy to launch a 51 percent attack. If there were no mining reward, there would be no industry of people who buy hardware and pay for electricity to contribute to the network.

Bitcoin also relies on cryptographic protocols. Public-private key cryptography is used to give individuals safe, exclusive control of their bitcoin. Hash functions are used to "link" each block in the bitcoin blockchain, proving an order of events and the integrity of past data.

Cryptographic protocols like these give us the basic tools necessary to build reliable, secure systems like Bitcoin. Without something like public-private key infrastructure, we could not guarantee to a user that they have exclusive control over their bitcoin. Without something like hashing functions, nodes would not be able to guarantee the integrity of the history of bitcoin transactions contained in Bitcoin’s blockchain.

Without the hardness of cryptographic protocols like hashing functions or public-private key cryptography, we would have no secure unit of account with which to reward miners - no confidence that our record of past accounts was authentic and exclusively controlled by a rightful owner. Without a carefully calibrated set of incentives to reward an industry of miners, that unit of account could have no market value because there would be no confidence that the system could persist into the future.

In this way, bitcoin's design requires an understanding of both cryptography and how incentives affect the security properties and functionality of systems built with cryptography. Cryptoeconomics is strange and counterintuitive. Most of us are not used to thinking of money as a design or engineering problem, nor are we used to economic incentive design being an essential component of a new technology. Cryptoeconomics requires us to think about information security problems in economic terms.

One of the most common mistakes in this industry is made by those who view blockchains only through a lens of computer science or applied cryptography. We have a strong tendency to prioritize the things we are most comfortable with, and see things outside of our domain of expertise as less important.

In blockchain technology, this leads many people to assume or abstract away the crucial role of economic incentives. This is one reason we see meaningless phrases like "blockchains are trustless," "bitcoin is backed only by math" or "blockchains are immutable."These are all wrong in their own way, but all have the effect of obfuscating the essential role of a large network of people whose necessary participation in the network is maintained through economic incentives.

Cryptoeconomic systems like bitcoin feel like magic to someone who views them only as a product of computer science, because bitcoin can do things that computer-science alone could never accomplish. Cryptoeconomics isn’t magic – it’s just interdisciplinary.

2. How does it relate to economics more generally?

The term cryptoeconomics can be misleading because it suggests a comparison to economics as a whole. This is part of what leads people like Parker to dismiss the term. Economics is the study of choice: how people and groups of people respond to incentives. The invention of cryptocurrency and blockchain technology does not require a new theory of human choice – the humans haven’t changed. Cryptoeconomics is not the application of macroeconomic and microeconomic theory to cryptocurrency or token markets.

Cryptoeconomics has most in common with mechanism design, a field related to game theory. In game theory, we look at a given strategic interaction (a "game") and then try to understand the best strategies for each player, and the likely outcome if both players follow those strategies. For instance, we might use game theory to look at a negotiation between two firms, relations between countries or even evolutionary biology.

Mechanism design is often referred to as reverse game theory because we start with a desired outcome and then work backwards to design a game that, if players pursue their own self interest, will produce the outcome we want. For instance, imagine we are responsible for designing the rules of an auction. We have an objective that we want bidders to actually bid the real value they place on an item. To achieve this, we apply economic theory to design the auction as a game where the dominant strategy for any player is to always bid their true value. One solution to this problem is called a Vickrey auction, where bids are secret and the winner of the auction (defined as the player with the highest bid) only pays the second highest amount that was bid.

Cryptoeconomics, like mechanism design, focuses on designing and creating systems. Like in our auction example, we use economic theory to design "rules" or mechanisms that produce a certain equilibrium outcome. But in cryptoeconomics, the mechanisms used to create economic incentives are built using cryptography and software and the systems we are designing are almost always distributed or decentralized.

Bitcoin is a product of this approach. Satoshi wanted bitcoin to have certain properties – for instance, that it be able to reach consensus about its internal state and that it be censorship-resistant. Then, Satoshi set out to design a system that would achieve those properties, assuming people responded in rational ways to economic incentives.

Most often, cryptoeconomics is used to provide a security guarantee about a distributed system. For instance, we have a cryptoeconomic security guarantee that the bitcoin blockchain is secure against a 51 percent attack unless someone is willing to spend a few billion dollars. Or, in a state channel – a topic we discuss later – we can have a cryptoeconomic security guarantee that an off-chain process is nearly as secure and final as an on-chain transaction.

It is worth noting that mechanism design is not a panacea. There is a limit to how much we can rely on incentives to predictably shape future behaviour. As Nick Szabo rightly points out, ultimately we are speculating about people's future mental states and making assumptions about how they react to certain incentives. A cryptoeconomic system's security guarantee depends in part on the strength of its assumptions about how people react to economic incentives.

3. Three examples of cryptoeconomics

There are at least three different kinds of systems being designed today that could be called “cryptoeconomic”.

Example 1: Consensus protocols

Blockchains are able to reach reliable consensus without having to rely on a central trusted party – a product of cryptoeconomic design. Bitcoin's solution, which we surveyed above, is called "proof-of-work" consensus because miners must commit work – in the form of hardware and electricity – in order to be participate in the network and receive mining rewards.

Improving proof-of-work systems and designing alternatives to them is one active area of cryptoeconomic research and design. Ethereum’s current proof-of-work consensus mechanism includes many variations and improvements on the original design, enabling faster block times and being more resistant to the mining centralization that can result from ASICs.

In the near future, ethereum plans to migrate to a "proof-of-stake" consensus protocol called Casper. This is an alternative to proof-of-work that does not require "mining" in the usual sense: there is no need for specialized mining hardware or huge expenditures of electricity.

Remember that the whole point of requiring miners to buy hardware and spend electricity is to impose a cost on miners, as a way of raising the cumulative cost of attempting a 51 percent attack sufficiently high that it becomes too expensive. The idea behind proof-of-stake systems is to use deposits of cryptocurrency to create the same disincentive, rather than real-world investments like hardware and electricity.

In order to mine in a proof-of-stake system, you must commit a certain amount of ether into a smart contract "bond." Just like in proof-of-work, this raises the cost of a 51 percent attack – an attacker would have to commit a very large amount of ether to successfully attack the network, which they would then lose forever.

Casper is being designed by Vlad Zamfir, Vitalik Buterin, and others at the Ethereum Foundation. You can read more about the history of Casper's design in this series of posts by Zamfir or hear him talk about it on a recent podcast. Buterin wrote a long post about Casper's design philosophy here, and there is a useful FAQ on the ethereum GitHub wiki here.

Example 2: Cryptoeconomic application design

Once we have solved the fundamental problem of blockchain consensus, we are able to build applications that sit "on top" of a blockchain like ethereum. The underlying blockchain gives us (1) a unit of value that can be used to create incentives and penalties, and (2) a toolkit with which we can design conditional logic in the form of "smart contract code." The applications we build with these tools can also be a product of cryptoeconomic design.

For instance, the prediction market Augur requires cryptoeconomic mechanisms in order to function. Using its native token REP, Augur creates a system of incentives that rewards users for reporting the "truth" to the application, which is then used to settle bets in the prediction market. This is the innovation that makes a decentralized prediction market possible. Another prediction market, Gnosis, uses a similar method, though also lets users specify other mechanisms for determining true outcomes (commonly called "oracles").

Cryptoeconomics is also applied to design token sales or ICOs. Gnosis, for instance, used a "Dutch auction" as a model for its token auction, on the theory that this would result in a more fair distribution (an experiment that had mixed results). We mentioned earlier that one area where mechanism design has been applied is in the design of auctions, and token sales gives us a new opportunity to apply some of that theory.

These are a different kind of problem than building the underlying consensus protocols, but they share enough similarities that both can be fairly seen as cryptoeconomic. Building these applications requires an understanding of how incentives shape users' behaviour and careful design of economic mechanisms that can reliably produce a certain result. They also require an understanding of the capabilities and limitations of the underlying blockchain on which the application is built.

Many blockchain applications are not products of cryptoeconomics; for instance, applications like Status and Metamask – wallets or platforms that let users interact with the ethereum blockchain. These do not involve any additional cryptoeconomic mechanisms beyond those that are already part of the underlying blockchain.

Example 3: State channels

Cryptoeconomics also includes the practice of designing much smaller sets of interactions between individuals. The most notable of these are state channels. State channels are not an application but a valuable technique that can be used by most blockchain applications to become more efficient.

A fundamental limitation of blockchain applications is that blockchains are expensive. Sending transactions requires fees, and using ethereum to run smart-contract code is comparatively costly to other kinds of computation. The idea behind state channels is that we can make blockchains more efficient by moving many processes off-chain, while still retaining a blockchain's characteristic trustworthiness, through the use of cryptoeconomic design.

Imagine Alice and Bob want to exchange a large number of small payments of cryptocurrency. The normal way for them to do this would be to send transactions to the blockchain. This is inefficient – it requires paying transaction fees and waiting for the confirmation of new blocks.

Instead, imagine that Alice and Bob sign transactions that could be submitted to the blockchain, but are not. They pass these back and forth between one another, as fast as they want – there are no fees at this point, because nothing is actually hitting the blockchain yet. Each update "trumps" the last one, updating the balance between the parties.

When Alice and Bob have finished exchanging small payments, they "close out" the channel by submitting the final state (i.e. the most recent signed transaction) to the blockchain, paying only a single transaction fee for an unlimited number of transactions between themselves. They can trust this process because both Alice and Bob know that each update passed between them could be sent to the blockchain. If the channel is properly designed, there is no way to cheat – say, by trying to submit a previous update as though it were the most recent – since recourse to the blockchain is always available.

For illustrative purposes, you can think of this as similar to how we interact with other trusted sources, like a legal system. When two parties sign a contract, most of the time they never need to take that contract to court and ask a judge to interpret and enforce it. If the contract is properly designed, both parties simply do what they promised to do, and never interact with the courts at all. The fact that either party could go to the court and have the contract enforced is enough to make the contract useful.

This technique is not just useful for payments, but for any update to the state of an ethereum program – hence the more general term "state channel" rather than the narrow "payment channel." Instead of sending payments back and forth, we can send updates to a smart contract back and forth. We can even send entire ethereum smart contracts that, if needed, will be sent to the blockchain and executed. These programs never have to be executed to be useful. All that is needed is a sufficiently high guarantee that they could be executed if necessary.

In the future, most blockchain applications will use state channels in some form. It is almost always a strict improvement to require less on-chain operation, and many things done on-chain today can be moved into state channels while still preserving a sufficiently high guarantee to be useful.

The description above skips over many important details and nuances of how state channels work. For a more detailed description, Ledger Labs built a toy implementation last summer that demonstrates the basic concept.


Thinking about the blockchain space through the lens of cryptoeconomics is helpful. Once you understand the idea, it helps to clarify many of the controversies and debates in our industry.

For instance, "permissioned" blockchains that are centrally managed and do not use proof-of-work have been a source of constant controversy since they were first proposed. This area of work is often referred to as "distributed ledger technology" and is focused on financial and enterprise use cases. Many partisans of blockchain technology dislike them – they may be blockchains in the literal sense, but there is something about them that feels wrong. They seem to reject the thing that many people see as the whole point of blockchain technology: being able to produce consensus without relying on a central party or traditional financial systems.

A cleaner way to make this distinction is between blockchains that are products of cryptoeconomics and blockchains that are not. Blockchains that are simply distributed ledgers and do not rely on cryptoeconomic design to produce consensus or align incentives might be useful for some applications. But they are distinct from blockchains whose whole purpose is to use cryptography and economic incentives to produce consensus that could not exist before, like bitcoin and ethereum. These are two different technologies, and the clearest way of distinguishing between them is whether or not they are products of cryptoeconomics.

Secondly, we should expect that there will be cryptoeconomic consensus protocols that do not rely on a literal chain of blocks. Obviously, such a technology would have something in common with blockchain technology as we call it today, but labelling them blockchains would be inaccurate. Again, the relevant organizing concept is whether such a protocol is the product of cryptoeconomics, not whether it is a blockchain.

The ICO craze has also focused attention on this distinction, though few have articulated it clearly.
Many people independently identified that one of the strongest signs of a token's value is whether it forms a necessary component of the application to which it is connected. To put this in clearer terms, the question should be: is the token part of a necessary cryptoeconomic mechanism in the application? Understanding the mechanism design of a project holding an ICO is an essential tool in determining that token's utility and likely value.

In the past years, we've moved from thinking about this new field solely through the lens of one application (bitcoin), to thinking about it in terms of one underlying technology (blockchains). What needs to happen now is to step back once again and view this industry in terms of a unifying approach to solving problems: cryptoeconomics.

Thanks to Jeff Coleman, Ethan Wilding, and Vlad Zamfir for their comments on an earlier draft of this article.

Paper: Applications of Distributed Ledger Technology to Regulatory and Compliance Processes

21 August 2017 |


Earlier this year R3 commissioned me to write a research paper on how blockchains/DLT could be used in applications related to regulatory reporting and compliance. The paper is now publicly available here (though you need to enter an email address to download).

The basic idea presented in the paper is that blockchains/DLT could be used by financial institutions to improve the way they comply with certain regulatory requirements. The example we look at in depth in the paper is the requirement for financial institutions to report certain types of transactions. For instance, if a bank trades a derivative, there may be a requirement to report the details of that trade in real-time to a regulator. Blockchains/DLT could improve this process by (in a sense) giving the regulator "shared access" to the actual transaction itself, rather than rely on a process of copying information and sending it through a separate process. The final third of the paper is an exploration of how we might accomplish this for over-the-counter interest rate swaps (a type of derivative) in Corda, R3's DLT product for financial services.

Thanks to Kevin Rutter, Neepa Patel, Tim Swanson, and the whole team at R3 who were a pleasure to work with.

The Space of Possible Economic Relationships

28 June 2017 |

A concept I often use to explain the potential of blockchain technology is “the space of possible economic relationships”.

What do I mean by economic relationships? I mean any situation where two or more persons enter into a relationship concerned with value:

  • A transfer of cash
  • An informal agreement to borrow money from a friend
  • A legal contract to buy a house
  • The relationship between all the shareholders of a corporation
  • The relationship between all persons who use US dollars

This is meant to be very broad, including informal agreements, legal contracts, and very diffuse relationships that we don’t often think about, like sharing a national currency.

Now, let’s imagine a space that contains all possible economic relationships, and put some points on a graph.

This space includes not just all economic relationships that we’re familiar with or which are even used, but every possible economic relationship that could exist.

In reality, only some of this graph is available to us. Let’s draw a line to indicate which economic relationships are actually possible today.

Every economic relationship currently used by human beings (not just the ones we have highlighted as examples) is in this section. Every kind of purchase, corporate structure, debt instrument, store of value, and medium of exchange is somewhere inside that shape.

This shape used to look different, and was once much smaller. Until we invented money, we might have only had access to a very small area near the bottom right. Currency zones only became possible with stable political systems. Binding contracts required the slow evolution of complex legal systems. Public companies with shareholders required centuries of common law and commercial experience, and creating new specializations in professions like finance and law. All of these required technology, too: metalworking for money, writing for law, and even information technology for modern stock exchanges (ever heard of the paper crisis?).

We only have access to these economic relationships because these are the only ones for which we’ve built out the necessary institutions and technology. There are probably many other kinds of economic relationships out there, in the blank space, that we haven’t been able to access.

Recently, the invention of blockchain technology has expanded the frontier of this space. Now it probably looks a lot weirder - maybe something like this:

Blockchains let us do things that weren’t possible before:

Types of economic relationships that used to have big, expensive barriers to entry are suddenly a lot easier, and we’ve only really just begun experimenting with the technology.

Blockchains have expanded the space of possible economic relationships. But it’s been so sudden, we’re not really sure what to do with them yet. Usually these new capabilities develop slowly, because they require legal and political systems that are naturally gradual and expensive to change.

But blockchains let us do some things without those institutions, which means new capabilities become available much faster than usual. The limiting factor isn't going to be whether we have the capability to do these things, but our ability to recognize that the space of possible economic relationships has expanded, and identify new useful things to build in those spaces.


The general idea I’ve expressed above has been written about by many people before me - this is just a useful conceptual aide I like to use to get the point across. If you found this interesting, you might also like:

  • This recent twitter-thread by Nick Szabo, on how “smart contracts” enable more, newer kinds of commercial deals
  • This blog post by Nick Szabo - “Money, blockchains, and social scalability”
  • This blog post by Christian Catalini - “How blockchain technology will impact the digital economy”
  • Lex Cryptographia, by Primavera De Filippi and Aaron Wright

A Response to Chris DeRose' Article on ICOs & Token Sales

19 June 2017 |

A few weeks ago Chris DeRose published an article titled "Dear SEC: ICO's & 'Tokens' are killing innovation". The article was widely shared and praised in the bitcoin community, and much maligned by others (particularly from within the ethereum community). A journalist on twitter, who had shared the link and received criticism for casting Chris in a positive light, mentioned that he would be interested in reading a non-ad hominem response to the piece. Said journalist has since deleted the tweet asking this (or at least I couldn't find it), so I don't mention his name here.

I ended up writing a brief email to this person, and thought I would turn it into a blog post here, lightly edited.


First, I agree in principle with some of Chris' concerns. Some ICOs are scams or get-rich-quick schemes, designed to take advantage of a hot market and some investors' lack of technical sophistication. Some tokens are very likely to be securities, and anyone working in this space should be cautious and work closely with legal counsel. Improving this market - by building tools and services to help investors make better decisions and identify scams before they get started, and perhaps even some form of regulation to deal with the worst abuses - is something I support.

That said, I do not think that every current ICO is a scam. I think that in the long term this is a powerful new capability for an open-source financial network that will eventually mature into a safe, useful form of fundraising.

The primary flaw with Chris' argument is that it does not recognize the distinction between a technology and the uses of that technology. The whole piece is guilty of cherrypicking examples of particularly bad ICOs, and then asserting that definitionally, all ICOs must be just as bad, without actually making that argument for specific projects. This would be like asserting that because one bank was used to launder drug money, all banks are necessarily fraudulent. Or like arguing that because some people use bitcoin to buy drugs and weapons, there is no legitimate use for a censorship resistant global currency. These are poor arguments.

With that in mind, here are some specific responses to sections of the piece that I thought were particularly wrong or poorly argued:

The word ICO is merely a synonym for an ‘unlicensed security’. ICOs are released to investors under a pretense of venture equity, but with the specific purpose of circumventing SEC authority and control.

The label ICO is an unwise one, as it directly compares tokens to equity. However, declaring that an ICO is always an unlicensed securities offering is... un-credible. Any lawyer telling you that it's settled law that tokens are securities would be lying. Even very well-informed lawyers who take the opinion that tokens are very likely securities would not make this claim, because it is not true. Chris is not a lawyer, and does not provide any argument to support this claim. He likewise provides no evidence that the only purpose of issuing tokens is to circumvent the SEC. This is obviously not true for ICOs based outside the US and which prevent US participants from purchasing, to give one example.

Retail Investors are left holding these worthless securities in lieu of real world assets, unable to comprehend what risk they’ve agreed to

I haven't seen much evidence that retail investors make up any significant portion of the people buying into ICOs. Chris has not provided any evidence that this is true. My best informed-guess is that BTC and ETH-rich persons, who have recently made a lot of money, are trying to diversify their investment. We know, for instance, that many recent ICOs have been dominated by a small number of whales who have invested very large sums. Recent ICOs have been so competitive that only people running their own node infrastructure or manually setting high transaction fees are able to reliably participate. This suggests to me that retail or "blue collar" investors make up a very small portion of the total investment.

I agree that this is a real concern in the medium and long run - eventually retail investors will be participating in ICOs, and we should be concerned about whether they are being taken advantage of.

It is unclear why ‘blockchain’ is needed for any of these projects, other than as a mere label, in which to dodge regulatory enforcement.

Not sure where to start with this one. Chris starts from the perspective that every use of blockchain technology other than bitcoin is a scam, fraudulent, fake. This is a position he's held for a very long time. If one actually believes this to be true, then I see how you reach this conclusion. If you believe that bitcoin is the only possible or legitimate use of the technology, then I won't be able to convince you otherwise here. If Chris can propose a way to design a decentralized prediction market that does not require a token, I'd be very interested to see it (as would the Gnosis and Augur teams).

The ‘rights’ offered to shareholders are shockingly limited. There is generally no pretense of signing legally valid documentation for profit sharing, voting, auditing, or corporate rights of any kind - despite the fact that promoters often promise that their schemes will permit these things.

It's not clear what he is talking about here. He would prefer promoters offer a "pretense" of legally valid documentation? I think he's misusing that word, and probably means something like "there is not even a pretense of legally valid documentation".

More substantively, this argument is just a re-statement of a point he's already made - that these tokens might be unlicensed securities. If those tokens are securities, then the problem is that they are unlicensed securities, not the lack of a share certificate. If those tokens are not securities, then it doesn't matter.

When ICO’s deliver 100% of the company’s expected receivables at launch, founders are incentivized to leave their project immediately thereafter

This is a problem with the design of a specific ICO, not with ICOs in general. You can structure a token sale to lock funds for arbitrary periods or put in place other protections to deal with this issue. For instance, for funds to be locked into a multisig account that is only released by a trusted third-party on certain conditions - for instance, that the team has met certain milestones that they pre-committed to during the token sale.

No pretense of accuracy or responsibility for claims have led to ornate perpetual motion schemes receiving funding, at expense to humbler better-grounded offerings.

I'm not sure what this is supposed to mean. Is he saying that there are other projects ("better...offerings") that aren't receiving funding, because of ICOs? I would be interested to see that argument, but it is not being made here.

Incumbent and regulated VC models are no longer sustainable fundraising options, as the returns from ICO ponzis are starving out capital and perverting investor expectations

This is an extraordinary claim that requires extraordinary evidence. Is Chris really suggesting that ICOs have made VC funding unsustainable? That ICOs are "starving out" capital? US software companies raised $33B in VC in 2016. The total value of all ICOs listed in his piece + Bancor is ~1% of that total. Blockchain companies continue to raise traditional capital despite the existence of ICOs. I see no evidence, and Chris has supplied none, that this claim is even remotely true.

By the end of the piece, Chris hasn't provided any arguments to support the supposed point of his article: that ICOs are "killing innovation". He's offered many arguments that some ICOs are scams, and that the practice can be used poorly to harm people. The only point that actually connects to this idea that ICOs are harming innovation in the blockchain ecosystem is his argument that ICOs are "starving out capital", which is impossible to take seriously given no evidence was offered to support it.


This brings us to the, uh, less charitable part of the post.

It's become popular in bitcoin circles to oppose the use of ICOs, to argue that they are illegal or immoral, that the core developers of the ethereum platform are responsible for any fraud committed using the technology and, more recently, to support some kind of harsh regulatory response.

It's been very strange to watch. In the early 2010's, the bitcoin community took great offence when outsiders pointed out that bitcoin was used to purchase illegal goods, from drugs to weapons to worse. The fact that people will use a technology for bad ends, they argued, could not be an indictment of the platform as a whole, and certainly not a moral responsibility of the developers who helped build the technology. The bitcoin community is largely made up of people who oppose regulation almost by default, who believe in open financial networks free of government control or censorship, who might even believe that the state itself should not exist.

It seems very unlikely to me that this group of people have developed overnight a sincere concern for the sanctity of US securities regulation. There are genuine concerns around how securities law treats tokens, ICOs, token sales. But if I wanted to gather informed perspectives on this issue, I wouldn't ask a bitcoin maximalist and self-described anarchist whose concern for the law dates back to the moment it became a useful cudgel to wield against a competing platform.

Chris has a pretty clear pattern. He makes absurd, uninformed claims and is rude and often hostile to other people, especially women. When he's challenged on anything he has said or done, he responds by inviting that person onto his notorious youtube show. If the person refuses, it is proof that they are morons, "ethtards", snowflakes, etc. If they say yes, Chris has succeeded in booking a guest that will produce a lot of clicks and pageviews. Rinse, repeat.

He's a troll. Don't take him seriously.

"Granular Exchanges"

30 May 2017 |

One common feature of many commercial transactions is that they are deferred exchanges. For instance, A gives $ to B today in exchange for a promise that, in the future, B will give A some valuable good.

This is a source of risk. The time between the exchange of promises and the performance of those promises introduces uncertainty. Even though A has paid B, B might take the money and run and never provide whatever good they promised to A.

From a very high level, this is one reason we need legal contracts: they make promises enforceable. I can trust a promise will be acted on in the future if I believe I can enforce that promise. Deferred exchanges become less risky.

New technologies like state channels (or payment channels) will allow us to “compress” the time-lag between payment and provision of some good or service. This would reduce risk and uncertainty, and mean we might rely less on expensive solutions used manage that risk (like legal contracts) in some cases.

For instance, there are many services that we pay for in big chunks (e.g. Monthly) but use or receive constantly or in small increments (internet, electricity, netflix). Sometimes these must be paid up-front, while others are billed each month after we have already used the service.

This creates risk on both sides. Utilities spend large sums trying to collect debts from users who consumed electricity or internet but never paid for it. Users may pay for a service, but then never receive it. If the amount we've lost isn’t large enough, we might simply eat the cost because it’s too expensive to pursue the claim.

What if we reduced the time-lag between payment for and receipt of this service? For every minute of internet connectivity you have or consume, your account automatically makes tiny streaming payments. The total cost could be identical to what you pay monthly, but it’s no longer a deferred exchange, and both parties can rely less on promises. If a user stops paying, the internet turns off. If the internet goes down, the user stops paying. We’ve made the exchange more granular - you are paying in tiny pieces, rather than in big lump sums.

This isn’t a particularly new idea - it's often discussed as a component of various projects/dapps in the blockchain space, as well as generally in discussions of payment/state channels. But I thought it deserved its own post and an attempt at giving it a name that put it in a useful context. So: granular exchanges.

Also, obviously this only works for some types of exchange. Money payments can always be granular, but some goods are not provided in incremental amounts. This would not make sense for purchase of a car. In other cases, there might be other reasons why paying in monthly lump sums is valuable even if we could turn it into a granular exchange. For instance, it’s probably worse for society if a person who suddenly lost their job has their electricity turned off in the middle of the month. In the current form, the monthly billing system provides that person some “slack” or credit they can use to figure out how they are going to continue paying for an essential service next month.

A few upcoming events & appearances

09 March 2017 |

A roundup of some interesting events I'll be participating in over the next few months:

"Critical and Emerging Issues in Blockchain Law" Osgoode Professional Development Course, on March 20 in Toronto (link). I'll be presenting & joining a panel discussion on smart legal contracts.

"Landscape View: Applications & Considerations of Blockchain across Industries" hosted by the IEE Standards Association on April 24 in Mountain View, CA. I'll be giving a talk titled "Blockchains and Law: Questions of Application & Questions of Transformation".

IT.CANN Technology Law Spring Forum on May 18th in Toronto (link). I'll be joining a panel with Addison Cameron-Huff and Wendy Gross on Technology, Business Process Innovation and the New Contracts process.

Expert workshop on the "Governing risks and benefits in applications of distributed ledger technologies" on June 15-16, hosted by the International Risk Governance Center (IRGC) at EPFL.

Been busy with non-public facing work for a while. Another post on securities law soon!

Blockchain Tokens & Basics of Securities Regulation

21 January 2017 |


American Union Bank, New York City. April 26, 1932.

Over the last year, the application of securities regulation to blockchain technology has become a popular topic. Entrepreneurs and developers are building exciting new applications while trying to stay on the right side of the law, and lawyers are beginning to grapple with a strange new financial technology. As a sign of the importance of the issue, the first presentation at Devcon (the annual Ethereum developers conference) in Shanghai this past September was given to Peter Van Valkenburgh of Coincenter to give a lecture about US securities law (thrilling to me, less so for most attendees). More recently, some very smart people at Coinbase, ConsenSys, USV, Coincenter and Debevoise & Plimpton LLP published a Securities Law Framework for blockchain tokens.

This post is meant as a short introduction to the issue for non-lawyers, focused on the basic history and policy objectives of securities regulation. In my experience, most commentary on this issue neglects to start with the basics necessary to grok the big picture. In a follow-up post, I’m going to dig more into the legal substance to make a more pointed argument about the challenges of applying existing law to blockchain tokens.

I am assuming the reader is familiar with the concept of a “blockchain token” - if not, I provide an overview of the concept in another article here.

What are securities, and why are they regulated?

“Securities” are a broad category of financial asset. The type of security most people will be familiar with are shares of company stock. Many other financial assets are considered securities, such as bonds and derivatives.

In most jurisdictions, securities are highly regulated. In order to sell shares in your company (to “issue” shares), you must comply with a complex set of regulatory requirements that usually involves disclosure - in other words, an obligation to disclose certain information about your company. Think of this as a form of consumer protection - in order to sell a security to an investor, you need to reveal certain information that regulators have decided is necessary for someone to make an informed purchase - like financial statements, or the identities of the company's directors. These regulations don't apply to all companies of course - there are many exceptions (called "exemptions" in Canada) to these rules that allow, for instance, small companies to raise money from family members without going through a burdensome process.

Securities regulation in the US and Canada were a response to the crash of 1929 and the depression that followed. Before the 1930s, there were few restrictions on financial markets. It was common for companies to wildly exaggerate their current or future profits, and sell shares on the basis of information that was unverified, misleading, or completely false. Following the market crash - fuelled in part by wild speculation - there was a sense that regulation was needed to prevent these kind of deceptive practices and more generally stabilize capital markets.

The definition of a “security” in the US and Canada is expansive. The point is to protect investors who are entering into a certain type of contract. The definition must be expansive to encompass the wide variety of possible investment schemes that have been dreamt up over the years. If the definition of a security were narrow and formalistic, it would be easy for issuers to evade securities regulations while still taking advantage of investors.

Application to blockchain tokens

With this broader policy perspective in mind, it should be clear why some feel that securities regulation will impact the blockchain industry. Blockchain technology gives us a new way of creating & conducting financial relationships. Inevitably, some of these financial relationships might fall within the category governed by securities regulation. Like any other form of money or financial asset, this technology can be used for investment schemes that take advantage of the public.

Most of the public commentary I’ve seen so far on these issues skips past the broader policy concerns. Understandably, the concern for most entrepreneurs right now is that they stay on the right side of the law as it is, and do whatever they can to ensure that their tokens are not considered securities.

But as an industry we also need to think about the medium and long term. Because securities regulation is such a policy-driven area of law, we need to be alive to the broader concerns that motivate securities regulators. Staying clear of existing definitions of what constitutes a security is fine for now, but ultimately securities regulations will change over time, and could be expanded to explicitly include certain uses of blockchain tokens.

I’m hopeful that this can be done in an intelligent way, and that many of the unique capabilities of blockchain technology could satisfy the policy objectives of securities regulation, mitigating the need for a large regulatory burden. This is more likely to happen if entrepreneurs & developers work closely with regulators, developing their applications in a way that is mindful of these broader concerns.

In part 2, we'll dive into the legal test for what constitutes a security and the challenges of fitting blockchain tokens within it. While this will focus on Canadian law, US readers will likely still find it informative as (1) our test is derived in large part from Howey, and (2) the argument is general enough to be applicable broadly.

The above post discusses law, but is not legal advice. If you require legal advice about your particular situation you should hire a lawyer.

Making Sense of Blockchain Governance Applications

11 November 2016 | on governance

Note to reader: This article also appeared on Coindesk on November 11, 2016. In this article I describe some basic theory on how blockchains can be used for governance.

Governance has long been one of the most-hyped applications for blockchain technology. However, there's often little clarity about what "governance" means in this context. The term is used to encompass applications ranging from secure online voting, to new forms of political governance, to flawed experiments in decentralized investment funds.

First, let's be clear about what we mean by "governance". Most often the term brings to mind political governance. The institutions that, according to a system of rules and laws, make up our various levels of government. Political governance includes processes like democratic elections, votes held by representative bodies like parliaments, and the particular responsibilities and powers given to different institutions.

We might also think of corporate governance: the processes used by corporations to make decisions. Corporate governance includes processes like shareholder votes, board meetings and the different levels of power and responsibility given to executives and committees.

Both of these are applications of a common set of tools designed to facilitate group decision-making. Rules, laws, institutions, processes, rights and customs that, used together, become a system that enables organizations to make decisions. Applications of governance range from highly complex systems like nation states to very simple ones – say, a private club with a simple majority voting mechanism for approving new members.

This is what I mean by "governance" for the purposes of this article – the processes and systems used to facilitate decision-making in any organization.

Note that this doesn't refer to a particular use of those tools. Governance systems can be designed well or poorly, they can be effective or not and they can be just or unjust. But, the set of tools that lets us build any of these systems share common features, and it is the tools that might be improved by the various projects, products and technologies that make up the category of "blockchain governance" applications.

The technological requirements of governance

Any governance system requires certain basic technologies.

First, it requires a way to record a set of rules. Rules like who gets to vote, who gets to sit in parliament or who has commit access to a codebase. These rules have to be recorded somewhere securely so that they can't be lost, destroyed or forgotten. Importantly, we must also be able to verify that a given rule is the real rule, and not fraudulent.

Second, there must be a way for people to interact with the rules. For instance, if a rule gives you the right to vote, then you need to be able to exercise that right. You need an election: poll workers, voting booths, paper slips, vote-reading machines and other technologies required to facilitate voting. If there is no way to interact with a rule, then the rule can't serve its purpose in the overall system.

Third, governance systems require a way to enforce the rules. What if someone cheats? What if they vote twice, or refuse to give up power when their term is up? There must be a way to compel individuals to follow the rules, otherwise the rule is again hollow. Existing governance systems use different tools to enforce their rules, like social norms or legal systems.

Let's look at a simple example: a small charitable non-governmental organization (NGO) with a three-member board. The NGO receives funds from sponsors, and must decide how to spend the money to achieve its mandate.

Its rules are contained in a simple constitution that sets out the purpose of the organization, as well as articles of incorporation and bylaws that contain the rules that define how decisions are made. The NGO keeps a copy of these rules, and so does its lawyer, who serves as a trusted third party – a way of ensuring that they can always be certain about what the "real" rule is. To interact with those rules, the board convenes meetings where votes are carried out and recorded. Third, the bylaws are enforced – if necessary – by the legal system of the jurisdiction in which the NGO is registered.

Applying blockchain technology

Blockchain technology offers an elegant new way of accomplishing these three basic functions of governance.

First, blockchains are ideal for recording information in a way that can be later verified as authoritative. Information stored on a blockchain is distributed, meaning it is very difficult to destroy completely and very easy to access. Anyone can verify for themselves that a given entry on a blockchain has not been altered since it was created and verify that it was created through a particular process.

Let's return to our NGO example and suppose it has a rule where the votes of two-thirds of the board members are required to approve any expenditure over $1,000. We could simply store a hashed copy of that rule written in plain language on a blockchain and then later be able to cryptographically prove that the rule we are reading is the same one we placed there and that it has not been altered since.

Second, blockchains provide a new way for people to interact with the rules directly. To do this, we wouldn't simply store a copy of natural-language rules like in our example above. Rather, we could take this a step further and express the rule in code. Using what is commonly known as "smart contract code" technology, some blockchains allow users to create logical scripts that are executed by the blockchain itself.

Instead of recording our NGO's rule in natural language, we could express it as a simple computer program. The program would receive a spending proposal as an input, check to see if its value is more than $1,000, and then trigger a vote. The program would receive inputs in the form of signed votes, count them, and then determine whether there was a majority. If two out of three board members have voted "yes", then the program would automatically send the funds to the recipient defined in the proposal.

Crucially, we have already achieved our third requirement – enforcement. When the rule is expressed as executable code, the rule can be enforced at the same time it is exercised. So long as the code can control the assets subject to the rule, then the rule itself executes the outcome.

While they sound mundane, these basic features form the building blocks of any governance system. The fact that they can be achieved – even in a narrow sense – through the scripting capabilities of blockchain networks opens up new possibilities to augment existing governance systems or build entirely new ones.

The larger context and limitations

Blockchain governance applications are an extension of the technology's general capability to execute rules defined in code. This capability is most often discussed in the context of "smart legal contracts", where blockchain code is used to augment traditional legal contracts. In that context, blockchain code is used to store and enforce rules as agreed to between two parties to a commercial relationship. Here, we are using the same technology – blockchain code as rules – and just applying it to a slightly different use case.

In a commercial contract, the parties are agreeing to a set of rules designed to facilitate trade of some kind. In a governance system, the parties are agreeing to a set of rules that will help them cooperate and make decisions together. In either case, the ability of blockchain smart contract code to "enforce" its own rules is a powerful capability, though it comes with limitations.

The first important limitation is what can actually be controlled by a blockchain governance system. In our example above, our blockchain-enforced spending limit rule was useful because the rule itself can have control over the funds at issue. Once the votes are in, the money is sent. This is possible because we are assuming that the NGOs funds are in cryptocurrency, which can be directly controlled by blockchain smart-contract code.

But if the thing being controlled by the governance structure was something else – US dollars, or a physical asset like a vehicle – our solution can't be as easily automated. We could hold a vote through our system, but ultimately some person would have to enforce the outcome of that process by making a bank wire or transferring legal title of the car.

Over time, we should expect that other types of assets – like fiat currency, or vehicle registries – will be integrated with blockchain systems, which will expand the utility of blockchain governance systems.

Likewise, if our governance system is primarily concerned with controlling access and permissions within some other system (eg: over a codebase, or within a private Internet forum), then the utility of our blockchain governance system depends on whether the blockchain-enforced rules can control the permissions or access in those systems. This, too, is a barrier that will quickly be overcome as platforms are built that integrate easily with blockchain technology.

Putting existing use cases into context

Keeping in mind our analysis above, how do the various projects that fall into the category of "blockchain governance" relate to one another?

Some of these projects aim to simply provide a user a set of tools they can use to build their own governance systems. Boardroom, for example, is a suite of "governance components" that a user can take and structure however they want. Using pre-built default code contracts – things like votes, proposals, boards and committees – a user can more quickly build something that fits their particular needs.

The point of the product isn’t a specific type of governance, but rather just providing the tools needed for users to build their own governance structures. Our NGO above, for example, could use Boardroom to build the simple governance system we described.

Other projects attempt to build new types of governance systems that take advantage of the unique strengths of blockchain technology. The most obvious of these strengths is that blockchains are decentralized – there's no central party required to maintain the system or "enforce" its rules. This makes it possible for governance systems built on blockchain networks to themselves be decentralized, with no central party.

The best known project of this kind was The DAO. The DAO, which stands for decentralized autonomous organization, aimed to be a user-controlled venture fund. It raised funds by selling tokens, which granted holders of those tokens certain rights in its governance system. Token-holders would then vote on proposals submitted to the DAO and decide where it should invest its funds. The DAO had no legal entity and no bank account – it was governed entirely through blockchain code.

It was an audacious plan, and it's unfortunate that it failed as quickly as it did. Critical security flaws in its code let an attacker siphon away The DAO's funds, destroying confidence in the project and leading to an elaborate game of cat-and-mouse as The DAO's creators tried to salvage their project and recapture the funds. As an experiment in smart-contract security practices, The DAO was a failure. But, it was also an experiment in whether a governance system of this type – a decentralized venture fund – could succeed in the marketplace. The failure of the first experiment unfortunately means the second wasn't truly tested.

A third type of blockchain governance application is aimed at solving the practical problems facing traditional enterprise as they adopt blockchain systems more generally. For instance, consider the governance challenges facing consortium blockchain projects.

Many "enterprise" blockchain systems being explored today take the form of a permissioned blockchain network that is shared between entities – a consortium. The nodes that make up the permissioned blockchain would not be maintained by the public, but rather by each participating institution. For instance, a shared blockchain ledger maintained by several banks that enables them to more easily settle cash balances between themselves, or a shared blockchain ledger that tracks ownership of financial assets like shares, derivatives, or bonds.

One challenge facing institutions as they work on these projects is how they will be governed. If there is no central entity that will "own" the ledger – indeed, this is part of the value of this approach – the participants must be able to govern it jointly. Not only is this politically difficult (coordinating among competitors with different priorities is never simple), it's a practical problem as well. There must be a process, mediated by the code itself, through which the consortium makes critical decisions, like voting to add new members or removing existing ones, or upgrading the code over time. More than our other examples above, this will require careful integration of the blockchain-code components that govern the rules of the system and the traditional governance and legal requirements facing financial institutions.

Within "blockchain governance" we can usefully distinguish between at least a few categories, illustrated by the examples above. There are projects that aim to simply provide the tools of governance, like Boardroom. Then there are blockchain projects that are using those tools to build particular forms of governance. The DAO sought to build an entirely new form of economic entity made possible by blockchain governance.

Others have more modest aims, and are designed to solve the particular problems introduced by the adoption of blockchain technology – like those facing consortium projects. These use decentralization in a more limited sense: to enable a smaller group of participants like banks to jointly govern a shared piece of financial services infrastructure, with no centralized entity.

The bigger picture

Blockchain governance systems matter because they have the potential to permanently lower the cost of creating and maintaining governance systems of all kinds.

Governance is valuable, and the systems that make it possible are expensive. Corporations spend large sums ensuring that their internal governance processes are followed, and they spend even larger sums settling lawsuits with shareholders or regulatory agencies when those processes are not followed or are inadequate.

For organizations in jurisdictions with weak rule of law, the challenge is even more stark – the institutions necessary to ensure basic political or corporate governance may simply be unavailable without relocating to a different country. Access to functional governance systems is a barrier to entry for all kinds of organizations, ranging from companies to political parties to charity organizations.

Blockchain governance systems could, in some circumstances, serve as a foundation for less expensive, more efficient and more automated governance. This could reduce the regulatory burden on existing political and corporate governance systems and give others access to enforceable, verifiable governance systems where they were not otherwise feasible.

It seems odd to think about governance as dependent on, or intertwined with, technology. But it's certainly true that technology shapes, to some degree, the possible range of governance systems available to us. The possibility of modern democratic governance depends on the transportation and communication technologies that make it possible for millions of people to engage in secure democratic elections, and for a centralized bureaucracy to manage a nation with millions of citizens.

Blockchain governance systems won't usher in a utopia, up-end the modern corporation or replace all of our existing governance methods. There are many aspects of governance that cannot be replaced by, or obviously improved through, technology. A governance system written in code can be designed just as poorly as one written in ink. But at a minimum, we’ve expanded the basic governance toolkit.

Building the Foundations for a Scalable Ethereum Community

28 August 2016 | on governance, ethereum, policy

Note to reader: This article also appeared on Coindesk on August 28, 2016. In this (long!) piece I recap the aftermath of the DAO hack, consider arguments for and against implementing a governance structure over the Ethereum network, and suggest some practical ways to move forward.

Recent events have forced ethereum's community to the forefront. On 17th June, a critical security vulnerability in an ethereum application called The DAO was used to drain millions of dollars worth of ether into accounts controlled by an anonymous attacker. After a period of deliberation, a majority of core developers, miners and other members of ethereum's community decided that the best path forward was to hard fork the network to "undo" the hack and return the stolen funds.

The community's power to revise ethereum's transaction history has surprised many outside observers who were told that blockchains are, as a rule, immutable.

To the broader market, the inner-workings of the deliberative process that led to this outcome are at best opaque. The decision proved controversial within the community as well, with a vocal minority taking the position that ethereum has betrayed its core principles and choosing instead to support the un-forked network, with the result being that there are now two blockchains that share ethereum as a common ancestor.

"The community" is often in the background of our conversations about ethereum. In any discussion of ethereum's ability to provide settlement finality, it's a necessary caveat: in two pieces from earlier this year, both Tim Swanson and Vitalik Buterin articulate that, ultimately, it is the community's economic consensus which determines which chain is legitimate. More broadly, any conversation about ethereum’s future potential relies on the implicit promise that there will continue to be a productive community of talented developers working to maintain and support the project.

But for the most part, the community is treated as a black box. We know it is important, we believe that it works, but we rarely look too deeply at what makes it so. When our community functions as we expect, we congratulate ourselves, as we did when we successfully hard forked into Homestead. When someone else's community struggles, as bitcoin has with the divisive block size debate, we point to it as a sign of inevitable moral failing.

There have already been suggestions for how the ethereum community could better manage future situations like the DAO hard fork. But too often these require creating formal rules or governance structures which are impractical in a decentralized community.

Rather, our solution should begin by looking at what works today, what doesn’t, and by finding practical ways to make incremental improvements.

This isn’t just an academic issue. The community wields tremendous power over its blockchain. Convincing the world to build its future on ethereum requires proving that our community will exercise that power in a responsible way. Even more, it requires proving that our community will continue to be effective and responsible as the platform scales into something far larger than it is today.

The community's role

The DAO hard fork is a useful practical illustration of how the community exercises power over its blockchain.

The ethereum community is the group of people, institutions, companies and other organizations that together support and maintain the ethereum blockchain. This includes the core developers who work on the ethereum protocol itself, the miners who own and operate the nodes that constitute the ethereum network, the larger ecosystem of developers and entrepreneurs who are building applications on the platform, researchers who make critical contributions to the development of the platform, ordinary token-holders or users of ethereum applications, and others.

In response to the DAO hack, core ethereum developers proposed a hard fork that would return the stolen funds. Essentially, the miners whose nodes constitute the ethereum network would all agree to adopt a new version of the ethereum software that would remove the offending transactions.

This change requires a "hard fork" because it breaks backwards compatibility – the entire network must agree on the state of the blockchain to continue.

However, a minority can reject the changes introduced by a hard fork and continue with their own chain – they have the power of "exit". This is what happened after the DAO hard fork – a minority of miners decided to continue on without accepting the changes, and became their own minority blockchain. In a narrow sense, the ethereum blockchain's immutability has not been compromised by the hard fork. The "original" chain, without any of the edits introduced by the hard fork, still exists in the form of ethereum classic.

However, the minority has no guarantee that the broader community will devote resources or attention to their blockchain. This is significant because the community gives ethereum part of its value: the expectation that, over time, the protocol will be upgraded and a large ecosystem of applications will be developed, increasing the utility of the platform. The ethereum community understands this intuitively, which is why a few days afterwards both sides of the fork were competing to tally up which companies, people or researchers were working on their preferred chain.

These nuances of blockchain immutability are not widely understood. Data you store on a blockchain – including tokens, or code – has a strong probability of remaining immutable. But preserving that immutability might require you to choose a minority chain, in which case you have no guarantee that your preferred chain will continue to attract the attention of the broader community. And if the value of your tokens or the utility of your code depends on that community, the minority chain may not be much use to you.

This extends beyond immutability. Hard forks are not typically changes to the history of transactions – more often, they are protocol upgrades or new features that change how the blockchain functions. For example, a change to increase the maximum block size in bitcoin. More generally then, we might say that you have a guarantee against any change that could be introduced through a hard fork only if you can accept being in the minority in some cases.

Forming a minority chain is not always possible. If I am the only person that wants to reject a hard fork, I could certainly operate the lone remaining node of the unchanged blockchain, but my chain would not be viable. In practice, a minority chain needs some minimum amount of support to attract a community of developers or convince an exchange to list its tokens. So, we need to add another caveat: you have a guarantee against changes introduced through hard forks only if you can form a sufficiently large minority to continue a viable chain.

(Lastly, it's worth noting that the parameters of hard forks might change significantly in the future, which would alter the dynamics I describe above).


The community matters. Core developers have influence over which concrete proposals are brought to the community, and are trusted by miners to provide technical guidance. Miners have control over which hard forks are accepted by the majority of the network. A larger community of developers, companies and others determine which post-fork chain attracts the most talent and resources. The ability of any individual to reject a change introduced through a hard fork depends on convincing a viable minority of the community to come along with them.

None of these decisions are made in a vacuum. They require the community as a whole to be able to identify novel problems, surface relevant expertise, propose effective solutions and thoroughly consider the benefits and costs of those solutions. Ideological beliefs and financial incentives shape the decisions of all community members to different degrees. Disputes and personal conflicts can, if not resolved, damage the decision-making process and inhibit cooperation.

We can't separate the technical components of the ethereum blockchain from the human community that supports it. This isn’t just some nice sentiment. This is mission-critical wetware on which ethereum’s future depends. A community can be better or worse, cooperative or siloed, productive or toxic. A blockchain whose community loses key expertise and is unable to debate solutions without devolving into personal conflict may be a perfectly adequate piece of technology, but it is a terrible blockchain. What guarantee do we have that this will never happen to us?

Defining the community

Within the ethereum community, we often delude ourselves into thinking that blockchains are beyond these concerns. There is a tendency to believe that because the community is decentralized, it is immune to the challenges of other human organizations. Part of this is due to the lack of easy analogs: blockchains are not companies, they’re not governments and they’re not quite like other open-source projects either.

It’s difficult to point to a model for what our community ought to be. Blockchain communities are novel things with no easy analogs. But they are still made of people, and subject to the same flaws and strengths as any human organization. Even decentralized communities can consciously try and change or improve themselves. Members of the community are free to adopt shared norms, ethical standards, and processes that make the group as a whole more effective at achieving a shared goal.

The ethereum community’s capacity for critical self-analysis and improvement isn’t just a theoretical concern. So far, the community has functioned well enough. But will the same decision making processes used today be as effective when the community is 100 times as large? When the economic value at stake approaches the size of a small country? When the political and financial pressures on key community members are far greater?

Over the next few years, we will attempt to scale the platform. How will we scale the community to match if we don’t understand what makes it work today?

Inspiring confidence

Outside observers of blockchain communities often make a different mistake.

Those with backgrounds in finance or law often grok immediately that public blockchains depend on a community. But when they look at it, they see an opaque mass of pseudonymous techno-anarchists engaging in messy arguments on Reddit and twitter and dozens of chat rooms. They conclude that there is no way this community could serve as a foundation for a global value transfer platform.

This is where the issue of "the community" intersects with another common topic in the conversation around ethereum – whether, and how, public blockchains should be directly integrated into existing legal structures. If you believe that the community alone can never provide sufficient confidence, then the obvious conclusion is to try and use legal or regulatory tools we already understand to accomplish the same end. For example, by treating core developers and miners as fiduciaries.

This is wrong, too – or at least premature. It is generally true that people tend to overestimate the stability of regulated centralized institutions and underestimate what can be achieved by decentralized systems. It's probably too early to say that the decentralized community around ethereum could never convince the market that they are capable of maintaining the ethereum blockchain in the long-term.

For now, it’s an open question. But if advocates of public blockchains believe that the community shouldn’t be subject to onerous regulation, then the community needs to find other ways to provide assurances to the outside world.

Improving, decentralized

The ethereum community needs ways to improve itself over time, to adapt to new challenges and provide greater confidence in its decision-making processes as the platform grows.

Some people want to use very heavy tools to accomplish this. Either by trying to fit the ethereum community into existing legal and regulatory structures, as mentioned above, or by having the community adopt rigid governance systems of some kind that will constrain future decision making.

Ethereum's decentralized nature makes these solutions impractical. Using existing legal tools in individual jurisdictions are more likely to cause entrepreneurs to flee that jurisdiction than they are to strengthen confidence in the community. Trying to convince the community to adopt some type of hierarchical, formal governance structure is likewise difficult: it’s seen to compromise the decentralization of the platform, a key ideological value shared by large segments of the community. Maybe some version of these “hard” tools could work someday, but for now they're non-starters.

If decentralized communities like ethereum are environments where formal processes are weak, maybe we shouldn’t start there. Maybe the right way to approach decentralized community governance is to try and develop very strong shared social norms and standards of behaviour, enforced not through some central mechanism, but through rough social consensus.

Formal processes are not the only way to improve a community's governance. Communities can also differ by the norms of behaviour they freely choose to adopt. A norm is simply an informal rule shared by a community of people. While not strictly enforced, norms play an important role in shaping how any community behaves. This is commonly understood in other contexts. For instance, every successful startup knows that their culture – their shared norms – is critically important.

We can already observe norms developing within the ethereum community. For instance, it’s become common for anyone writing about specific blockchain projects to disclose whether they are invested in it, either to remove the appearance of a conflict of interest or to signal their commitment to the project (I own less than $2,000 worth of ETH). Our community has a strong norm in support of identifying and widely criticising anything that even smells like a scam.

The advantage of relying on informal rules like norms is that it lets us take the processes used today and make incremental improvements. Even though it may be messy to outside observers, the community does “work” and has proven itself capable of responding to threats to some extent.

We aren't going to redesign the community into a system of committees governed by a constitution (at least not anytime soon). But we can take the community we have and try and articulate basic improvements where they are needed, argue about them, and build social consensus around them.

A thorough analysis of the ethereum community is beyond the scope of this essay. But drawing on the events of the last few months, here are three general areas that might be worth considering in more detail:

1. Reducing information asymmetry through transparency and pro-active disclosure

Some members of the ethereum community have access to more information than others. Core ethereum developers who are well-connected in the community and involved in critical projects, for instance, have more knowledge, insight and access than the average token holder. This is an example of information asymmetry, a type of problem that motivates disclosure and transparency efforts in many other contexts. In public markets, for example, companies are required by law to provide necessary financial and other information to their shareholders.

We might ask a similar question: What level of transparency should the community expect from its key members? We can already observe a strong pro-transparency norm. Shortly after the DAO hack, for example, a transcript of a conversation between core community members was released that allowed the broader community an unfiltered view into the early moments of the decision making process that shaped the initial response.

But our approach to transparency and disclosure is inconsistent at best. Many industry observers need to understand the deliberative process that led to the DAO hard fork in order to predict how the community might act in similar future situations. The public resources available to them – mostly news articles and blog posts – are insufficient and incomplete. Larger institutions rely on personal contacts from within the community to explain what happened, and why. If we want the broader market to trust the community, there should be better public channels for communicating decisions and the processes that led to them.

Information asymmetry is related to another problem: real or perceived conflicts of interest. Those who have access to information by virtue of their position in the community could profit from that information through speculation. Relatedly, those with particular influence in the community could use that influence to support outcomes that benefit them financially.

During the DAO hard fork debate, there was a recurring allegation that’s social ties to core ethereum developers motivated those developers to support the fork. Though this has been adamantly denied, the fact that it was a credible allegation at all damaged the legitimacy of the process.

Are there circumstances in which prominent community members should declare a conflict of interest and recuse themselves from the discussion? If so, what are they?

2. Community engagement

When important decisions are being made in the ethereum community, do we have an obligation to ensure that the furthest reaches of the community – say, passive token holders – are aware of what is going on and how it might affect them? Today, this might seem unnecessary – anyone who owns ETH probably does so because they are invested in this project and are already following the discussion to some extent. But it's not clear how engaged the wider community is in such issues – prior to the DAO hard fork, a coin-vote held to gauge support had a turnout of only 5%.

In the near future, this problem will grow. Eventually, we should hope that many people that own ETH or rely on the platform will not have to care about the internal politics at the centre of the community. But these people would still be materially affected by the community’s decisions. It would probably be easier for them to trust the platform as a whole if they had confidence that, if a big decision is at hand, they will be notified.

This isn’t a unique problem for blockchains. A similar situation exists for public companies, whose shareholders need to be notified of important decisions or votes that require their attention. In most jurisdictions, there are regulations that require corporations to notify their shareholders (and the public markets in general) of important votes, and an entire industry built on helping shareholders make decisions on how to vote.

We can imagine that an analogous system of notification and voting could be accessed through the wallets and exchanges that token-holder use to manage their blockchain assets. In the case of a situation like the DAO hard fork, this could give the community as a whole far better information about the preferences of token-holders.

3. Resolving conflict

Occasionally, disagreements will turn into disputes. These can become toxic and damaging to the community as a whole. We've already seen in the bitcoin block size debate how a bitter conflict between individual people can spill out into public and have a negative impact on the platform as a whole. During the DAO hack and its aftermath, personal attacks and other drama distracted and demoralized the community.

Ethereum developer Vlad Zamfir wrote on Twitter recently that the most important thing he learned from the DAO hard fork was the importance of good manners. This isn’t just some nice idea – this is an essential norm for a community that wants to retain and attract talent.

This is something that other open-source communities have learned the hard way. In 2014, Linus Torvalds said that the thing he most wishes he had done differently over the previous 23 years was treat people better:

"From a technical standpoint, no single decision has ever been that important... The problems tend to be around alienating users or developers and I'm pretty good at that. I use strong language. But again there's not a single instance I'd like to fix. There's a metric shitload of those."

Ethereum’s community prides itself on being collaborative and polite, a widely shared norm that is due in no small part to Vitalik's example. How do we ensure that it stays this way?


Talking about the community in these terms seems odd. Sometimes it feels like an overly serious argument between moderators of a niche online forum, and other times like a disconcertingly vague conversation about securities laws.

But this makes a kind of sense. On the one hand, this is an odd internet subculture made up of people with a shared geeky passion. On the other hand, it is a community that supports and ultimately controls what could become a tremendously important piece of global infrastructure. If that happens, understanding the dynamics of our quirky community might someday be as important to global commerce as understanding the internal politics of the Federal Reserve.

If ethereum succeeds, the community will have to grow and adapt over time. But because the community sits in this uneasy middle-ground, it’s hard to articulate how it could grow or adapt. Doing nothing and hoping for the best is a mistake. Doing too much – by suggesting formal, hierarchical governance – is a poor fit in a decentralized community.

An easier place to start is to realize that there’s a middle way: formal structures aren’t the only mechanism for improvement. We have to take the community as it is – the one that works now – and build on it, by adopting norms and behaviours where needed. It’s something we do already – but it’s time to start being more intentional about building a scalable community.

Making Sense of Blockchain Smart Contracts

04 June 2016 | on smart-contracts

house rental contract, Mesopotamia, 514 BC -

House rental contract, Mesopotamia, 514 BC

Note to reader: This article also appeared on Coindesk on June 4, 2016. In this piece I argue for a distinction between "smart contract code" and "smart legal contracts". This piece has since been cited by R3's Tim Swanson & Lee Braine's work at Barclays.

The term “smart contract” has no clear and settled definition.The idea has long been hyped to the public as a central component of next-generation blockchain platforms, and as a key capability for any practical enterprise application.

They are defined variously as “autonomous machines”, “contracts between parties stored on a blockchain” or “any computation that takes place on a blockchain”. Many debates about the nature of smart contracts are really just contests between competing terminology.

The different definitions usually fall into one of two categories. Sometimes the term is used to identify a specific technology – code that is stored, verified and executed on a blockchain. Let’s call this type of definition “smart contract code”.

Other times, the term is used to refer to a specific application of that technology: as a complement, or substitute, for legal contracts. Let’s name these “smart legal contracts”.

Using the same term to refer to distinct concepts makes answering even simple questions impossible. For instance, one question I’m often asked is simply: what are the capabilities of a smart contract?

If we are talking about smart contract code, then the answer depends on the capabilities of the language used to express the contract and the technical features of the blockchain on which it operates.

But if we are asking about using that technology to create a binding legal agreement, or an effective substitute for a binding legal agreement, the answer depends on far more than the technology. This answer depends on existing legal doctrine and how our legal, political and commercial institutions decide to treat the technology. If businesspeople don’t trust it, the legislature doesn’t recognize it and the courts can’t interpret it, then it won’t be a very practically useful “contract”.

It would be futile to try and change the way people use the term already. Practically speaking, we are probably stuck using – or at least reading – the term “smart contract” for now. This makes it essential for anyone interested in this space to understand the different ways the term is used and be able to distinguish clearly between them.

Smart contracts as smart contract code

Blockchains can run code. While the first blockchains were designed to perform a small set of simple operations – mainly, transactions of a currency-like token – techniques have been developed to allow blockchains to perform more complex operations, defined in full-fledged programming languages.

Because these programs are run on a blockchain, they have unique characteristics compared to other types of software. First, the program itself is recorded on the blockchain, which gives it a blockchain’s characteristic permanence and censorship resistance. Second, the program can itself control blockchain assets – i.e., it can store and transfer amounts of cryptocurrency. Third, the program is executed by the blockchain, meaning it will always execute as written and no one can interfere with its operation.

To developers and others working directly with blockchain technology, the term “smart contracts” is most often used to refer to this blockchain code. You’ll see this use of the term in the Ethereum documentation, on stackexchange and in technically minded articles. The term has been particularly associated with the Ethereum project, whose primary purpose is to be a platform for smart contract code. But today, the term is used generically across the community to refer to any complex program that is stored and executed on a blockchain.

Calling these programs contracts is helpful in that this code is governing something important or valuable. We only go to the trouble of creating a binding contract when it’s important that we be able to enforce the terms. Similarly, we only use smart contract code when the code controls something important, like money or identity.

That said, smart contract code need not resemble anything we would ordinarily think of as a “contract”. While the code could articulate a conditional financial transaction (“send 1 BTC from Alice to Bob on July 1, 2016”), it could also be a governance application that controls account permissions (“if Alice has voted yes, remove Bob’s voting rights over Application X and notify the following accounts…”).

In many cases, smart contract code is not used in isolation but as a small piece in a larger application. Every DApp, DAO, or other blockchain-based application is built using smart contract code to perform operations on their chosen blockchain. Any Ethereum application that you’ve read about – like Augur,, or Boardroom – is made out of smart contract code.

Imperfect, misleading, and someday outdated

The term receives a lot of valid criticism. Relying on the metaphor of a “contract” is misleading because it emphasizes a single narrow use case. The term fails to capture one of the key capabilities of blockchain programs: that they have a kind of independent agency.

Smart contract programs can themselves hold balances of cryptocurrency, or even control other smart contract programs. Once they are created, they can act autonomously when called to perform an action. For this reason, many prefer the term “smart agent”, analogous to the more general concept of a software agent.

Eventually, this use of the term may simply fade from use as blockchain technology matures.

Developers will be more likely to refer to a specific language (“Let’s look at your Solidity code”) or platform (“Our application runs on Eris.db”) that they are working with, as opposed to a generic term that could describe any complex operation on a blockchain.

The capabilities and purpose of smart contract code as distinct from other code may simply become clear from context, without requiring the use of a clumsy analogy like “contract”. It might end up being more similar to how we speak of HTML and JavaScript today, without having to think about how the former is a “markup” language, playing a distinct role from JavaScript in the overall web application.

Smart contracts as smart legal contracts

Among those who work in finance or law, the term “smart contract” is often read quite differently than the definition above.

“Smart contract” here refers to a specific use case of smart-contract code – a way of using blockchain technology to complement, or replace, existing legal contracts. This is the definition of the term I considered in my last post: the use of code to articulate, verify, and enforce an agreement between parties. A smart legal contract.

These smart legal contracts would most likely be a combination of smart contract code and more traditional legal language. For instance, imagine a supplier of goods enters into a smart legal contract with a retailer. The payment terms could be defined in code and executed automatically when delivery is made. But the retailer would likely insist the contract include an indemnity clause, whereby the supplier agrees to indemnify the retailer against claims flowing from a defective product. There would be no point representing this clause in code, since it is not something that can self-execute – it exists to be interpreted and enforced by a court in the case of litigation.

Commercial agreements are full of boilerplate clauses that protect parties from various edge-case liabilities, and these are not always suitable for representation and execution through code, meaning that smart legal contracts will require (at least for the foreseeable future) a blend between code and natural language. This is the basic idea behind Eris Industries’ dual integration system, Primavera de Fillipi’s proposed Legal Framework for Crypto-Ledger Transactions, and R3’s Corda smart contracts system.

Could smart legal contracts ever be considered legally enforceable? Probably. Despite what many think, the conditions under which an agreement becomes a legally enforceable contract are flexible and attuned to the underlying relationship between the parties, rather than dependent on the form the contract takes. Anything from a verbal agreement to an email conversation can become a contract at law, if the basic elements of a contract can be found.

Many contracts, many use cases

The category of smart legal contracts is complicated by the fact that there are many different types of contracts in the world, only some of which are obvious candidates for use as “smart contracts”. A legal contract could be anything from a verbal agreement for someone to paint your house to a derivative traded electronically in financial markets.

Since early 2015, the use cases attracting the most attention are smart legal contracts as smart financial instruments like shares, bonds, or derivatives contracts. Articulating these contracts in code could allow financial markets to become more automated and simplify many process-intensive systems related to trading and servicing of financial instruments.

These “smart financial instruments” do not exist at scale today, although many people are working to build them. R3’s recently announced Corda platform is designed to facilitate this type of smart-contract. Digital Asset Holdings recently acqui-hired Elevance, a Swiss firm that has developed a way to model financial agreements in code. In April, Barclays’ revealed details of a scheme, in cooperation with R3, to represent ISDA agreements in smart contract code.

Financial instruments are just one type of contract that could benefit from blockchain code. As the technology matures, other assets – e.g. real estate, or intellectual property – may be stored and traded over blockchain systems. As new asset types go “on-chain”, the agreements used to govern those assets in the world today (like a mortgage or licensing agreement) may benefit from blockchain-based analogs.

Alternatives to traditional legal agreements

Many advocates for blockchain technology see larger possibilities. Rather than merely imitate or complement the legal contracts we use today, perhaps smart contract code could be used to facilitate new types of commercial arrangements.

We might even call this a third definition of the term: using smart contract code to create novel, alternative forms of agreements that are nonetheless commercially useful. Let's call these "smart alternative contracts".

This approach takes a broader view of the real-world problem solved by contracts. Commerce depends on individuals being able to form stable, predictable agreements with one another. Contracts, along with a strong legal system, are the primary mechanisms we use to shape each party’s incentives to the point where they have sufficient confidence in their relationship to engage in the risky business of trade.

But perhaps legal agreements are not the only solution to this general problem. Smart contract code offers a new set of tools to articulate and enforce terms, and they can be used to create systems of incentives that may be sufficient to make commercial relationships possible.

The most widely discussed opportunity of this type is machine-to-machine commerce. The growing ecosystem of smart devices – particularly those that are in some fashion autonomous – will eventually need a way to engage in basic commercial interactions with one another. For instance, a washer that buys its own detergent or a car that can pay to recharge itself.

These transactions still require a minimum level of trust to be commercially viable, but are ill-suited for legal contracts, which are comparatively expensive and require the involvement of legal persons like a corporation or human. Smart alternative contracts might enable an entirely new type of commerce carried out between our computers, cars, phones, and appliances.

There probably are – or will be – other types of commercial interaction that aren’t well suited to traditional legal contracts. New markets, suddenly made possible by technology, but which are underserved by legal tools that are slow to innovate and adapt. Smart alternative contracts might let us stretch the web of trust out a little further, a little faster, beyond the reach of the legal system, where they can enable new forms of commerce not possible today.


The lack of clear terminology in this field is an unfortunate reality. Those of us who work in the blockchain space should be mindful of how the term is being used in different communities, and be prepared to ask a series of annoying, though necessary, clarifying questions when asked about the nature and potential of “smart contracts”.

The different uses of the term illustrate a broader challenge in our industry. The interdisciplinary nature of blockchain technology, and “smart contracts” in particular, lead people to see the technology as primarily belonging to their own discipline, at the expense of the others.

Lawyers often look at smart contracts and see marginally improved legal agreements, without appreciating the fuller potential of blockchain-code to extend beyond law’s reach. Developers, on the other hand, consider smart contracts and see the limitless possibilities of software, without appreciating the subtleties and commercial realities reflected in traditional legal agreements.

As with any interdisciplinary field, both must learn from the other.

How Close Are Smart Contracts to Impacting Real-World Law?

11 April 2016 | on smart-contracts, ethereum

Note to reader: This article also appeared on Coindesk on April 11, 2016. In this piece I introduce the basic concept of a smart contract and explain why blockchains are an ideal technology to implement them.

Over the last year, the concept of a "smart contract" has received renewed attention in legal and business circles.

Advancements in blockchain technology have led some to believe that smart contracts could soon offer alternatives to traditional commercial and financial agreements, with dire results for the legal and financial sectors. While this enthusiasm may be premature, the legal profession nonetheless remains mostly unaware of this important emerging technology and the long-term implications for their profession.

In this context, "smart contract" refers specifically to the use of computer code to articulate, verify and execute an agreement between parties. Whereas a typical contract is drafted using natural language, the terms of smart contracts are expressed in code, similar to a programming language like javascript or HTML.

The contract is then "executed" by a computer – given the conditions of the agreement, and a set of defined inputs, the smart contract enforces its own terms.

Readers familiar with blockchain technology will know that the term "smart contract" is often used in a more general sense to refer to any script or program that operates on a blockchain. However for the purposes of this article, we focus on the narrower meaning described above: using code in place of traditional contractual agreements between parties.

Point of origin

The term "smart contract" was first popularized by computer scientist Nick Szabo in his 1997 paper "The Idea of Smart Contracts". The vending machine, he described, is the simplest form of a "smart contract" – a mechanical device designed to transfer ownership of a good (a candy bar) when provided with a certain defined input ($1.50). Because the machine itself "controls" the property – by being physically sealed – it is able to enforce the terms of the "contract".

Extending the concept, Szabo suggested that computer code could be used in place of mechanical devices to facilitate far more complex transactions of digital property. Rather than transfer ownership of a candy bar, a smart contract could transfer ownership of real estate, shares or intellectual property. The program would define what "inputs" were necessary for the contract to execute – things like payment, votes of board members or any other condition that can be expressed by code.

Consider a basic options contract. A call options contract entitles the holder to buy a given security at a defined price. In our example, Alice buys our "smart options contract" from Bob. The contract entitles Alice to purchase 100 shares of Acme Inc from Bob at a defined price of $50 per share. The contract has an expiry date, after which Alice is no longer entitled to buy the share at the defined "strike price".

Expressed in pseudo-code, a simple "smart options contract" might look like this:

contract Option  
  strikePrice = $50
  holder = Alice
  seller = Bob
  asset = 100 shares of Acme Inc.
  expiryDate = June 1st, 2016

function exercise ( ) {  
  If Message Sender = holder, and
  If Current Date < expiryDate, then
    holder send($5,000) to seller, and
    seller send(asset) to holder

In the first section, the smart options contract defines the relevant terms – the underlying asset, the strike price, the identities of each party and the expiry date. Then, a function we’ve named "exercise" enables the holder to trigger the purchase of shares at the strike price at any moment before the expiry date.

The function first checks to see if the entity triggering it (the "Message Sender") is the holder, and then checks to see that the contract is still within the expiry date.

If both are true, then the contract immediately executes by transferring cash from the holder to the seller, and the assets from the seller to the holder, according to the contract’s terms.

Two challenges

Until recently, smart contracts were little more than theory. In general, there were two fundamental challenges that needed to be addressed before smart contracts could be used in the real world.

First: How would a smart contract actually control real assets so that it could enforce an agreement? A vending machine, to return to Szabo's example, controls property by physically securing it inside of itself. But how could code do the same? In our options contract above, the "exercise" function transfers money and assets between the two parties. How can a computer program control real-world assets like cash and shares?

Second: What computer would be trusted to "execute" those terms in a way that both parties could rely upon? Parties must not only agree on the code of their contract, but also the computer which interprets and executes that code. A shared standard, at the minimum, would have to exist, and be used in a way that was verifiable by each party – ideally, without requiring the parties to physically inspect the computer in question.

In the last few years, solutions to both of these problems have come into sight. Emerging research and development surrounding blockchain technology may provide a basis to make smart contracts a reality in the near future.

The first use of blockchain technology was the digital currency bitcoin, made famous by its mysterious creator and sudden price increase in late 2013. In the last few years, its underlying "blockchain" has been intensely studied and adapted to expand its use beyond simple digital currencies. Startups, open-source communities and large financial institutions alike are improving and expanding the technology with the aim of one day using it to facilitate exchange of fully digital assets.

A blockchain is an authoritative database. It is a database that, by virtue of the way it is maintained and updated, has very high trust properties. Blockchains are not controlled by a single party. There is no single company, organization or person that has ultimate control over a blockchain. Rather, a blockchain is maintained, updated, and secured by a network of participating computers. Each computer keeps a full copy of the blockchain database, and each copy is kept in synchronization with the others by a system of cryptographically-enforced rules called a consensus algorithm.

Crucially, blockchains are append-only databases, meaning that once information is validly added, it can never be removed. Each update to the blockchain is secured by a cryptographic process known as a hash function, which allows the network to detect and reject any attempt to distribute an edited copy of the database. In this way, blockchains form the foundation for the recording and transfer of fully digital assets.

Because the blockchain is always kept in synchronization, there is only ever one true record of ownership – essential to prevent anyone trying to double-spend their assets by sending it to multiple parties at the same time, a problem that plagued previous attempts to create digital assets. Because it is impossible to edit a blockchain once it has been properly updated, parties have mathematically-enforced confidence that the record of their ownership will persist into the future.

Emerging solutions

While the technology is still in early stages, many now believe that if blockchains can create a secure platform for the trade of digital assets, they may also solve the two fundamental challenges facing smart contracts.

First, smart contracts require a way for computer code to control real assets. By enabling fully digitized assets, blockchains make it possible for code to exercise control over property. On a blockchain, control over an asset means controlling a cryptographic key that corresponds to the asset in question, rather than any physical object.

Thus in our example above, the options contract could itself have control of the underlying assets, rather than an escrow agent. When the "exercise" function is called, the operation of the code would transfer the assets without requiring any human assistance.

Second, smart contracts need a "trusted computer" that would execute the terms of the contract. This is the blockchain itself. The blockchains that are being developed today are not only databases, but distributed computers that can execute code as well as record ownership of assets.

Our “smart option” example would itself be uploaded and stored on a blockchain, and would be executed by the blockchain when instructed to do so.

The same properties that make blockchains ideal to record ownership of assets also make them ideal for executing smart contracts. Once the code of the contract is uploaded and recorded onto the blockchain, the parties can have confidence that the contract cannot be altered, and that it will perform as expected.

Current work

Blockchain smart contracts may not be as far away as we expect. Banks, exchanges, and other financial institutions are actively developing blockchain technologies that will enable them to store and trade real assets over blockchain systems. Nasdaq, in partnership with blockchain startup Chain, has developed and begun testing a private-market equity trading platform.

A next-generation open-source blockchain called Ethereum aims to be the foundation for a new industry of non-traditional decentralized commerce. A consortium of 43 banks, working with blockchain firm R3, have begun work on a shared industry platform based on blockchain technology specifically designed to facilitate financial agreements. Within a few years, financial markets may be trading fully-digital assets across blockchain networks, with the terms of those trades enforced by code.

The impact will not be limited to financial contracts, although these are the most obvious use cases. As techniques are developed that enable other types of property to be recorded and transacted on a blockchain, the possible applications for smart contracts will multiply.

If they ever become widely used, smart contracts could alter the nature of corporate and commercial transactions. The advantages of software that have revolutionized so many industries – automation, predictability and speed – could finally be brought to bear on segments of the legal industry.

Representing contractual terms in code, rather than natural language, could bring clarity and predictability to agreements. A smart contract could be tested against any set of inputs – in other words, against any set of material facts which it takes as inputs - allowing lawyers on either side of a deal to know precisely how the contract would execute in every computationally-possible outcome.

In our simple Smart Option example above, each of Alice and Bob could "dry run" the contract in a simulated environment, where every possible input is tested. While this is unnecessary in such a simple example, imagine a contract with thousands of inputs, and hundreds of nested if-then statements – as is common in many complex financial agreements.

These, too, could be tested against every possible input defined in the code. Analogous to how software developers “debug” their own code by testing it in every possible circumstance, lawyers could test contracts, giving each side of a deal a clearer understanding of their risk – and perhaps requiring fewer billable hours.

Alternatives, not replacement

Of course, smart contracts will never fully replace natural-language law. Many types of agreements can never be fully expressed in code or executed by a computer – for instance, those that involve human performance rather than the exchange of dematerialized assets.

Even fully self-executing contracts will ultimately need to make reference to legal terms and concepts that will define each party’s rights if their relationship leads to litigation. Rather, the emergence of smart contracts will lead to a re-evaluation of common practice, as lawyers and clients alike discover which types of agreements and terms are best suited to code, which should be left to natural language, and how to combine each to achieve the best of both worlds.

For now, smart contracts are still science fiction. But for the first time we have a technology that could be used to bring them into commercial use. While that day may still be years away, legal professionals would be wise to consider how these innovations could impact their business.

© 2017