A Standard of Professional Attention for Data Security

Better than a Checklist of Minimum Requirements


By what legal standard should the holder of PII be held? PII means personally identifiable information like social security numbers and medical information.
I argue the standard should be this: A data holder must have an on-going process for devoting professional attention to security.

Under this standard, a sizable data holder like a hospital or a retail chain deploys a team of professionals to work all the time, every day. Any legal review of the data holder is an enormous amount of work . . . an utterly massive amount of work. Under this standard courts, insurers or regulatory authorities must undertake an exhausting analysis to conclude whether a data holder met the standard.

“Minimum Technical Requirements” Is a Common But Flawed Standard.


But the professional attention standard that I advocate is not universally acknowledged by authorities.

Instead, a commonly-articulated standard is that the data holder must achieve some “minimum requirements.” Those minimum requirements amount to a checklist of specific technical measures the data holder must take. The authority promoting the minimum requirements argues that each and every requirement is easy to do, so failure to do any one of them merits some kind of penalty.

Here are two examples of a legal authority arguing that a data holder failed to meet minimum, easy requirements for data security:

One: Cyber-insurer Denies Coverage Because Hospital Failed to Do Everything on Minimum Checklist. 


In Columbia Casualty Company vs. Cottage Health System a hospital had paid for cyber insurance. Then a breach happened. The insurer sued the hospital, seeking to deny coverage because – in good part – the hospital failed to satisfy some specific minimum requirements like installing patches on servers.

Two: FTC Says Medical Laboratory Violated Law Because It Missed Some Specific Checklist Points. 


The Federal Trade Commission is locked in an epic struggle against the victim of a cyber attack, LabMD. In this proceeding FTC’s lawyers maintain that LabMD violated data security law because LabMD failed to implement specific low-cost checklist items, such as adoption of written security policy (which is different from an unwritten policy), formal training of employees, destruction of data on people for whom no healthcare was performed and failure to update operating system.

See Footnotes 5-14 and accompanying text, Complaint Counsel’s Opposition to Respondent’s Motion to Dismiss. Public Document Number 9357, filed May 6, 2015.

It is important to observe that FTC’s lawyers give no credit to LabMD for what it did right; LabMD did in fact have a substantial, on-going InfoSec program. But FTC’s lawyers simplistically say: You missed some specific technical points in our checklist; therefore, you violated the law. No deeper analysis is necessary.

The Minimum Requirements Checklist Does Not Align with Reality.


The minimum requirements approach is easy for an authority like FTC to enforce. An audit will always find that a data holder did not meet some specific minimum requirement. That is reality. So any time the FTC looks, it will find that the data holder failed to meet this requirement or that requirement, even if the data holder maintained a substantial, professional, good faith InfoSec process.

But the minimum requirements approach is ineffective.

Every day, major data breaches happens. The reason is that data security is astonishingly hard to achieve in a functioning organization. As I write this post today, the big breach in the news is US Office of Personnel Management. Breaches are routine. Breaches are normal.

According to InfoSec pundit Bruce Schneier:

“In general, it is far easier to attack a network than it is to defend the same network. This isn’t a statement about willpower or budget; it’s a statement about how computer and network security work today. A former NSA deputy director recently said [link omitted] that if we were to score cyber the way we score soccer, the tally would be 462456 twenty minutes into the game. In other words, it’s all offense and no defense. … In this kind of environment we simply have to assume that even our classified networks have been penetrated.”

In practice, achieving all of the minimum, low-cost requirements – 24 hours a day, 365 days a year -- is exceedingly hard to do. Each little requirement viewed in isolation might be “low cost,” but collectively they are not low cost. More importantly, striving for minimum requirements is not the most effective approach to security. As a multitude of institutions have proven, the data holder can invest great resources in security and still be breached.

InfoSec is a fierce competition, and you might not win that competition even if you work hard at it. Like a rugby game, security invariably involves tradeoffs, judgment calls and good faith mistakes.
Cyber Defense as competition.
Even “easy” measures might not make sense on account of such things as compensating controls, prioritization of attention, rapidly-changing threats and technology, disruption caused by “patches” or the operational needs of the data holder.

The Better Standard Is Professional Attention.


So the better standard is not that the data holder meet specific minimum requirements on a checklist. The better standard is that the data holder maintain a professional program to attend to security.

To understand that standard, let’s look at an example. A hospital (Massachusetts Ear and Eye Infirmary) lost a laptop containing patient data. The Department of Health and Human Services investigated. HHS concluded that the hospital violated HIPAA data security requirements and imposed a $1.5 million fine.

But the analysis by HHS was telling. HHS emphasized the violation and fine were not about a specific security measure, i.e., encryption on a laptop. HHS did not say, "Encryption is easy. You did not encrypt. Therefore you broke the law."

Instead, said HHS, the violation was that the hospital failed over time to maintain an effective, on-going process for evaluating the security of portable devices and responding to that evaluation. See Resolution Agreement September 13, 2012.

Perfection in Information Security Will Never Be Achieved.


If data holders like hospitals must achieve perfect minimum data security – if they must always meet all the “low-cost” measures that can be dreamed up -- then they should cease operating. They will never get to legal compliance, and they will owe infinite fines and infinite compensation to victims like patients. That outcome is absurd.

A better approach is to motivate data holders to maintain a process, a responsible on-going program. It is like motivating a sports team to train rigorously and do its best on the field.

That approach includes recognizing that oftentimes organizations with good programs will be breached. Organizations with good programs should be rewarded for having the programs. They should be spared penalty when a breach happens.

Sports teams should be cheered for playing hard, even when they lose.

--Benjamin Wright

Disclosure: Mr. Wright has performed work for LabMD.

eDiscovery: Opportunities for Creative Thinking by IT Professionals

Deep knowledge of technology is critical to winning modern lawsuits. When an enterprise is in litigation, the legal team needs advice and ideas from IT staff and other forensic experts.

Discovery of Records Resolves Lawsuits

Consider in particular the discovery phase of a commercial lawsuit.  The lawyers representing an enterprise wish to request, through the rules of discovery in litigation, that the adversary turn over records that are relevant to the lawsuit. The adversary’s records can help to resolve the lawsuit.

Fishing Expedition Not Tolerated

But under the rules, the lawyers must have some reason to believe that specific kinds of records exist in order to ask for them. The lawyers can’t simply ask that the adversary rummage through all of its digital stuff – all email, text messages, files, folders, images, metadata, tapes, hard drives, backup, cloud-computing accounts and on and on -- and turn over “all relevant records.” Such a request would be an open-ended fishing expedition,  which the court will not tolerate. Such a request would be far too broad and therefore not enforceable.

So the lawyers face a chicken-and-egg paradox. They want the adversary’s records, and they are entitled to get some of those records. But if they don’t know which specific kinds records the adversary might have, then they don’t possess the technical knowledge necessary to frame a request for them.

The Internet of Things Is an eDiscovery Bonanza


Enter the Internet of Things.
forensics
Evidence from Small Connected Devices
New technology – like smartphones, smart-watches and smart-grid power meters – begets prodigious quantities of heretofore unimaginable records. The records can show, for instance, who was at a certain place at a certain time or when a particular event occurred in a work room. The technology changes and advances constantly. Many new and surprising kinds of records – records that could be very impactful in a lawsuit – emerge every day.

A Demonstration from Investigative Journalism

