A Legislative Definition of Blockchain

October 13, 2016 By Josh Rosenblatt, Courtney Rogers

It seems like everyone is discussing “blockchain,” but few have taken the time to really define what blockchain is (and is not). In particular, the federal government has not reached a consensus on what the term should mean. This Thursday, a group of blockchain experts from academia, private practice, and government relations are sitting down together to do just that—define “blockchain” – at the Blockchain Definition on Capitol Hill event, hosted by MIT Media Lab, Congressman David Schweikert, the Chamber of Digital Commerce, and the DC Blockchain Center.   This article proposes one such definition, which I will be submitting for discussion at the event.

Goals of a Definition

Before parsing words, the goal of the definition has to be determined. Should the definition be broad and run the risk of including some “blockchain-like” systems that arguably should not be included? Or should it be narrowly focused so that only certain, known types of blockchain are included, creating space for blockchain operators to avoid government purview by tweaking their structure.

The greatest risk is defining “blockchain” in a way that forces its development to adapt to poorly written legislation, as opposed to the legislation adapting to the needs of the users of blockchains.  A broad definition, with enumerated exemptions, best accomplishes that goal.

Because no one knows exactly where the technology will go, it seems the safest bet would be a broad definition.

Broad Definitions with Exemptions

The government has often taken a broad approach to new concepts, which allows for greater flexibility in enforcement, and, as concepts firm up, exemptions can be added to narrow the number of entities covered.  Two laws that take this broad approach come to mind: the Stark law and the money transmitter definition.      

Another feature of the money transmitter definition is whether a person is a “money transmitter” is a matter of “facts and circumstances.” Essentially, that means is that the government reserves the right to review each application to determine whether it is covered by the definition.  That strategy might be a good one for blockchain. The technology is new and evolving quickly. Who can guarantee that today’s blockchain will look substantially similar to a blockchain five, ten, or fifty years from now?

A Critical Assumption

Laws, essentially, govern how parties act toward one another. The ability to “trustlessly” share data between multiple parties is what makes blockchain so interesting. Thus, any definition of blockchain should focus on the data sharing aspects of blockchain among multiple parties with disparate interests.

The Definition

With this combination of goals, definitional trends, flexibility of definition, and the assumption that only blockchains affecting third parties with disparate interests need to be regulated, a proposed legal definition for blockchain is:

1)      Definition:

a)      A blockchain is an electronic distributed[1] store of data utilized by multiple unaffiliated[2] parties.

b)      Whether a “store of data” is a blockchain is a matter of facts and circumstances. Generally, if a store of data maintains a decentralized continuously growing list of records stored cryptographically, such as by a hashing process, it is a blockchain.

2)      Exceptions: for the purposes of this definition, a blockchain is not:

a)      A store of data where only one party or multiple affiliated parties have the ability to control which parties can add, delete or modify the data. 

b)      A store of data which is retained on systems exclusively controlled by only one party or multiple affiliated parties.

“Store of Data” versus “Database”

Many articles refer to blockchain as databases, and that is not necessarily incorrect. Blockchains can store data, or they can store references to other data. In this way, they are like databases, but databases often include more features, such as the ability to query information.  Thus, to keep the definition broad, “store of data” is preferred to “databases.”


The exceptions are the most interesting part of the definition because they determined whether a concept should be legislated at all.  One crucial question is “who controls the blockchain”. If only one party (or affiliated parties) control the blockchain, it should not be covered in the definition of a blockchain. Many blockchains will be utilized in private, intra-firm environments—scenarios where regulation is can hopefully be avoided. Thus, those situations are exempt from this definition. 

The second exemption goes to where blockchains are located. Blockchains are often thought of as decentralized, but they need not be. A blockchain could, ostensibly, live in only one location (or more likely, multiple locations that reside on the systems of one entity affiliated with the other entities). In that situation, the owner of the system on which the blockchain resides exercises “control” of it by conditioning or terminating access to the data. This control exists regardless of which entity controls the ability to read or write on the blockchain. 

Definitions in Action: The Hypothetical

Assume you had unaffiliated Entity A and Entity B working through Consortium C to create a two-entity record for the settlement of funds between the two entities in an industry that requires a high level of systems security. Entity A and Entity B own an interest in Consortium C.[3] Should they be regulated by a hypothetical law that requires stringent security standards be applied to blockchains? Are they under the above definition?

As with all good legal analysis, the answer is “it depends:”

[1] “Distributed” and “store of data” should be further defined, but for simplicity’s sake we decline to do so here.

[2] For this definition, “affiliate” has the same meaning as set forth in Rule 405 of the Securities Act: “a person or entity that directly or indirectly controls, is controlled by, or is under common control with, another person or entity.”

[3] Many examples might use banks, but that invokes the image of banks storing customer payment data. And customer data creates additional wrinkles to be discussed another day. For this example, let’s simply assume the data is confidential company data.]