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