Here’s an example of how new technology breeds surprisingly influential new records and evidence. News media investigated the spending habits of former Congressman Aaron Schock. Congressman Schock relished using social media to tell the world what he was doing all the time. But unbeknownst to him, he was telegraphing little clues – little records – about himself that would prove to be embarrassing.

Schock published Instagram photos that included time and geolocation data.
investigation
Geographic Location on Photograph
The ever-watchful Associated Press matched this data with his official (publicly available) expense reports. The AP deduced, for instance, that he illicitly rented a private jet, at taxpayer expense, for his transportation connected with a particular fundraising event in Peoria, Illinois. Ouch.

As an investigative journalist, AP published its analysis and concluded that Schock was abusing his travel expense budget. This and similar revelations contributed to Schock’s resignation.

Now Let’s Apply that Example to Litigation

Just as digital details like geolocation data can help the news media scrutinize spending by a politician, they can be decisive in a commercial lawsuit. But often the lawyers handling a lawsuit need help from people with technical expertise. Lawyers may not realize that, for example, if a video is stored in Sharepoint at an adversary enterprise, then Sharepoint may store reliable metadata about the date of the video and the dates of each revision to that video.

Very often, under the rules of discovery, the lawyer’s request for something like Sharepoint metadata must be predicated on more than a mere guess that “some kind of meta data somewhere exists with respect to the video in question.” In their eDiscovery request for records from the adversary, the lawyers need to refer to some empirical evidence that Sharepoint metadata would be relevant to the case at hand.

That’s precisely where an alert IT staffer can add value. If the staffer understands the details of the case, he or she may be able to divine that the adversary was using Sharepoint to store a video. Further, the staffer might know enough about Sharepoint (or be able to learn through quick research) to advise the lawyers they should target Sharepoint metadata in their eDiscovery request. That kind of advice can make or break a case!

IT Experts: You Should Be Inspired and Empowered  

A person with technical knowledge should be inspired to be creative … and to think outside their normal roles … to help their legal team to discern and articulate that the adversary possesses unconventional records that should be produced.

By Benjamin Wright


What is Best Practice for Government Email Retention Policy?

Central archive promotes internal control, deters corruption.

Enterprises like businesses and government entities should generously retain the email of important employees in a central archive. A central archive is controlled by the IT department, not the employees whose email is in the archive. Such an archive ensures records are conveniently available and searchable for audit, e-discovery and internal investigations.

IRS investigation nightmare proves the need for a central archive.


The current poster child in favor of central archives is the Internal Revenue Service. IRS is currently enduring a nightmare owing to its failure to archive employee email centrally. This nightmare is not over. But it has transpired enough to teach painful, timeless lessons.

The nightmare in question is the investigation into the emails of an IRS executive named Lois Lerner. Lerner headed an IRS division handling sensitive tasks (evaluating the tax status of nonprofits).

The Inspector General at IRS recently opened a criminal investigation into whether one or more employees at IRS attempted to destroy or hide Lerner’s emails (that is, government records).   If an employee did that, the employee could go to jail.

Scandals often hinge on electronic mail.

Here’s the story. A political controversy erupted over Lerner’s work. Congress demanded her emails. (Logically, emails are a very relevant thing for an investigator or legal adversary to demand in today’s age. In modern enterprises, emails record most of the action by managers and executives.)

Astonishingly, IRS replied to Congress that all of Lerner’s emails had been destroyed because the hard drive on her single laptop had crashed. What?!

Furthermore the Commissioner of the IRS (its top executive) testified to Congress that Lerner’s emails were irretrievable . . . could not be recovered by any means. What?!

A manager’s emails need to be archived and segregated from the manager.
In effect IRS was saying that its IT systems were designed so that the retention of many important emails depended upon the function of a single PC hard drive. That’s nuts . . . for two reasons.

First, PC hard drives commonly fail; important records like management emails need to be copied some other place. Reliance on a single PC hard drive constitutes gross mismanagement.
electronic mail archive
PC hard drives can fail.

Second, if sensitive records are stockpiled in a single place under the control of a single employee, then that employee has the ability to destroy her records. She has the ability to cover up her own wrongdoing in the event of an investigation into her performance or malfeasance.

What’s more, it strains credulity for an enterprise to say that large numbers of emails of an executive are irretrievable, even after a hard drive has crashed. Copies of those emails are likely scattered far, wide and deep, especially in backups and on servers.

And in fact, when the IG investigated, that’s what IG discovered. Lots of Lerner’s emails are on backup tapes and (potentially) on server hard drives.   Recovering all this is much work. But it can be done by patient, well-resourced investigators.

The emails were not "irretrievable" as the IRS Commissioner had testified to Congress. One can't expect the IRS Commissioner to be an expert on computers and records. Obviously he has to base his testimony on advice from other people. And obviously he got horrible advice, in good part because IRS had failed to archive Lerner's emails in a centralized, competent archive.

IRS could have avoided this embarrassment.


For IRS as an enterprise, this investigation is becoming a long, expensive and embarrassing saga. A protracted criminal investigation like this can be very damaging to the reputation of the enterprise and to overall employee morale, even if the investigation concludes that no crimes were committed.

An enterprise like IRS is wiser to archive email centrally, under the control of the IT department and outside the control of individual employees. If IRS had at the outset archived Lois Lerner’s emails in a centrally-controlled appliance, they would not have (seemingly) disappeared and the IRS would be spared from this debilitating forensic investigation.

By Benjamin Wright

Legal Training for New CISSP Exam | CPE Too

The information security world is in turmoil. For infosec professionals, the adoption of smart legal practices is becoming more urgent.

Keeping with the times, the CISSP exam -- and related CPE requirements -- are being refreshed as of April 15, 2015. (CISSP stands for Certified Information Systems Security Professional.)

Cyber Threats Rise


The refresh reflects the alarming new reality of information security around the globe. 2014 was a banner year for data breaches and cyber attacks: Home Depot, Sony Pictures Entertainment, Community Health Systems, et al. And already for 2015 we’ve seen records breached for 80 million people at health insurer Anthem.
confidentiality
Privacy Law
As a consequence of this bad news, lawsuits are becoming more common and government audits & investigations are becoming more intrusive. For example, in the wake of the Sony Pictures attack, former employees of Sony have sued the company for allowing their personal information to be exposed.

CISSP Exam Covers Legal Issues


In this context the CISSP exam is changing. Among the topics in the exam are:

  • Law
  • Compliance
  • Regulations
  • Privacy
  • Policy
  • Investigations
  • Evidence
  • Ethics

These are all topics I address in a five-day bootcamp, “Law of Data Security and Investigations,” taught at the SANS Institute. SANS and I have been delivering and updating this course – known as LEGAL 523 --for many years. This course has served many hundreds of students from around the world.

Like the CISSP exam, the course embraces both old (timeless) lessons and new lessons. Through the years, the process of teaching the class -- engaging with smart students -- has improved my understanding of the topic; it has helped me refine the material, iteration after iteration.

LEGAL 523 is unique in the world. I am aware of no other course that seriously competes with it. It is taught by a practicing lawyer, who has years of experience. He devotes his professional life to keeping up with latest developments, such as New Jersey’s new law S.562 that (more or less) requires health insurers to encrypt personally identifiable information.

SANS LEGAL 523 | Law of Data Security and Investigations

By Benjamin Wright


