Blockchain Legal Digest

The Source for Blockchain Legal News & Opinion

smart contracts

Understanding real contracts: a guide for smart contracts coders. Part 3: The Money.

By

Addressing money issues in smart contracts may be a challenge because subjective measures may play an important role. Money Photo Credit | License: CC BY 2.0

Editor’s Note: This is an installment of a series of articles providing background to smart contracts coders about how contracts work in real life. The articles reference this sample sales contract. This guide is intended for general informational purposes only. If you need legal advice about a specific situation, contact a lawyer.

The third part of a contract is what I call The Money section. It says how much is being paid, when it’s being paid and what conditions apply to payment. It’s Section 3 in the sample sales contract.

If you’re writing code for a smart contract, here’s where the magic should happen. It’s what’s going to lead to a few killer lines of code — the “if then” statement that is going to remove layers of back-office administration. This is what gets people jazzed about smart contracts.

But here’s where smart contracts become a little theoretical, particularly outside the realm of purely digital transactions. If you’re writing a contract for the delivery of 100 widgets — the kind of simple sales transaction that the sample contract is intended to cover — what is your trigger going to be for payment?

Will your trigger be a digital notice of delivery of the widgets from the shipper? That works if you’re writing a contract that is very favorable to the seller of the widgets because the seller would get paid even if the box only contains 80 widgets or the buyer ordered green widgets and the box contained 100 pink widgets. Fedex’s notice of completion of delivery isn’t going to address either of those situations, and if you’re the buyer that sucks because you’re bearing all of the risk of a problem that is in control of the seller.

The sample contract includes optional language that makes payment subject to acceptance of the shipment, which seems like a fair balance of the risks, but it adds in a layer of subjectivity that smart contracts aim to remove. One day, IoT sensors will be cheap and common enough that they can be attached to the widgets and help solve this problem, with the movement of the widgets logged on a blockchain. There’s a lot of work being done in this area, but it’s not mainstream yet, and it doesn’t solve for quality issues such as poorly made widgets or even the color of the widgets.

One solution is to provide a method for the buyer to reject a shipment — in part or in full — within a certain time after delivery and then make payment contingent on the buyer not objecting. It’s not a perfectly clean solution. The buyer could object to a shipment without justification and hold up payment, and even if the objection is justified, the buyer and seller are going to have to try to work through the issue.

Smart contracts have the promise of making transactions more efficient, but they are going to have to deal with real world issues, and real world issues are messy.

Next up: Part 4 — The Risk Shifting

Understanding real contracts: a guide for smart contracts coders. Part 2.

By

The scope of work section of a contract sets out critical business terms.
Worked Lights Photo by Mike Cofrancesco | License: CC BY-ND 2.0

Editor’s Note: This is an installment of a series of articles providing background to smart contracts coders about how contracts work in real life. The articles reference this sample sales contract. This guide is intended for general informational purposes only. If you need legal advice about a specific situation, contact a lawyer.

The second section of a contract is the scope of work. This is where the action is. It describes the promises and obligations of each of the parties. In the sample contract, it’s sections 1 and 2, which describe what’s being sold, when it needs to be delivered and where.

The sample is a contract for the sale of goods, which is a simple business relationship. I send you money, and you send me widgets. In a more complex relationship, the description would be a lot longer than it is in the sample. In some cases, particularly if one party is building something complex for the other party, the terms are put in a document that is attached to the back of the contract. 

Contracts drafters may use the term schedule, exhibit, appendix, attachment or statement of work for this separate document. Don’t get caught up in what it’s called. The names are pretty much interchangeable. They’re used for a couple of reasons. They make the flow of the main part of the contract a little smoother because they move some of the more complex terms to the back of the contract, but the main reason to move terms to a schedule is that there may be a different group of people that are focused on those terms than the terms in the main agreement. For example, if the contract covers the development of software, there may be a separate schedule that will require the attention of software engineers, solution architects and project managers. If the scope of work is in a separate document, these folks can trade drafts while others — lawyers, sales people and the business development team — work on the main sections of the agreement.

The main key to the scope of work section is to ensure it’s accurate and complete. If you’re the one providing the goods or services, you’ll want to make sure it doesn’t promise more than you intend to deliver. If you’re the one buying the goods or services, you’ll want to make sure it doesn’t promise less than you think you’re paying for.

