Colored Coins and Ricardian Contracts

What is a Ricardian Contract ?

An asset is any object representing rights which can be redeemed to an issuer on specific conditions.

  • A company’s share gives right to dividends,
  • A bond gives right to the principal at maturity, coupons bears interest for every period,
  • A voting token gives right to vote decisions about an entity. (Company, election)
  • Some mix are possible : A share can also be a voting token for the company’s president election,

Such rights are typically enumerated inside a Contract, and signed by the issuer. (and a trusted party if needed, like a notary)

A Ricardian contract is a Contract which is cryptographically signed by the issuer, and can’t be dissociated from the asset.
So the contract can’t be denied, tampered, and is provably signed by the issuer.

Such contract can be kept confidential between the issuer and the redeemer.

Open Asset can already support all of that without changing the core protocol, and here is how.

Ricardian Contract inside Open Asset

Here is the formal definition of a ricardian contract :

  1. A contract offered by an issuer to holders,
  2. for a valuable right held by holders, and managed by the issuer,
  3. easily readable by people (like a contract on paper),
  4. readable by programs (parsable like a database),
  5. digitally signed,
  6. carries the keys and server information, and
  7. allied with a unique and secure identifier.

An AssetId is specified by OpenAsset in such way :

Let’s make such ScriptPubKey a P2SH as :

Where :

IssuerScript refer to a classical P2PKH for a simple issuer, multi sig if issuance need several consents. (issuer + notary for example)
It should be noted that from Bitcoin 0.10, IssuerScript is arbitrary and can be anything.

The “RicardianContract” can be arbitrary, and kept private. Whoever hold the contract can prove that it applies to this Asset thanks to the hash in the ScriptPubKey.

But let’s make such RicardianContract discoverable and verifiable by wallet clients with the Asset Definition Protocol.
Let’s assume we are issuing a Voting token for candidate A,B or C.

Let’s add to the Open Asset Marker, the following asset definition url : u=http://issuer.com/contract

In the http://issuer.com/contract page, let’s create the following Asset Definition File :

And now we can define the RicardianContract :

This terminate our RicardianContract implemented in OA.

Check list

A contract offered by an issuer to holders

The contract is hosted by the issuer, unalterable, and signed every time the Issuer issues a new asset,

for a valuable right held by holders, and managed by the issuer,

The right in this sample is a voting right for candidate A,B,C to give before 10 jan 2015.

easily readable by people (like a contract on paper),

The human readable contract is in the contract_url, but the JSON might be enough.

readable by programs (parsable like a database),

The details of the vote are inside the AssetDefinitionFile, in JSON format, the authenticity of the contract is verified by software with the IssuerScript, and the hash in the ScriptPubKey.

digitally signed,

The ScriptPubKey is signed when the issuer issues the asset, thus, also the hash of the contract, and by extension, the contract itself.

carries the keys and server information

IssuerScript is included in the contract

allied with a unique and secure identifier.

The AssetId is defined by Hash(ScriptPubKey) that can’t be changed and is unique.

What is it for ?

Without Ricardian Contract, it is easy for a malicious issuer to modify or repudiate an Asset Definition File.
Ricardian Contract enforces non-repudiation, make a contract unalterable, so it facilitate arbitration matter between redeemers and issuers.
Also, since the Asset Definition File can’t be changed, it becomes possible to save it on redeemer’s own storage, preventing  rupture of access to the contract by a malicious issuer.

You may also like...

  • Eric MSc Blockology

    I understood nothing. Where can I read about the Counterparty operations to understand the significance of this?

    • flaviencharlon

      This is colored coins, not Counterparty. Colored coins don’t use special operations, they use the Bitcoin protocol directly. OP_DROP is a Bitcoin opcode.

      • Eric MSc Blockology

        You’re right, I mistakenly wrote that. I’m on the Coinprism blog talking about a colored coin feature, after all.

  • Gavin Engel

    I love this blog, all this new information is fascinating! A couple questions on this topic. Can a p2p loan be equated to a Ricardian Contract? Will there there be a real overlap between colored coins and btcjam.com for p2p loans? Also, counterparty boasts an escrow feature. Could/will colored coins do this built in escrow as well?

    • http://financialcryptography.com/ iang

      Gavin,
      a p2p loan could certainly be presented as a Ricardian Contract. At its minimal, it is just a wrapper that takes a prose contract into the digital domain.

      Whether a system like btcjam.com does that I don’t know; there certainly will be contracts there, but whether they want both users and programs to read those contracts, refer to them in transactions, move them around, party to party, is another matter. Somewhat depends on their business model.

  • iang

    Nicolas, thanks for doing this.
    Can you point me to some examples of this? I’m writing up notes for a talk on the evolution of Ricardian Contracts, and hoping to include some examples of how it has made its way into the blockchain.

    • Lucas

      Hi Ian, Nicolas, did you find an example?
      Found some interesting assets linking to contracts in their asset defintions but they don’t have a hash of the contract in the asset definition.. (e.g. https://www.lykkex.com/lkeCHF)