Note: LEGAL 523 is not a cram course for the CISSP exam. It aims to teach all professionals (CISSPs, lawyers, auditors, investigators, penetration testers, managers and others) how to cope with the most pressing legal risks in data security and data investigations.

Blockchain Smart Contracts | Fraud, Taxes & Evidence

The Case for Supporting Automated Contracts with Traditional Legal and Audit Documentation


Blockchain enthusiasts envision smart contracts, where assets and transactions are governed on the type of shared ledger that controls Bitcoin.

Here is an example of a “smart contract:” Alice, Inc. earns bitcoin by mining. Alice controls a bitcoin account to which earned bitcoin is added from time to time. Alice, Inc. promises to pay Bob Corp. 25% of the bitcoin added to the account each week. (Assume the value to be paid Bob is around $250,000 per year.) Alice management sets up this transaction by adopting rules on a functioning, publicly-accessible Ethereum-based blockchain. The functions of the blockchain automatically execute the transaction and cause the requisite bitcoin to move from Alice’s account to Bob’s bitcoin account.

The transaction is functionally complete, but poorly documented.


In principle, this transaction is functionally complete. In principle the code on the blockchain could control and execute the transaction as intended by Alice and Bob.
Crypto 2.0 Needs Scrivener

However, I argue that for many businesses like Alice, Inc. the transaction needs more legal and audit documentation. The establishment of rules on a public blockchain ledger may not be enough to satisfy Alice, Inc.’s responsibilities to stakeholders, including shareholders, creditors and tax authorities.

Now, management at Alice, Inc. might disagree with me. Management might argue that by setting up the transaction on the blockchain it has undertaken and documented a transaction that is just as legally-binding as a promise made with paper and ink. The blockchain is open for public inspection. Anyone can inspect the function of the blockchain and the open-source code that runs it.  Anyone can monitor the transactions recorded and executed on the blockchain. The transactions are executed under publicly-known, publicly-validated cryptographic security measures, including hash algorithms and digital signatures.

Accordingly, argues management, even if the smart contract does not execute, Bob Corp. can still refer to the code recorded in the blockchain as evidence of the intent of the contract and thereby enforce the contract in a court of law just as if it were written in ink on paper.

Judicial cases support the proposition that a smart contract could be enforced in court.


In support of its position Alice management might cite case law interpreting security measures instituted with respect to property such as land. Courts have long evaluated the “security measures” instituted on land to ascertain whether rights of ownership to land have changed by way of “adverse possession.” Those security measures have included gates, locks, fences and the like.

So, for example, a New Mexico court said that adverse possession of land could be interpreted from the history of locks used on a gate that controlled access to the land. Dethlefsen v. Weddle, Opinion Number: 2012-NMCA-077, New Mexico Court of Appeals, 2012.

Similarly Mississippi courts have said that adverse possession of a parcel of land could be interpreted by examining fences on the land, including their location, history and purpose.

To understand evidence of security measures, a court may need to hear testimony from witnesses, such as people who understand the land in question.

In other words courts have much experience examining publicly gatherable evidence of security measures used to control property and then interpreting that evidence as a record of the rights and ownership pertaining to the property. Another way to say it is that the function of fences, gates and locks is a form of language, and with enough effort a court can come to understand that language.

Courts can interpret security measures, just as they can interpret words written on paper.

If courts can do that for land, argues Alice Inc.’s management, then courts can do it for logical evidence that can be seen by all on a blockchain. Just as courts can hear testimony from witnesses who know land, courts can hear testimony from cryptographic experts who understand blockchains.

In theory, if the blockchain stopped functioning, and Alice otherwise refused to transfer the bitcoin to Bob Corp., Bob could sue for breach of contract and win a judgment against Alice. With the help of qualified witnesses, Bob could prove the existence and meaning of the smart contract by referring to the code and security measures used in the blockchain.

A contract need not be written in natural language in order for a court to understand it or enforce it. So argues management at Alice, Inc., who believes no additional documentation is necessary.

Good business documentation seeks more than just enforceability in court.


But I have a rebuttal to the foregoing argument by management at Alice, Inc. Just because a contract is legally enforceable does not mean it is documented well enough for accounting purposes.

Alice’s management may be correct that the smart contract is written, recorded, understandable and enforceable.

Nonetheless, Alice, Inc. still has problems with this transaction. Good business practices expect businesses to better document substantial transactions like a promise to transfer roughly $250,000 in value per year.

A promissory note is greater documentation than is a mere notation in a ledger.
A business like Alice, Inc. needs to account to stakeholders. One example of a stakeholder might be a bank that has lent money to Alice and expects Alice to repay the loan and otherwise maintain a strong balance sheet. Another example of a stakeholder would be a shareholder. If Alice is a larger business, it could well have numerous shareholders, including founders (and their heirs and family members) angel investors, venture capitalists and employees.

Promissory Note to Support Autonomous Contract

Critical to a business’ accounting to stakeholders is its maintenance of books, ledgers and documentation to show revenue, expenses, assets, liabilities and so on. Those books, ledgers and documentation enable a third-party auditor to review and opine on the financial statements the business provides to stakeholders.

But if Alice’s evidence for its obligation to Bob is just the entries on a public blockchain, that evidence may not satisfy the auditor. The auditor may lack the expertise to interpret the blockchain. Blockchain technology is very new and very complex. Few accountants in the world are today qualified to review a blockchain.

Alice’s auditor may refuse to approve Alice’s financial statements . . . or may flag the poorly-documented contract as a problem.

Famous court case calls for backup documentation.


An instructive court case is SEC v. World-Wide Coin Investments, 567 F.Supp. 724 (N.D. Ga. 1983). World-Wide Coin was a small, publicly-owned company. It was subject to the US securities laws, including the requirement that it “make and keep books, records, and accounts, which, in reasonable detail, accurately and fairly reflect the transactions and dispositions of assets of the” company. 15 USC § 78m(b)(2)(A). The court found that the company had failed to satisfy that requirement for records. Among many other recordkeeping defects, the court found: “no promissory notes or other supporting documentation has been prepared to evidence purported loans to World-Wide.”

In other words, at this company obligations to pay money (repay loans) were supported by only sketchy notations and/or memories stored in the heads of staff members. But the court said that’s not good enough to serve the interests of stakeholders (even though the people to whom money was owed were not complaining). Sketchy notations and human memories are inadequate to constitute “reasonable records.” Obligations to pay money need to be documented by written evidence like promissory notes or contracts.

Outside auditors demand good documentation.


Let’s apply the World-Wide Coin lesson back to Alice, Inc. Its outside auditor will expect Alice to have reasonable records of obligations. (Further, under general corporate law Alice’s creditors and shareholders also expect Alice to maintain reasonable records of obligations.) Those records give the auditor comfort that the financial ledgers shown to the auditor are in fact accurate.

If the auditor is uncomfortable with the quality of Alice’s documentation, the auditor could point to the World-Wide Coin case for the proposition that Alice is deficient (even if Alice is not a publicly-owned company that must comply with the securities laws like 15 USC § 78m(b)(2)(A)).

In the mind of the outside auditor, deficient documentation of transactions could be a symptom of deeper problems at Alice. 
  • One problem could simply be sloppiness such that Alice – innocently, naively -- does not understand its obligations and therefore is incompetent to account for its financial status.
  • A second, more sinister, problem could be that management at Alice is intentionally obscuring the company’s financial condition for the purpose of fraud. The poster child for this problem is Bernard “Bernie” Madoff, one of the most infamous of all financial crooks. He and the staff at his company deliberately maintained sketchy or nonexistent documentation of contracts and other transactions in order to hide the company’s true condition from auditors, investors and regulators. 