Next up: Part 3 — The Money

Understanding real contracts: a guide for smart contracts coders. Part 1.

By

The introductory section of a contract identifies the parties and provides background information that may be useful in future reviews. Introductions Photo by Tricia | CC BY-2.0

Editor’s Note: This is the second installment of a series of articles providing background to smart contracts coders about how contracts work in real life. The articles reference this sample sales contract. This guide is intended for general informational purposes only. If you need legal advice about a specific situation, contact a lawyer.

Nearly all contracts begin by identifying the people or businesses that are making promises that are memorialized in the contract. You’ll see in the sample that it has a blank for “STATUS OF BUSINESS.” Yipes! What I think that really means is the type of business (in the U.S., this generally is a corporation or a limited liability company) so that it would say Acme, Inc.” or “Acme, LLC”, but considering the sample is pretty old-school, it’s also likely expecting that you’ll include the state of registration so that it would say “Acme, Inc., a Delaware corporation” or “Acme, LLC, a New York limited liability company.” Trust me, you can skip that information if it’s not readily available. Lawyers waste a bunch of time trying to track down the state of incorporation including too often for subsidiary companies of their own employer. I supposed this information could be useful in a lawsuit, but I think it appears in contracts mostly because people are afraid of the unknown consequences of leaving it off. God forbid if you’re the first person to not include the state of incorporation in a contract. The Law doesn’t like change. 

In addition to identifying the parties to a contract, the introductory paragraph usually also identifies the start date of the contract. Until you’ve done a contracts due diligence review, you have no idea how often people screw up the date of the contract, and people looking years later can’t figure out when then contract was supposed to start or, generally more importantly, end.  Was a contract that was sent by email on December 28, 2018, really meant to start on January 1, 2018 or was that a typo? Or then there are the contracts with a missing date. Again, you may need to look back at emails (if you have them) to see when it appears the parties intended the contract to start. The lesson here for coders is make sure you’re capturing the intended start for the contract you’re working on, and remember that is usually, but not always, the day the parties are signing the contract.

The next part of the introductory section of the contract is the recitals paragraph. I hate the term recitals.  It sounds as bad to my ears as an afternoon of listening to little kids playing Chopsticks on the piano. Some people call them the “whereases,” but that is even more awful.  As-es? You can’t be serious. If you know what you’re doing, you call this the background section, you write it in plain English (or whatever the native language is for your contract) and you actually make this useful. With high-volume sales contracts, there shouldn’t be much doubt about the background, but with customized, one-off contracts it’s really helpful to have a good description of why the parties were entering into the contract and what they intended to accomplish. 

Next up: Part 2 — The Scope of Work

Understanding real contracts: a guide for smart contracts coders. Introduction

By

Understanding contracts is critical for software engineers who are working on blockchain smart contracts. Contract Photo by Steve Snodgrass | License: CC BY 2.0

So, if you’re doing smart contracts as, well, actual contracts, it might be a good idea to know something about contracts. 

Law students in the United States spend one semester taking one class on contracts, and at least at the better law schools, it’s all theoretical and you don’t actually learn anything about contracts. I’m serious. In three years at one of the best law schools in the U.S., the only contract I saw was the lease agreement for my apartment.

It takes time grinding out billable hours at a Big Law firm to really learn contracts the way a good software engineer understands the flow of well-written code. It’s one of those Malcolm Gladwell 10,000-hour things.  Except, unlike some kid learning the violin who becomes a virtuoso between ages 4 and 18, as a law firm associate you get your 10,000 hours under your belt in two years because you’re trading time for money — actually your firm is trading your time for their money — in the most brazen way.

Anyway, here’s my effort to distill my 10,000 hours into a 20-minute read, and like a cheap wine distilled into grappa, it’s going to go down a little rough.

You’ll need something to follow along with, so here’s a sample sales contract that I found on the web. Like everything else you’re going to find on the web, it’s awful, but it was free and didn’t require trading my PII. And it’s good enough to demonstrate the points I’m going to make.

I’m going to break contracts into five parts. You’ve heard about contracts that were written on paper napkins like the world’s best footballer (soccer player for those of you in the States) Lionel Messi signing with Barcelona as a teenager, but those kind of contracts only work when there aren’t any disputes. Real contracts run several pages, and you can bet Messi’s current contract isn’t written on a cocktail napkin.

