Ricardian Contracts

RC-bow-tieRicardian Contracts are really a stepping stone to Smart Contracts.  They are a way to link a contract to another system, typically an accounting system.  Ian Grigg came up with the Ricardian Contracts some time ago.  He first published about it in Financial Cryptography in 7 Layers in 1998.  Ricardian Contracts were initially used for Ricardo (hence their name), a bond platform.

They are a melding of a traditional contract with a contract that can be read and executed by machines. A Ricardian Contract can be defined as a single document that:

  1. is a contract offered by an issuer of some item of value (think of a bond, coin, token, currency, etc.) to a holder of such item;
  2. for a valuable right held by the holder, to be managed by the issuer;
  3. can be read in plain language by humans (so like a normal contract);
  4. can be read by programs (and is parsable like a database);
  5. digitally signed;
  6. carries the keys and server information; and
  7. is allied with a unique and secure identifier.

Generally a Ricardian Contract is one that is used to define a value for issuance and holding of something over the Internet.  It sets forth the applicable terms and sets it in cryptographic stone, so everyone knows who signed it, and when and exactly what it said at that time. It automates the offer and acceptance of the agreement and ensures they are enforceable.

It removes a good deal of the typical contract dispute issues, but not all of them.  Items such as what was the offer and whether it was accepted, who the parties are, what the terms of the contract are are greatly resolved. When you use natural language however, there are always items that may be ambiguous, or changes in the nature of the parties, the industry or the economy which can greatly change what parties expected in a contract (that’s assuming they both had the same expectations for all provisions in the contract – another thing that is usually not the case).

The Ricardian Contracts are a bit unique, and likely cannot be used for anything, as drafting these agreements which must include markup language to enable them to be read by computers is a bit different.  They are also pretty versatile and can be strung together (usually transactions are more complicated than one agreement can cover).

M&A Deals: What is a “Cap” and a “Basket”?

victorian-297856_960_720This is a follow up post on our series of merger and acquisition issues.  If you are selling your company you’ll be faced with the prospect of indemnifying the purchaser for any damages they suffer in connection with the sale.  Now such indemnification may arise for a number of reasons, such as an unknown debt or lien that was on an asset you sold, a claim that an employee or third party made against the company or an asset which you did not inform the purchaser of, or a number of other issues.  These are usually breaches of the representations and warranties that sellers have to make to the buyers in the asset purchase agreement.   For example, the seller will represent (i.e. state as true at the time of signing or closing or both) that there are no debts owed by the company or liens on the company assets.  If the deal closes and a lender or lien of the company did exist, its a breach of that representation, and the seller is liable to the buyer for any resulting damages. Read more

Using “Tested” or “Market” Contract Language

This is a response to a post by Ken Adams of Adams on Drafting.   In one of my earlier posts about the desires of certain clients to have as short a contract as possible, I stated that it was beneficial to draft an agreement a certain way, including certain terms and language, because judges have seen similar items before. Ken identified this and he reiterated his position that a contract drafter should not rely on what he deems “tested” contract language. Read more

Clickwrap License Cases: Treiber & Straub, Inc. v. UPS, 474 F.3d 379 (7th Cir. 2007)

Treiber & Straub, Inc. v. UPS, 474 F.3d 379 (7th Cir. 2007).

I think this case gives a more “substantive” holding than some of the other cases which merely hold that procedural items are enforceable, such as forum selection, class action waivers, etc.  This case actually enforces UPS’s online shipping website’s Terms of Use to the detriment of the shipper.

In this case, a user shipped a ring worth $100,000 via UPS’s online shipping website.  He submitted the ring in a package for shipping with the shipping label.  UPS then lost or misplaced the package.

In order to ship the ring the user had to click not once, but twice, to agree to UPS’s websites shipping Terms of Use.  The terms provided that UPS would not be responsible for any item of “unusual value” which it stated was anything over $50,000 (which is the maximum amount UPS let you insure an item for).

The shipper then put in a claim with UPS, and UPS disclaimed stating it did not have to pay him anything because it was an item of unusual value. The shipper then sued for the value of the ring and the court upheld UPS’s Terms of Use, finding that UPS provided adequate notice on its website to anyone shipping an item.

The Court held that using a clickwrap agreement for online transactions was “common in Internet commerce” where “one signifies agreement by clicking on a box on the screen.”  The court reasoned that merely because the user chose not to read the terms, that does not let him avoid any of the provisions he does not like.