Tax authorities demand good documentation.


In regards to Alice, Inc.’s accounting documentation, another stakeholder is a tax authority. If Alice is a US company it must pay federal income tax. Alice will likely try to reduce its tax liability by claiming the transfers of bitcoin to Bob Corp. reduced Alice’s income.

In support of Alice’s claim, the Internal Revenue Service expects Alice to keep adequate records and documentation. The records and documentation enable IRS auditors to confirm Alice’s annual income.

Section 6001 of the Internal Revenue Code requires each taxpayer to keep records necessary to show whether the taxpayer owes tax.

The taxpayer has the burden to prove the authenticity of its records. Gillespie v. Commissioner, 35 T.C.M. (CCH) 269 (1976).

Sometimes, owing to inadequate documentation of transactions, IRS disagrees with a business taxpayer’s calculation of tax. In Bard v. Commissioner, for example, the IRS disallowed deductions the taxpayer had taken for the costs of precious metals purchased in cash transactions. The taxpayer had documented the purchases with little more than a fragmentary telephone log kept in a looseleaf notebook, without numbered pages. Although the taxpayer appealed to the tax court, the court sided with the IRS. It sustained the disallowance of deductions, which increased the taxpayer’s tax liability considerably. 60 T.C.M (CCH) 485 (1990).

In theory a tax auditor can understand the smart contract on the blockchain. But in practice the tax auditor may consider the blockchain to be too obscure and therefore inadequate to support Alice’s tax claims.

Accordingly, Alice, Inc. may be saving itself heartache in a tax audit by supporting the smart contract, at the outset, with a traditional, written promissory note.

Why is a promissory note needed?


In all likelihood the code for a functioning smart contract will not include all the information that is critical from a legal or accounting perspective, such as the precise legal name of the parties (Alice, Inc. and Bob Corp.).

The process or drafting a promissory note or similar document – to stand along side a smart contract -- imposes intellectual and ethical rigor on business people and programmers who may otherwise be in a hurry. In my experience executives and coders can dash-off ideas and deals quickly, with little regard for the details that may not seem important at the time.

But those details are the domain of the scrivener (the document draftsman). The disciplined scrivener knows that a promise to pay needs to nail down topics such as the precise legal identity of the parties, whether the promise was made by an authorized officer of the promising company, whether the obligation to pay can be enforced in court (outside of the blockchain), and more.

Conclusion: Smart contracts and traditional documentation complement each other.


Smart contracts are good, and companies like Alice, Inc. should use them where they make sense. But substantial smart contracts need to be supported by traditional written documentation like paper contracts or promissory notes.
What do you think? If any of my ideas are off-target, please let me know.

By Benjamin Wright



Legal Terms for Crypto 2.0 Project

Generic Disclaimer of Liability


Ethereum’s Vitalik Buterin inspires me to offer a contribution to the cryptocurrency community (a.k.a. Crypto 2.0). Buterin observes how many different projects are underway within the community, working on cryptocurrencies, blockchains, smart contracts, distributed ledgers, decentralized consensus and the like. 

These projects include Bitcoin, myriad altcoins, Bitshares, Ethereum, Counterparty and others. More projects will come. 

Many of these projects are open source. Many of them celebrate their informality. Legal formalities were scarce when Satoshi Nakamoto launched Bitcoin.

Buterin recommends that the folks working in their different projects (he calls them “silos”) make their projects inter-operate, all for the greater good. Particular projects may come to specialize in offering browsers, blockchain services or decentralized applications (DApps) that can help other projects.

Generic Legal Terms


For such projects, here (tentatively) are legal terms to publish conspicuously to stakeholders.

Project Terms

1. This Project is built and used by a community of people from all over the world. 

2. The Project includes the data, work, ideas, protocols, software, processes and documentation that are contributed to it. Original contributions to the Project are open source and public domain forever. 

3. The Project is offered “as-is.” The Project, its contributors, leaders, promoters and users disclaim all liability and all warranties, whether express or implied. There is no assurance that the Project will be accurate or error free, will achieve any particular result or complies with any particular law or property right. You use, rely on or contribute to the Project at your own risk. 

4. The Project may discontinue or change at any time.  

5. If any portion of these Terms is held to be invalid or unenforceable, the remaining portions remain in full force and effect.
==

Analysis of the Terms


The foregoing is a generic form. It is short so that it is more likely to be read. It strives to cope with legal risk in furtherance of the project.

It condenses terms for services and terms for software into a single unified statement. For some projects the distinction between services and software makes little sense. In fact there may be no “service” per se. The project assembles software so that a freeform community of miners (workers or voters) can use it in a process to achieve a result, such as a consensus vote on what time it is or the execution of a transaction.

Yet, the project may be more than just software, which is the subject of a traditional open-source license.

Risk Begone!


One goal of these Terms is to reduce the potential (theoretical) liability of some project stakeholders to other stakeholders. Some malcontents may claim that others promised they'd get rich but the riches never materialized. The malcontents might try to sue in a court, or just complain in public.

The Terms above aim to curb the risk of liability on the part of any party. But it does not eliminate the risk.
electronic contract
Legal Notice

Property Ownership Might Be Disputed.


A second goal is to reduce the possibility of unexpected claims of ownership to something. But it does not eliminate the possibility.

The terms say, “Original contributions to the Project are open source and public domain forever.” That sentence does not guarantee that no one can claim ownership to something, such as ideas or code. It applies only to “original” contributions. So if Jane contributes proprietary code that was stolen from Phil, then that code would not be an original contribution. Phil might still claim ownership. 

Further, Nick might muddy the topic of ownership (of the code he contributes) by widely declaring: “The ‘open source and public domain’ terms of the Project do not apply to the code that I contribute. The code that I contribute is copyrighted and patented by me.” Nick's unruly declaration raises unsettling issues over how legal terms are negotiated in an online community.

Your Project May Need Something Different.


The generic Project Terms above are not customized for the needs of any particular project. Some projects will be wise to have different or additional terms. For example:
  • Certain terms that are specific to software, and other terms that are specific to services.
  • Reference to a particular license or terms, such as (for open-source software) the GNU General Public License.
  • Notice that the project uses technology such as a particular algorithm under a specified license.
  • More formality and detail to confirm that all contributions to the project and its software are open source and free.
  • Explicit limitation of liability to a certain amount. The Mozilla Public License (MPL) referenced below limits liability to $500.
  • Choice of law. The MPL chooses California law.

The Project Terms above are obviously for a free, open-source project. A proprietary project or a project that is charging fees may need different or additional terms. Appropriate terms might look like a license that commonly comes with proprietary software or a service agreement for paid services.

Disclaimer and Caution


Notice: This blog post is just public discussion. It is not legal advice for any particular situation, and I am not your lawyer. If you need legal advice, you should retain a lawyer.
public warning
Legal notice modifies risk because it warns people
before they take action that could cause them injury.

I am skeptical that the Project Terms above would protect someone such as a project leader who is intentionally deceiving people.

I consider the Project Terms I publish above to be in the public domain. You may use them any way you wish. But you are responsible, not me.

Feedback Invited