Here’s how I’ll break contracts down:

Part 1: The introduction

Part 2: The scope of work

Part 3: The money

Part 4: The risk shifting

Part 5: The miscellaneous junk that lawyers feel obligated to include.

Stay tuned for future installments.

Lawyers and Software Engineers Need to Collaborate to Fulfill Promise of Smart Contracts

By

Software engineers and lawyers will need to contribute their perspective and skills to make smart contracts work. Kumbaya Photo by Keith | License: CC By-SA 2.0

Last year, I took a blockchain business strategy class offered by MIT. The class was good and one of the key points was made by Christian Catalini, one of the professors who’s now apparently on leave from MIT because he’s a co-founder of the Libra cryptocurrency and the chief Economist for Calibra. 

I can’t find the exact quote, but it was something like: “It’s going to be really important for lawyers to work with software engineers to realize the promise of blockchain technology.”

Nowhere is this more true than with smart contracts. Yes, I know there’s been discussion that smart contracts aren’t necessarily legal contracts, but if they’re done right, smart contracts have the potential to make contracting more efficient and eliminate a lot of work that takes place in the backend to properly operationalize contracts.

Real contracts are like code. It takes experience to do them well, and like Catalini said, it’s going to require lawyers working with software engineers to really make smart contracts work well.

Good lawyers and good software engineers bear a lot of similarities. They’re fascinated with code, and good contracts are like good software code. The best contracts are not only functional; they are elegant in their simplicity. 

Software engineers and lawyers also are similar in that they tend to be stubborn. I remember my first meeting with the CTO I worked with years ago. He told me right off the bat that  he was “pretty good at interpreting contracts” with the implication being that didn’t really need my help. I told him I’d make him a deal “if you promise to not interpret contracts, I promise to not write code.” We had a really good working relationship after that because we had mutual respect for each other’s strengths.

But smart contracts are only of those areas where we can’t just mark off our territory. It’s going to take collaboration between lawyers and coders.  To that end, I’m offering a guide to contracts gives coders working with smart contracts the opportunity to learn something about the structure of contracts in real life. You’ll see this guide published in several installments on this blog in the coming days and weeks.

Counselor convicted; panel recognizes crypto & smart contracts; China cracks down on illicit currency

By

Lawyer Mark S. Scott was convicted of a money-laundering scheme, the proceeds of which he used to purchase luxury homes, cars and yachts. Photo by Marco Verch

Counselor Convicted of Crypto Crimes: A former law firm partner who aimed to earn $50 million by age 50 has found himself facing up to 50 years in prison for his role in a crypto-related money laundering scheme.  Mark S. Scott, a former partner at international firm Locke Lord, was convicted in U.S. federal court in New York of laundering $400 million in proceeds of a massive international fraud scheme known as “OneCoin” through fraudulent investment funds that Scott set up and operated for that purpose, according to the U.S. Attorney’s Office.  Scott received more than $50 million for his money laundering services, which he used to buy luxury cars, a yacht, and several seaside homes.

“Scott … used his specialized knowledge as an experienced corporate lawyer to set up fake investment funds, which he used to launder hundreds of millions of dollars of fraud proceeds.  He lined his pockets with over $50 million of the money stolen from victims of the OneCoin scheme. Scott, who boasted of earning ‘50 by 50’ now faces 50 years in prison for his crimes.”

Manhattan U.S. Attorney Geoffrey S. Berman

Recognizing Crypto and Smart Contracts: A U.K. panel issued a report this week on the legal status of cryptocurrency and smart contracts. The U.K. Jurisdiction Taskforce of the Lawtech Delivery Panel concluded that cryptocurrency should be considered legal property, which means that it can receive the same treatment under the law as other assets in circumstances such as bankruptcy or theft.  The panel also recognized that smart contracts can be treated as legally enforceable in the same manner as other more traditional contracts.

China Cracks Down on Crypto:  China’s central banking authority has announced a further crackdown on cryptocurrency, according to a report from Reuters. The People’s Bank of China said in a statement that “the issuance, financing and trading of virtual currencies involve multiple risks.”  The crackdown comes shortly after officials in Shenzhen announced a similar crackdown and as the RBOC prepares to offer its own cryptocurrency.    