What do you think? I welcome discussion and feedback. I may revise the Terms above, so check back from time to time.


Footnote: The Project Terms published above are inspired by unlicense.org and these things connected with Mozilla Firefox: 

  • “About Your Rights,” accessible through Firefox address bar at “about:rights”
  • “Mozilla Firefox Web-Based Information Services,” accessible through Firefox address bar at “about:rights#webservices”
  • Mozilla Public License, Version 2.0

Smart Blockchain Contract Law

Many propose to use block-chain technology to make “smart contracts.” Examples include:

  • Blockstream, which proposes to run contracts off of “sidechains” to the Bitcoin blockchain;
  • Ethereum, which is a decentralized publishing platform for powering contracts; 
  • OpenBazaar, which proposes to be a decentralized market for using Bitcoin to make purchases

Some say that smart contracts are "trustless" transactions because they execute transparently without the need to trust any particular person or institution.

Some say this trustless transparency results from "decentralized consensus," where a community of "miners" makes each decision (to execute a transaction or not to execute a transaction) by way of consensus that is controlled by no one.

Bitcoin Succeeds.


These proposals are early in their development. They build on the pioneering success of Bitcoin.

Bitcoin is truly remarkable. It is the first distributed ledger to operate usefully and perpetually, independent of any central institution or sponsor. See my discussion of a distributed public ledger.

Proposals for smart contracts seek to launch distributed ledgers to execute transactions that are more complex than Bitcoin; Bitcoin  just keeps debits and credits of “coins.”

“I Hereby Bequeath My Bitcoin to My Kids.”


Here is an example of a complex smart transaction, as explained by Stephan Tual, CCO of Ethereum:  Stephan says he holds digital assets like bitcoin. He imagines setting up a commitment under an Ethereum-based blockchain for distributing his assets upon his death. To govern that commitment, he imagines these rules as his digital last will and testament:


  1. If Stephan does not appear on the Internet for three consecutive months, then
  2. His assets will be transferred to accounts belonging to his two designated heirs.
  3. The issue whether Stephen has failed to appear on the Internet for three months would be resolved by a vote among “miners” that maintain the Ethereum blockchain.