Smart “Contracts”: You Keep Using that Word ….

By

Ethereum co-founder Vitalik Buterin recently expressed namer’s remorse at calling the applications that run on the Ethereum platform “smart contracts.”

Buterin’s comments followed a line of controversy about the terminology that suggests to some people that the code running on a blockchain platform reflects a legal relationship. Here’s a sample of opinions:

The “smart contract” banner is a very catchy marketing ploy. It has been instrumental as an adoption driver. It’s edgy, contrastive and highly-prescriptive: if you’re not hip to “smart contracts,” well, then, maybe you’re just not … smart.  

Posted by CleanApp (To be fair, the piece actually argues against calling them smart contracts.)
Although I mostly disagree with her on this point, I’ll note some of the most insightful segments of the blockchain course offered by MIT that I recently completed were interviews between one of the instructors and Dr. Barrera.

Developers refer to smart contracts as distributed applications or Dapps (pronounced dee-apps or dapps). That nomenclature avoids misperceptions about what the programs actually are, and what they can and can’t do.

So, let’s call smart contracts what they actually are: Dapps.” (footnoted citation excluded). 

 –Lawyer James F. Brashear 

Smart contracts are not contracts in the legal sense. They are not drafted by lawyers; they are written by computer programmers—they are software.

Lawyer Amir Azaran at the CDX Academy Blockchain Brand Innovation Summit in New York.

It’s not surprising.  Calling something a “contract” means something to lawyers.  Maybe we see it as invasion on our territory (when we’re not counting the potential billable hours when we realize that technology that is the next BIG THING involves “contracts” and the number of lawyers who have even read about smart contracts can be counted in the double digits (I submit the traffic report from my Google Analytics account for this blog as evidence.)

But the lawyers and Buterin have a point.  There’s about a 10,000 year tradition of defining a contract to include these elements:  (1) an offer, (2) acceptance of the offer, (3) consideration a/k/a a promise of an exchange of value and (4) mutuality — “meeting of the minds” a/k/a a common understanding of the terms that were offered and accepted.  And, if you’re about to Google my claim about the length of the tradition, please just stop. I have no idea how long that tradition goes back, but I kinda suspect it dates back to whenever humans started trading with each other, so actually more like 50,000 years ago (and, again, stop with the Googling).

It doesn’t take something very formal to create a contract.  Soccer (football, for my handful of U.K. readers) superstar Leo Messi’s original contract with Barcelona, a team which he helped make into one of the greatest of all time, was written on a napkin.  And, of course, this blog post would not be complete without mentioning computer scientist and lawyer Nick Szabo’s example of a vending machine as a smart contract (yeah, back in 1997 he used the term “smart contract”).

Perhaps, part of the confusion arises from associating the legal relationship — what we call a contract — from the document (or in the case of a vending machine, the system) that memorializes the relationship.  I suppose that technically a 100-page asset purchase agreement that is sitting on conference room table waiting to be signed may not be a “contract” in the strictest sense since there has been no acceptance, but every lawyer would call that a contract (actually, we’d call it an agreement or an APA because that’s how we roll).

But every piece of code is not a contract.  The following standing alone doesn’t reflect an offer, acceptance, consideration or mutuality (although it probably does reflect my bad Python coding skills):

if x==20 : # btw, in Python, the == means equals

print(“Hello World!”)

But what if the code reflected that if Wilma paid 20 Bitcoin to Fred, then Fred would print a banner for her that said  “Hello World!” along with offer and acceptance and some evidence of mutuality That sounds like a contract to me, at least in the sense of a document or system that reflects the elements of a contractual relationship.  It also sounds like a pretty bad deal for Wilma unless the value of Bitcoin goes down a lot further than it already has.

So, how about this for a compromise:  we call software code a contract only when it actually is a legal contract or at least it reflects a relationship with the 4 elements of a contract, the same way a paper document reflects those elements?  That doesn’t mean that computer code can’t be “smart.” That’s the brilliance of smart contracts, they effectuate at least part of the relationship formed by the contract automatically. In the vending machine example, I put my dollar in the machine and a package of those horrible (but delicious) peanut butter crackers comes out.  With software, for example, funds can transferred automatically when certain events occur or a title to property recorded on a blockchain ledger can be transferred when a payment is received.

Privacy Policy - Terms and Conditions