(A premise behind Stephan's will is that if he does not appear on the net for three months, then he "must be dead.")

Transaction Executes Automatically.


In theory a smart transaction -- in this case Stephan's last will and testament -- will execute automatically, without involvement of a court or government or central authority, just as a transfer of bitcoin executes today. I analyze Stephan's smart will below. But first, let me provide some background . . .

Smart transactions – smart contracts – might govern myriad different deals, such as escrows, stock sales, credit default swaps, last wills and testaments, and corporate governance through shareholders.

Some envision smart contracts without the need for lawyers.

The concept is admirable. As an e-commerce lawyer, I am eager to see it in action.

But I am skeptical that smart contracts and smart transactions can exist in a pristine universe, separate from traditional law, traditional legal analysis and traditional legal draftsmanship.

Law Does Apply to Blockchains.


An old saw holds that “law abhors a vacuum.” What that means is that law applies wherever it needs to apply. People cannot get away from law. They cannot declare themselves, their computers, their data, their assets, their transactions, their communications, or their blockchains as free from law (though they may influence which law applies and how it applies).

Accordingly, you can control some bitcoin, subject to the Bitcoin blockchain. And the Bitcoin blockchain operates without direction from government authority. But that does not mean law has no impact on your control of your bitcoin. So – for instance – if you got your bitcoin by running the illegal Silk Road market, then law can take your bitcoin from you and cause it to be sold, with the proceeds going to the government. Reference the experience of criminal suspect Ross Ulbricht.

open ledger
Blockchain

Legal Talent Needed.


Let’s go back to Stephan Tual’s last-will-and-testament example above. Experience has proven that writing, interpreting and executing a will can be tricky, just as writing, interpreting and executing a contract can be tricky.

Any person can write a legally-binding will or contract. You don’t have to be a lawyer to write these documents, whether you write them on paper, in software code or on stone tablets.

However, my experience is that some people are more skilled at writing such documents than others. Some lawyers are more skilled at it than other lawyers.

Legal training, legal analysis, and experience in the practice of law can all be helpful in composing wills, contracts and similar documents so that they achieve the desired outcomes. When you want to write a contract for the sale of widgets, you are not required to retain a lawyer to do the writing. You can do it yourself. However, you may get a better outcome if you do hire a lawyer who is qualified and talented at writing sales-of-widgets contracts.

How to Avoid Misunderstanding


Poorly conceived terms in a will or contract can be misinterpreted. They can be ambiguous. Or they can fail to anticipate contingencies that thwart the real intent of the document.

Here are examples of misinterpretations, contingencies or issues that might apply to Stephan Tual’s last-will-and-testament:


  • What happens if Stephan has not “appeared on the Internet for three months” because he is sick? He is still alive, and he may still need his digital assets. Why must they now go to his heirs?
  • What if Stephan has died, but someone has stolen his credentials and falsely appears on the Internet as him? (In this scenario, one can imagine a court stepping in and forcing the transfer of Stephen’s assets to his heirs, even though -- according to the evidence conveniently available to the Ethereum miners -- he still “appears” on the Internet.)
  • What if 17.5 years from now the “Internet” is replaced by something so strange and so unanticipated that the “miners” cannot interpret what it means to “not appear on the Internet for three months”? (To be fair, similar problems can bedevil traditional paper wills. A will that is well-written in 1998 may make no sense in 2015 owing to changed circumstances.)
  • What if someone tricked Stephan into approving an Ethereum last-will-and-testament that he did not understand or intend?
  • Might there be ways to structure Stephan’s last-will-and-testament so as to reduce the tax liability incurred by his heirs?
  • Think of the overhead cost of “miners” constantly monitoring the Internet, indefinitely, to evaluate and vote on whether Stephan has appeared somewhere over the past three months. Is it practical to expect that this overhead can be sustained for the next 40 years of Stephan’s life?
  • What if the Ethereum blockchain has long stopped functioning? Might a court still interpret and enforce Stephen's code as his last will and testament? (The answer might be yes, unless Stephan has explicitly stated otherwise. The court might consider his old code to be his "written and signed" will -- equal to a will he wrote and signed on paper -- even though it cannot be executed through the original blockchain.) 

Intended Terms Can Be Coded Into the Will or Contract.


A skilled lawyer – or other professional such as an accountant – could help Stephan understand these problems and address them. They might be addressed variously by way of
  • the coding behind his “smart will,”
  • the publication of special words/terms connected with his will (e.g., "This will is effective only if executed through XYZ blockchain. If XYZ blockchain ceases to function, then this code does not constitute my legally-binding last will and testament.")
  • the adoption of measures that address risk (e.g., the division of Stephan’s assets into multiple accounts, corporations or trusts), 
  • helping Stephan include a contingency for third-party arbitration, or
  • recommending that Stephan manage his assets a completely way.


All those things are the stock in trade of the traditional practice of law or accounting.


To Be Effective, Contract Practice Must Keep Up with Technology.


In a “smart transaction” environment, traditional legal analysis and legal draftsmanship will encounter new twists. The same happened when we moved from old-fashioned paper contracts to modern electronic contracts. For instance, the “battle of the forms” – under which contract terms and conditions are negotiated – can unfold differently over the Internet compared to how they unfold when people exchange paper documents via snail mail.

decentralized
Transparent Ledger

Therefore lawyers will need to acquire new skills to help clients compose and evaluate contracts for the smart, blockchain universe.

By: Benjamin Wright, Author, The Law of Electronic Commerce

How to Cope with Block Chain Legal Liability

Some institutions may hesitate to participate with a blockchain until they get assurance on potential liability.

Bitcoin Is Just One Example of an Explosive Idea.


Bitcoin’s blockchain is a specific example of a greater idea. It is a distributed ledger. A distributed ledger is a powerful innovation for accounting.
debit credit
Traditional Central Ledger
It replaces the traditional centralized ledger for keeping track of trades and ownership of assets, such as money, stocks, barter, commodities and more.

The centralized ledger requires a central authority like a bank to keep track of debits, credits or other matters of account.

In contrast, a distributed ledger manages debits and credits by community action. In Bitcoin, the members of this community, this “crowd,” are called miners. They perform calculations and confirm transactions publicly, such that all the participants can observe what is happening and verify accuracy.

The distributed system does not rely on a central authority, who can be corrupted.

Bitcoin’s blockchain is the first really successful application of a distributed ledger. But visionaries see much more for the future.

A Better Way to Administer Trust


In effect a distributed ledger is a method for managing trust among entities without requiring the entities constantly to check back with headquarters (the central authority) to confirm that an entity or party is entitled to a measure of trust. Checking back with headquarters for every transaction is inefficient.

Checking with the crowd that maintains the block chain (the miners) can be more efficient.

What is even more important is this: to corrupt a large crowd of miners is harder than to corrupt a central authority.

An Open Ledger Manages Trust.


Therefore IBM is exploring use of block chain to manage trust in the Internet of Things, where a multitude of devices (like your smart watch and your home thermostat) share data and responsibility with one another.

An example Internet-of-Things transaction might be the decision for a thermostat to trust an instruction from a certain smart watch to increase temperature by three degrees at 2:03 p.m. The confirmation of transactions might be distributed across a large and constantly evolving multitude of devices (a crowd). No single device is trusted too much. But the system can function if most of the devices are trustworthy most of the time.

Confirmation of any unit of trust [see footnote] comes from multiple miners in the crowd, but not necessarily all the miners.

Potential Liability for Errors or Omissions


Bitcoin’s block chain runs on open source software. Many people have contributed to its development and updating.

[Video above depicts action on Bitcoin's block chain through bitcointicker.co; video saluted by @BTCticker.]

Many distributed ledger projects will involve the collaborative efforts of many parties.

However, some institutions (like a large nonprofit foundation) will be concerned about the potential liability that comes from associating themselves with a block chain project. Their contribution might look like an endorsement or an acceptance of responsibility.

Block chains will not always work as expected. For instance, Bitcoin as originally designed has proven vulnerable to attack in that hackers can steal bitcoin from an individual trader if they can compromise the credentials for a trader’s single signature. For that reason Bitcoin is evolving to multiple-signature credentials.

In the future, as a new blockchain is created an institution that supports it would not want to be a “deep pocket” target for a lawsuit from someone who claims the block chain’s poor design caused damage. (Example case: member banks settle liability for actions of electronic mortgage clearinghouse.)

Warn Users of Risk.


For this reason institutions are wise to insist that the block chains they support come with disclaimers and/or terms of use. These types of statements can explain and disclaim risk.

For instance, something like the following statement might be published widely in connection with a block chain that manages ownership among stockholders of a corporation:

This block chain is offered "as-is" with no assurance of reliability. Use at your own risk. 

The statement might go on to explain with some detail the kinds of risks that are present, such as flaws in software or a future decrease in miner incentive to work.

A disclaimer is not a perfect shield from legal liability. It probably does not protect an institution from liability if the institution knowingly engaged in fraud. But a well-crafted disclaimer can dramatically reduce the risk of liability.

Example Disclaimers


Here are three examples of institutions insisting on the publication of disclaimers relative to their contributions to community projects.

  1. The payment card community works together to publish the Payment Card Industry Data Security Standard. The PCIDSS sets standards for securing credit card data. However, it is possible that a merchant who follows PCIDSS will still suffer a data breach. The institutions that participate in the PCI community and promote the PCIDSS desire no liability for a shortcoming in the standard. Their solution is to require anyone downloading a copy of the standard to agree to a contract that disclaims liability and places risk with the user merchant.
  2. The American Medical Association works with the National Supplier Clearinghouse to facilitate communications of Medicare claims by healthcare providers. However, the methods and technology of the Clearinghouse may not give a healthcare provider the desired outcome. AMA wants no liability. Therefore access to the Clearinghouse website requires the user to click on terms that disclaim liability by AMA.
  3. Ethereum.org publishes this statement regarding the initial sale of "Ether": 
Ether is a product, NOT a security or investment offering. Ether is simply a token useful for paying transaction fees or building or purchasing decentralized application services on the Ethereum platform; it does not give you voting rights over anything, and we make no guarantees of its future value.

What Stands in the Place of Legal Liability?


The user of a block chain that comes with a disclaimer might ask how he can get assurance if legal liability has been disclaimed. The answer is that the user can rely on “collective intelligence.” The user can observe the collective behavior of the community using the block chain to understand the risk associated with it. If a large and smart community is using the block chain in a transparent way, then the user can sense a measure of assurance, though he knows he probably cannot use the legal system to enforce that assurance.

Cyber Insurance Distributes Risk.


Another way to manage risk is to acquire insurance. Some block chains may require participants to pay a fee, part of which could goes to the purchase of cyber insurance to cover the participants for risk of loss.

Alternatively the terms of a block chain might require that each participant purchase certain insurance for itself and absolve all other participants of liability.

Hold Harmless Clause Assigns Risk and Incentives.


The absolution of liability might be worded different ways, depending on the needs and culture of the community. For instance, an absolution of liability might include:

  1. An indemnification clause in which each participant holds each other participant harmless from any claims based on the first participant’s reliance.
  2. A caveat that the absolution of liability does not apply to intentional fraud, which is proven beyond a reasonable doubt. Such a caveat sets up a high standard of evidence that a participant must meet in order to collect from others on account of their misdeeds.


By: Benjamin Wright

==

Footnote: The “unit of trust” might measure any number of things. In Bitcoin it measures a debit or credit of bitcoin. But the unit of trust could measure ownership of land or commodities. It could even measure community perception on whether an entity or individual professional is in compliance with law, ethical principles or industry standards.

Related:

  1. Declaration of entire crypto 2.0 project as "as-is" and "use at your own risk" 
  2. Recording Bitcoin Legal Evidence

Bitcoin Services Agreement | What Terms Should a Customer Demand?

Many wallets and platforms like Coinbase provide services to Bitcoin and other cryptocurrency customers. Typically a service provider requires customers to agree to the provider’s standard terms of service. And typically individual and small business customers lack leverage to negotiate these terms.

However, some customers do have leverage. Customers may have leverage because they bring a large volume of business to the provider, or they have teamed up with other customers to negotiate as a group. Alternatively they possess the patience to shop among service providers to find the most favorable legal terms.

What Terms Protect the Customer’s Interest?

The following are some (not all) of the terms that customers may desire but that are not commonly offered to small customers:

1. A Clear Statement of What Services Are Being Provided to the Customer


Technology services providers are known for being vague about what services they are providing the customer. Some Bitcoin service providers are equally vague. For example Coinbase’s standard User Agreement says, “Coinbase securely stores 100% of all bitcoin associated with your Coinbase Account in a combination of online and offline storage.” However, the agreement itself does not define “storage.”
bitcoin ownership
Legally, what does
"storage" of bitcoin entail?
It may be that here “storage” means Coinbase is managing the credentials that control the credit of bitcoin to the address pertaining to customer in the Bitcoin blockchain. But Coinbase’s Agreement does not say that. Further, it does not say the customer is entitled to those credentials and any value associated with them. It does not say that the Blockchain address belongs to customer.

What does the User Agreement say that the customer is entitled to? The User Agreement does little more than imply that all the customer is entitled to (at most) “FEES PAID TO COINBASE BY YOU IN THE PRECEDING THREE (3) MONTHS.” See Section 9.1. That’s it.

Coinbase’s User Agreement seems to say nothing about the customer being able to obtain the customer’s blockchain credentials or the blockchain credit pertaining to the customer. Maybe that is because the customer is not entitled to those things. But if that is the case, I’ll bet many customers would be surprised. The customer may think he has 10 bitcoin, but in fact all he has is the right to obtain from Coinbase a return the past three months of fees (at most). Those fees could be worth much less than 10 bitcoin.

2. Effort to Overcome Force Majeure


Service providers often insist on a “Force Majeure” clause in their agreements. And that may be fair as far as the customer is concerned.
Fire
What if fire strikes?
“Force Majeure” means superior force. Typically a Force Majeure clause says the service provider is excused from performing services in the face of a superior force such as war, natural disaster and the like.

video
However, the customer prefers that the Force Majeure clause not allow the provider simply to close shop in the event of adversity. For example if the customer is a merchant, and the service provider ceases operation on account of an earthquake, then the customer is in a lurch. So the customer wishes for the provider to work to overcome the adversity.

The customer might insist that the agreement provide:
  • the service provider will promptly notify the customer of the force majeure event and then regularly update the customer about the status of the event; and
  • the service provider will use commercially-reasonable efforts to overcome the event. (In other words the provider will take reasonable disaster recovery measures and will strive to return to normal service quickly.)

3. Response to Subpoena or Court Order for Information

The service provider holds sensitive information about the customer. That information might include address data, transaction history, blockchain credentials, investment details and more. The information might be relevant to divorce, tax collection, private lawsuits, bill collection, child support obligations and many other disputes.

Adversaries to the customer might try any number of legal means to get the information from service provider. They might try a civil subpoena, a tax summons, a police raid or a grand jury subpoena. An official order demanding information might issue from most any legal jurisdiction in the world (e.g., Uganda or Canada), regardless of the geographic location of the customer or the service provider.

The legal validity of a subpoena or other demand for information can be open to dispute. It is possible that an adversary would issue a subpoena that is unjustified or overly-broad. What is worse, sometimes Internet service providers (especially smaller ones that lack a large legal staff) can be overly generous in responding to a subpoena and turn over more information than is required. (See Theofel vs. Farey-Jones, 341 F.3d 978, 981 (9th Cir. 2003), in which an ISP disclosed too much of a business customer’s email to the customer’s lawsuit opponent.)

Accordingly, a customer desires terms like these: If someone makes a legal demand for records about the customer, then . . .


  • service provider will promptly give a copy of the demand to the customer. (Under rare circumstances the service provider is forbidden by law from informing the customer that US law enforcement is seeking information about the customer.)
  • service provider will wait to comply with the demand until the applicable deadline. Often a subpoena will give the service provider, say, two weeks to comply. If the service provider waits to the end of the two weeks, that gives the customer time to study the subpoena and react to it. The customer might for instance believe the subpoena is invalid or overly-broad; so the customer might appeal to a court to “quash” the subpoena or reduce its scope. (See details about quashing a subpoena in a US court.)


Similarly customer desires that service provider enter a non-disclosure agreement (“NDA”). Under common NDA terms the service provider would not disclose or use customer records without permission (except as required by law). The customer does not want the service provider to give customer’s information to customer’s competitors. Neither does the customer want service provider itself to use customer’s trading data to compete with customer.

4. Cooperation with Audits, Investigations or Requests for Information


Just as a customer is reluctant to let adversaries access the customer’s information held by the service provider, the customer desires assurance that the customer itself can access its own information and details about how transactions are processed.

A customer desires an agreement that under no circumstances will service provider:


  • place a lien on customer’s data [A lien is a legal measure that impairs a person's freedom to sell or transfer its property, such as its data.]; or
  • deny customer access to his/her data.


Sometimes technology service providers take the position that in a dispute with the customer, the provider can withhold data or deny service. For example the vendor of a cloud-based electronic patient record recently denied a medical practice in Maine access to its own patient records!

But from the perspective of the customer, the service provider holds unfair advantage if it can hold data hostage in the event of a dispute. The customer argues that if there is a dispute the service provider should not hold data hostage; instead, service provider can sue the customer and enforce the results of the lawsuit through normal legal procedures.

The customer may have both a commercial need and an ethical need to access its records. What would be an example of an “ethical” need for records? Suppose the customer was a law firm. The law firm might be controlling bitcoin on behalf of a client in settlement of a dispute. The law firm is obligated under its professional code of ethics to ensure it has access to the relevant records.

What’s more the customer may need assurance that the customer’s auditors can confirm and understand transactions. Relevant auditors might include financial auditors, tax auditors and security/internal control auditors. Hence the customer might insist that the service provider:


  • maintain adequate documentation about how its system works; and
  • cooperate with customer’s auditors.


For its part, service provider might insist that it be compensated if its staff must spend time responding to audit requests.

In regards to the security/internal control auditors looking out for the interests of customers: the service provider may find it is impractical to respond to all customer audit requests one-by-one. Therefore the service provider might itself hire a single auditor to conduct an audit for the benefit of all of its customers under a standard like Statement on Standards for Attestation Engagements (SSAE) No. 16 published by the American Institute of Certified Public Accountants (AICPA).

These Ideas Apply Beyond Cryptocurrencies.

The foregoing terms are not unique to Bitcoin. They might serve the needs of customers of many kinds of technology and e-commerce services.

If I’ve made any mistakes, please let me know so I can correct myself.

By: Benjamin Wright

[The foregoing is not legal advice for any particular situation. If you need legal advice, you should retain and consult a lawyer.]

Related:



How to Write, Interpret, Enforce a Contract for Bitcoin

Stated Terms and Conditions Influence Legal Result.

Suppose John offers to sell a valuable widget to Betty in exchange for Betty agreeing to “pay 5 bitcoin” and Betty accepts the offer. They agree by recorded audio:

 [In regards to audio contract, see footnote below.]

Then suppose John delivers the widget to Betty, but Betty fails to deliver the bitcoin.

What are John’s legal rights?

Mutual Consideration Supports Contract.


Under US law it appears John and Betty have formed a legally enforceable contract. The parties made mutual promises for valuable consideration. The widget is valuable, and the bitcoin is valuable under current market conditions.

But the novelty of Bitcoin could make the precise outcome of a lawsuit by John against Betty hard to predict.

The “Money” that Is Not Money.


Although some people use the word “currency” to describe the phenomenon popularly known as Bitcoin, Bitcoin might not actually be a “currency.”  Unlike dollars, it has not been deemed in US law as legal tender that can be used to extinguish a debt.

Further, the Internal Revenue Service views bitcoin as property – which is subject to capital gains taxes – rather than currency -- which normally is not subject to capital gains taxes.

What Are the Remedies for Breach of a Virtual Money Contract?


So if John sues Betty for breach of contract, it seems he could succeed in showing he is the victim of a breach and he is entitled to remedy under contract law.

But it could take some effort for a court to understand the contract.

Bitcoin is a specific example of a general idea. The general idea is trading by way of a distributed cryptographic ledger. In Bitcoin the distributed ledger is called the "block chain."

If a distributed ledger is competently designed and implemented, it inherently follows the rules programmed into its software. As people use the software, they adopt "customs" of trade that can be understood without a lot of explanation by contract for each trade. For example, by Bitcoin custom the term "to pay" five bitcoin arguably means to modify the block chain to indicate as follows:

1. debit five bitcoin from the payer's address identified in the block chain; and

2. credit five bitcoin to the payee’s address identified in the block chain.

Industry Custom May Resolve Some Ambiguity.


Thus, John and Betty’s contract say she will “pay” 5 bitcoin to John. The custom around Bitcoin suggests that Betty is required to interact with the block chain to debit 5 bitcoin relative to her address and credit 5 relative to his address.

However, bitcoin and similar technology are evolving so quickly that clear custom may not have had time to coalesce. A full review of the interaction with block chain around the world may show confusion or ambiguity about what is customary and what is not customary. (See story about a failed Bitcoin transaction.)

In contract practice, if there might be confusion about custom, the draftsman of the contract can employ words to reduce the confusion. He might for instance write out a long statement of steps that Betty will follow to cause and confirm a 5 bitcoin credit to appear relative to John’s address.

Alternatively, he might refer to an authoritative statement of Bitcoin custom. He might say in the contract, “This contract will be interpreted under Bitcoin custom as articulated in https://en.bitcoin.it/wiki/Main_Page ." That sentence might resolve many questions about custom, but probably not all questions.

What Should Happen in a Court of Law?


However, neither block chain software nor Bitcoin custom explain what should happen in a court of law if a party fails to execute a trade (e.g., Betty fails to “pay” the five bitcoin).

The software and the custom fail to explain what the consequences should be if Betty does not control the agreed amount of bitcoin at the time in question. Is she required to purchase five bitcoin and then transfer it to John?

Or can she satisfy her obligation by delivering to John a quantity of pork bellies (a valuable commodity) equal in value to five bitcoin? That particular outcome does not seem right because we have no evidence that John is easily able to accept pork bellies.

What Should Be the Remedy for Breach of Contract?


If a court forced Betty to render to John 5 bitcoin using the block chain process, that outcome could be called “specific performance” under contract law. Specific performance means Betty must literally do what the contract says.  But commonly US courts disfavor specific performance.

Specific performance requires the court to understand what is going on.

In order for a court clearly to understand specific performance in Bitcoin, the court might need to digest quite a bit of testimony from experts. The experts would have to explain to the court how the block chain works and so on. That would be a lot of work for the court.

Courts Prefer Money Judgment Rather Than Specific Performance.


Instead, a court is likely to prefer to give to John a “judgment” for an amount of legal-tender-money equal to the value that Betty failed to deliver to John. A judgment is a ruling that enables John to take legal action relative to Betty and her property.

This judgment is the contract law remedy for Betty's breach of contract; it is an official statement that Betty owes a debt to John.

This kind of remedy is called a “money judgment.” A money judgment is easier for a US court to understand and oversee.

In the US legal system, money judgments are rendered and enforced all the time. Our system has managed money judgments for centuries.

In contrast, to require Betty specifically to execute some performance relative to the so-called “block chain” would be – for a court – a new and complex exercise.

Money Judgment Means Greenback Dollars.


Typically, in a US court, the amount of money in a judgment would be stated in US dollars. If John does obtain a court judgment, he can use regular  court procedures to enforce the judgment. Enforcement can include an array of actions by John, including placing and foreclosing a lien on Betty’s property, like

  • her house, 
  • her car, 
  • her bank account which is denominated in dollars or euros, 
  • her pork bellies, 
  • her intellectual property such as a patent, . . . or 
  • (theoretically) her bitcoin.

But typically the calculation of satisfaction of the judgment would be made in dollars.
legal tender
Court Judgment
Calculated in US Dollars.

For example, if John’s judgment is in the amount of $2500, then the value of his lien on Betty’s house would be up to $2500. When Betty sells her house, John would be entitled to $2500 of the proceeds.

Typically Betty could satisfy the judgment by paying John the requisite number of dollars.

But What If John Wants Specific Performance?


Let’s say John is really serious, at the outset of the contract, about wanting 5 bitcoin, rather than dollars. He could write the contract to state in detail something like the following:

(A) Betty represents that she controls a Bitcoin address with at least 5 bitcoin of credit.

(B) Betty will execute specific steps to credit 5 bitcoin to the Bitcoin address identified by John.

(C) If Betty fails to follow the steps, then John “will suffer irreparably harm and significant injury the degree of which may be difficult to ascertain.”

(D) John is entitled to an order from court requiring Betty specifically to execute the steps articulated under (B) above.
bitcoin symbol

Written Contract Details Add Certainty.


The contract as stated in the audio above leaves open to interpretation questions like:

  • when Betty must pay the bitcoin;
  • whether interest will accumulate if Betty fails to pay on time;
  • which jurisdiction’s law governs the transaction (e.g., Texas . . . or Alberta);
  • whether the party enforcing the contract in court receives compensation for the cost of enforcement, such as attorneys’ fees;
  • how the widget will be tendered or delivered.


Details like these can be specified in a well-written contract, and can help John with his enforcement.

Analysis of Example Agreement


Let’s look at a well-known contract that refers to Bitcoin practice, Coinbase’s User Agreement. Coinbase is a well-known Bitcoin wallet and platform.

Section 2.4 of the agreement says,  “Coinbase securely stores 100% of all bitcoin associated with your Coinbase Account in a combination of online and offline storage.”

What does that sentence mean? The words “store” and “storage” are metaphors for complex, and possibly ambiguous ideas. They mean something other than simply:

(a) keeping physical objects in a three dimensional place (e.g., keeping in a box a sheet of paper bearing the words “one bitcoin”); or

(b) the retention of specific data that expresses bitcoin (Example: It’s not like storing the content of a distinct Excel spreadsheet – which says, “Ben has 6 bitcoin” -- on a hard drive.)

If a customer wanted to reduce the ambiguity of those words “store” and “storage,” then the customer could insist that the agreement provide much more detail. Alternatively the customer might insist that the agreement say that terms like “store” and “storage” will be interpreted under Bitcoin custom as articulated at a place like https://en.bitcoin.it/wiki/Main_Page .

So a general message to readers is that a contract for bitcoin can be written with details that help to reduce risk and misunderstanding. A talented draftsman uses judgment to know how much detail is enough and how much is too much.

This is an intriguing topic, and I’d like to talk about it. Please comment. If I’ve made any mistakes, please let me know.

By: Benjamin Wright

You might also like:



*Footnote: Under the Statute of Frauds, this contract might need to be evidenced by a “signed writing” to be enforceable. An audio recording can constitute a “signed writing.” Ellis Canning v. Bernstein, 348 F. Supp. 1212 (D. Colo. 1972).