Jump to content

Ricardian contract: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
m r3cev.com PDF original link 404, found and added web.archive.org link
 
(21 intermediate revisions by 7 users not shown)
Line 3: Line 3:
{{Citation style|date=May 2018}}
{{Citation style|date=May 2018}}


The '''Ricardian contract''', as invented by Ian Grigg in 1996, is a method of recording a document as a [[contract]] at law, and linking it securely to other systems, such as accounting, for the contract as an issuance of value.<ref name=Grigg2004>{{cite journal |first=Ian |last=Grigg |title=The Ricardian Contract |journal=Proceedings of the First IEEE International Workshop on Electronic Contracting |pages=25–31 |publisher=IEEE |date=2004 |doi=10.1109/WEC.2004.1319505 |isbn=0-7695-2184-3 |url=http://iang.org/papers/ricardian_contract.html}}</ref><ref>{{cite journal |url=https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3085682 |title=What is a Ricardian Contract? |journal=Cyberspace Law eJournal |publisher=Social Science Research Network |date=11 December 2017|ssrn=3085682 |last1=Chohan |first1=Usman W. }}</ref> It is robust through use of identification by [[cryptographic hash function]], transparent through use of readable text for legal prose and efficient through [[markup language]] to extract essential information.
The '''Ricardian contract''', as invented by Ian Grigg in 1996, is a method of recording a document as a [[contract]] at law, and linking it securely to other systems, such as accounting, for the contract as an issuance of value.<ref name=Grigg2004>{{cite book |first=Ian |last=Grigg |title=Proceedings. First IEEE International Workshop on Electronic Contracting, 2004 |chapter=The Ricardian contract |pages=25–31 |publisher=IEEE |date=2004 |doi=10.1109/WEC.2004.1319505 |isbn=0-7695-2184-3 |chapter-url=http://iang.org/papers/ricardian_contract.html}}</ref><ref>{{cite journal |url=https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3085682 |title=What is a Ricardian Contract? |journal=Cyberspace Law eJournal |publisher=Social Science Research Network |date=11 December 2017|ssrn=3085682 |last1=Chohan |first1=Usman W. }}</ref>{{Better source needed|reason=Source is a preprint server, which is not a RS.|date=November 2022}} It is robust through use of identification by [[cryptographic hash function]], transparent through use of readable text for legal prose and efficient through [[markup language]] to extract essential information.


A Ricardian contract places the defining elements of a legal agreement in a format that can be expressed and executed in software.<ref name=Clack>{{cite book |last1=Clack |first1=Christopher D. |last2=Bakshi |first2=Vikram A. |last3=Braine |first3=Lee |title=Smart Contract Templates: foundations, design landscape and research directions |date=2016 |arxiv=1608.00771}}</ref> The key is to make the format both machine-readable, such that they can easily be extracted for computational purposes, and readable as an ordinary text document such that lawyers and contracting parties may read the essentials of the contract conveniently.<ref name=NagaShakel>{{cite conference |last1=Nagy |first1=Daniel A. |last2=Shakel |first2=Nadzeya V. |title=OpenPGP-based Financial Instruments and Dispute Arbitration |date=2008 |conference=Financial Cryptography and Data Security |publisher=Springer |series=Lecture Notes in Computer Science |volume=5,143 |url=https://ifca.ai/fc08/presentations/7-2-nagy.pdf |isbn=978-3-540-85229-2 |doi=10.1007/978-3-540-85230-8_24 |editor-last=Tsudik |editor-first=Gene |pages=267–271 |location=Cozumel, Mexico}}</ref>
A Ricardian contract places the defining elements of a legal agreement in a format that can be expressed and executed in software.<ref name=Clack>{{cite book |last1=Clack |first1=Christopher D. |last2=Bakshi |first2=Vikram A. |last3=Braine |first3=Lee |title=Smart Contract Templates: foundations, design landscape and research directions |date=2016 |arxiv=1608.00771}}</ref>


⚫
The method arises out of the work of Ian Grigg completed in the mid-1990s in contributions to Ricardo,<ref>{{cite conference |last=Grigg |first=Ian |title=Financial Cryptography in 7 Layers |conference=Proceedings of Financial Cryptography Conference 2000 |location=Anguilla, British West Indies |date=February 2000 |publisher=Springer Verlag |series=LNCS |volume=1,962 |url=http://iang.org/papers/fc7.html}}</ref>{{Better source needed|reason=Citation is primary source by creator of the concept.|date=November 2022}} a system of assets transfers that was built in 1995-1996 by Systemics and included the pattern.
From a legal perspective, the use of [[markup language]] embedded within a mostly legal prose document leads to reduced transaction costs, faster dispute resolution, better enforceability and enhanced transparency.<ref name=NagaShakel/><ref name=Nagy2006>{{cite journal |last=Nagy |first=Daniel A. |title=On Digital Cash-like Payment Systems |date=2006 |journal=Proceedings of the International Conference on E-Business and Telecommunications |series=Communications in Computer and Information Science |volume=3 |pages=26–38 |doi=10.1007/978-3-540-75993-5_3 |isbn=978-3-540-75992-8 |url=https://link.springer.com/chapter/10.1007/978-3-540-75993-5_3 |url-access=subscription}}</ref> From a computing perspective, the Ricardian contract is a [[software design pattern]] to digitize documents and have them participate within financial transactions, such as payments, without losing any of the richness of the contracting tradition. Publication of the content and reference to that content by the unique [[cryptographic message digest]] eliminates frauds based on multiple presentations.<ref name=Nagy2006/>

⚫
The method arises out of the work of Ian Grigg completed in the mid-1990s in contributions to Ricardo,<ref>{{cite conference |last=Grigg |first=Ian |title=Financial Cryptography in 7 Layers |conference=Proceedings of Financial Cryptography Conference 2000 |location=Anguilla, British West Indies |date=February 2000 |publisher=Springer Verlag |series=LNCS |volume=1,962 |url=http://iang.org/papers/fc7.html}}</ref> a system of assets transfers that was built in 1995-1996 by Systemics and included the pattern. The system and the design pattern was named after [[David Ricardo]] in honour of his seminal contribution to [[international trade theory]].


==Definition==
==Definition==
Line 15: Line 13:
A Ricardian contract can be defined as a single document that is<ref name=Grigg2004/>
A Ricardian contract can be defined as a single document that is<ref name=Grigg2004/>


a) a contract offered by an issuer to holders,<br/>
# a contract offered by an issuer to holders,
b) for a valuable right held by holders, and managed by the issuer,<br/>
# for a valuable right held by holders, and managed by the issuer,
c) easily readable (like a contract on paper),<br/>
# easily readable (like a contract on paper),
d) readable by programs (parsable like a database),<br/>
# readable by programs (parsable like a database),
e) digitally signed,<br/>
# digitally signed,
f) carrying the keys and server information, and<br/>
# carrying the keys and server information, and
g) allied with a unique and secure identifier
# allied with a unique and secure identifier
}}
}}


==Diagram==
==Diagram==
The Ricardian contract separates the agreement of parties across time and domain. On the left of the "Bowtie" representation,{{clarify|date=June 2018}} the negotiation and formation of a legally binding contract leads to a single parent document that defines all of the intent of that agreement. On the right, the performance of that agreement might involve many transactions to be accounted for, logically separated from the meaning of the issue.<ref>{{cite book |last1=Fujimura |first1=Ko |last2=Terada |first2=Masayuki |chapter=Trading among Untrusted Parties via the Voucher Trading System |title=Towards the E-Society |date=2002 |publisher=Springer |chapter-url=https://link.springer.com/chapter/10.1007/0-306-47009-8_32#page-5 |pages=445–457 |editor-last1=Schmid |editor-first1=Beat |editor-last2=Stanoevska-Slabeva |editor-first2=Katarina |editor-last3=Tschammer |editor-first3=Volke |isbn=978-0-7923-7529-6 |location=Boston |series=International Federation for Information Processing |volume=74 |doi=10.1007/0-306-47009-8_32 |url=https://link.springer.com/book/10.1007/b116400}}</ref> The join between the legal world and the accounting world is formed by the hash — each transaction locks in the terms and conditions of the precise deal of the parties by including the hash of the contract in every relevant transaction record, yet the operation of the transactions and the issuance of the contract are cleanly separated and thus perverse incentives are eliminated.<ref>{{cite book |last=Franco |first=Pedro |chapter=14.5 Open Transactions |title=Understanding Bitcoin: Cryptography, Engineering and Economics |publisher=John Wiley & Sons |date=2014 |url=https://books.google.com/books?id=YHfCBwAAQBAJ |isbn=978-1-119-01916-9 |pages=240–241}}</ref>
The Ricardian contract separates the agreement of parties across time and domain. On the left of the "Bowtie" representation,{{clarify|date=June 2018}} the negotiation and formation of a legally binding contract leads to a single parent document that defines all of the intent of that agreement. On the right, the performance of that agreement might involve many transactions to be accounted for, logically separated from the meaning of the issue.{{Citation needed|reason=Previous citation only mentions Ricardian contracts in passing and doesn't support this|date=November 2022}} The join between the legal world and the accounting world is formed by the hash — each transaction locks in the terms and conditions of the precise deal of the parties by including the hash of the contract in every relevant transaction record, yet the operation of the transactions and the issuance of the contract are cleanly separated and thus perverse incentives are eliminated.<ref>{{cite book |last=Franco |first=Pedro |chapter=14.5 Open Transactions |title=Understanding Bitcoin: Cryptography, Engineering and Economics |publisher=John Wiley & Sons |date=2014 |url=https://books.google.com/books?id=YHfCBwAAQBAJ |isbn=978-1-119-01916-9 |pages=240–241}}</ref>


[[File:RC-bow-tie.png|thumb|500px|right|BowTie diagram of Ricardian contract elements & generatives]]
[[File:RC-bow-tie.png|thumb|500px|right|BowTie diagram of Ricardian contract elements & generatives]]


==Legal relationship==
==Legal relationship==
The role of the Ricardian contract is to capture the contractual relationship between contracting parties to assist later performance of that contract by programs.<ref name=Batlin>{{cite web |last=Batlin |first=Alex |title=Crypto 2.0 Musings – Combining Ricardian and Smart Contracts |date=2016 |website=LinkedIn |url=https://www.linkedin.com/pulse/crypto-20-musings-combining-ricardian-smart-contracts-alex-batlin}}</ref> In its contractual form, it is the recording of an offer from an issuer to a holder. The offer is signed digitally within the format by the offerer, typically using a plaintext digital signature such as provided by [[OpenPGP]].
The role of the Ricardian contract is to capture the contractual relationship between contracting parties to assist later performance of that contract by programs.{{Citation needed|reason=Previous citation was to self-published blog post|date=November 2022}} In its contractual form, it is the recording of an offer from an issuer to a holder. The offer is signed digitally within the format by the offerer, typically using a plaintext digital signature such as provided by [[OpenPGP]].


The acceptance of the [[contract]] is typically formed by signing/agreeing to a transaction that refers to the hash of that contract. Within the context of a high-performance payment system, a secure payment will cite the hash of the contract of the instrument being paid, as well as paying and payee parties and a quantity of units.<ref>{{cite web |last=Howland |first=Gary |date=1996 |title=Development of an Open and Flexible Payment System |url=http://systemics.com/docs/sox/overview.html |publisher=Systemics}}</ref> In a [[smart contract]]s system, the acceptance would be performed by operating the contract's code to move the state of the agreement forward.
The acceptance of the [[contract]] is typically formed by signing/agreeing to a transaction that refers to the hash of that contract. Within the context of a high-performance payment system, a secure payment will cite the hash of the contract of the instrument being paid, as well as paying and payee parties and a quantity of units.<ref>{{cite web |last=Howland |first=Gary |date=1996 |title=Development of an Open and Flexible Payment System |url=http://systemics.com/docs/sox/overview.html |publisher=Systemics}}</ref> In a [[smart contract]]s system, the acceptance would be performed by operating the contract's code to move the state of the agreement forward.

===Signing and intent===
Typically, the signing of the contract by any party is overtly performed by use of a private key. The original offerer's signature is typically over the original document, and is then appended to form a fully binding, readable offer for the assets described in the document.<ref>{{cite web |last=Dorier |first=Nicolas |title=Colored Coins and Ricardian Contracts |date=2014-12-10 |url=http://blog.coinprism.com/2014/12/10/colored-coins-and-ricardian-contracts/ |url-status=dead |archiveurl=https://web.archive.org/web/20150216103205/http://blog.coinprism.com/2014/12/10/colored-coins-and-ricardian-contracts/ |archivedate=2015-02-16}}</ref>

Later participation by parties in the contract such as payments or smart contract performance will typically sign over a hash identifier (as generated by a [[cryptographic hash function]]) over the signed original document. In contrast to the initial signature, the use of the hash of the contract within following transactions also signals intent, and forms a covert signature over the contract. Although private key signatures are well studied and are subject of legal frameworks such as the European digital signature directive, Grigg suggests that the trail of hashes – entanglement – forms a more effective evidence of intent<ref name=Grigg2004/> than a private key signature.

==Programming pattern==
As a pattern in design, the Ricardian contract is like a reference–object [[tuple]] from the tradition of [[object-oriented programming]].
The reference is a [[cryptographic hash function]], and the object is formed by writing classes that handle the type of contract needed; a [[factory (object-oriented programming)|factory]] would typically read enough of the text of the document to figure out which class type is involved, and then construct an object of that specific class over the text.

Once an object is constructed, it can be interrogated for contents: the hash, name of issuer, nature of issue, keys and signature status.

==Variations==
If the agreement is more complicated than a single document can describe, the documents can be chained: An acceptance of an offer can be a Ricardian contract that includes the hash of the offer, or the acceptance can include the entire contents of the earlier phase, a design pattern known as Russian dolls<ref>{{cite web |last=Odom |first=Chris |date=2013 |title=Sample Currency Contract |url=http://opentransactions.org/wiki/index.php/Sample_Currency_Contract}}</ref> used by both OpenTransactions and [[OpenBazaar]]. These referral patterns can be conducted multiple times to create a chain or hierarchy of elements.

==Formats==
A relevant decision is choosing a representation of the text such that [[markup language|markup]] can be included to assist the software agent while maintaining readability.<ref>{{cite web |last=Wittenberger |first=Jorg F. |title=Contracts in A-Coin Wallets |website=BALL |publisher=Askemos |url=http://ball.askemos.org/A0cd6168e9408c9c095f700d7c6ec3224/?_v=search&_id=1856&_go=5}}</ref> To be a Ricardian contract, it has to be parsable both by the program and by a human reader.<ref name=Wörner>{{cite document |last1=Wörner |first1=Dominic |last2=von Bomhard |first2=Thomas |last3=Schreier |first3=Yan-Peter |last4=Bilgeri |first4=Dominic |title=The Bitcoin Ecosystem - Disruption beyond Financial Services? |date=2016 |url=https://www.alexandria.unisg.ch/publications/248647}}</ref>

"Readability" is necessarily defined relative to some viewing interface. Embedded markup systems such as XML are commonly viewed not as "raw source", but with much richer formatting applied. Jurists need not view "raw" JSON, LaTeX, or XML any more than Web users must view raw HTML or hexadecimal PNG images. Some visually impaired readers necessarily use very different interfaces. Even "plain text" editors differ in the treatment of [character sets] and [character encodings], OS-specific line-ends, fonts, tabs, wrapping of long lines, etc. Even a simple text editor can be hacked to mis-display text in a desired way, just like any other software can. But with standard, non-binary data representations underneath users can compare multiple viewing solutions, and with text-based representations as opposed to [[binary file]]s it is practical to check the source document directly when desired (or, as commonly done, to view fully-formatted and raw views simultaneously).

An ideal document format should also support a [[canonical form]] hash ([[cryptographic hash function]]), that is, have a way of delivering a hash over contents that does not change due to common [[serialisation]] and transmission artifacts.
[[LaTeX]] and [[XML]] are suitable because their source is generally readable by humans, and they have widely-available renderers. XML also has a standardized [[Canonical XML]] form which is specifically designed to facilitate cryptographic hashing, and neutralizes minor syntactic variations such as insignificant whitespace, platform-specific line-ends, order of attributes, etc.

Popular formats such as [[JSON]] and [[Semantic Web]] formats are often, though not always, much less readable in raw form to non-programmers such as jurists, and much more subject to unbounded syntactic but not semantic variation.<ref name=Webfunds>{{cite web |work=Webfunds |title=Ricardian Implementations |date=2016 |url=http://webfunds.org/guide/ricardian_implementations.html}}</ref><ref name=Batlin/>


==Relationship to smart contracts==
==Relationship to smart contracts==
[[Smart contract]]s, as defined in the work of [[Nick Szabo]] are an abstract concept relating to the automated performance of an already agreed contract,<ref>{{cite web |last=Szabo |first=Nick |author-link=Nick Szabo |title=Smart Contracts |date=1994 |url=http://szabo.best.vwh.net/smart.contracts.html |accessdate=2016-06-13 |url-status=dead |archiveurl=https://web.archive.org/web/20160306112751/http://szabo.best.vwh.net/smart.contracts.html |archivedate=2016-03-06}}</ref> whereas the Ricardian contract is a design pattern to capture the intent of the agreement of the parties, before its performance.<ref>{{cite web |last=Braendgaard |first=Pelle |title=Simple Convention for Human Readable Terms for Smart Contracts |website=StakeVentures |date=June 29, 2016 |url=https://blog.stakeventures.com/articles/smart-contract-terms}}</ref>
[[Smart contract]]s, as defined in the work of [[Nick Szabo]] are an abstract concept relating to the automated performance of an already agreed contract,<ref>{{cite web |last=Szabo |first=Nick |author-link=Nick Szabo |title=Smart Contracts |date=1994 |url=http://szabo.best.vwh.net/smart.contracts.html |accessdate=2016-06-13 |url-status=dead |archiveurl=https://web.archive.org/web/20160306112751/http://szabo.best.vwh.net/smart.contracts.html |archivedate=2016-03-06}}</ref> whereas the Ricardian contract is a design pattern to capture the intent of the agreement of the parties, before its performance.{{Citation needed|reason=Previous citation was to a self-published crypto blog|date=November 2022}}


By means of hashes within as references or links to external documents, above, the Ricardian contract form easily extends to refer to code.<ref name=Clack/><ref name=Grigg2015>{{cite web |last=Grigg |first=Ian |title=The Sum of all Chains – Let's Converge |date=2015 |work=Coinscrum |url=http://financialcryptography.com/mt/archives/001556.html}}</ref> The explicit referral to the code can pass legitimacy from overarching legal prose to the code, thus implementing the concept of the smart contract.<ref>{{cite web |last1=Brown |first1=Richard Gendal |last2=Carlyle |first2=James |last3=Grigg |first3=Ian |last4=Hearn |first4=Mike |title=Corda: An Introduction |date=2016 |url=http://r3cev.com/s/corda-introductory-whitepaper-final.pdf |archiveurl=https://web.archive.org/web/20170606024011/https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/57bda2fdebbd1acc9c0309b2/1472045822585/corda-introductory-whitepaper-final.pdf |archivedate=2017-06-06 |url-status=dead}}</ref>
By means of hashes within as references or links to external documents, above, the Ricardian contract form easily extends to refer to code.<ref name=Clack/><ref name=Grigg2015>{{cite web |last=Grigg |first=Ian |title=The Sum of all Chains – Let's Converge |date=2015 |work=Coinscrum |url=http://financialcryptography.com/mt/archives/001556.html}}</ref>{{Better source needed|reason=Self-published transcript of a talk, not a RS.|date=November 2022}} The explicit referral to the code can pass legitimacy from overarching legal prose to the code, thus implementing the concept of the smart contract.<ref>{{cite web |last1=Brown |first1=Richard Gendal |last2=Carlyle |first2=James |last3=Grigg |first3=Ian |last4=Hearn |first4=Mike |title=Corda: An Introduction |date=2016 |url=http://r3cev.com/s/corda-introductory-whitepaper-final.pdf |archiveurl=https://web.archive.org/web/20170606024011/https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/57bda2fdebbd1acc9c0309b2/1472045822585/corda-introductory-whitepaper-final.pdf |archivedate=2017-06-06 |url-status=dead}}</ref>


Refactoring to describe blockchains and to integrate references to smart contract logic created a hybrid version of the Ricardian contract.<ref name=Grigg2015/><ref>{{cite web |last=Grigg |first=Ian |title=On the intersection of Ricardian and Smart Contracts |date=2015 |url=http://iang.org/papers/intersection_ricardian_smart.html}}</ref> This form proposes a tuple of {prose, parameters, code} where the parameters can particularise or specialise the legal prose and the computer code in order to create a single deal out of a template or library of components.<ref name=Clack/> Also known as a Ricardian triple, it can describe blockchains, smart contracts, IoT devices and persons.
Refactoring to describe blockchains and to integrate references to smart contract logic created a hybrid version of the Ricardian contract.<ref name=Grigg2015/><ref>{{cite web |last=Grigg |first=Ian |title=On the intersection of Ricardian and Smart Contracts |date=2015 |url=http://iang.org/papers/intersection_ricardian_smart.html}}</ref> This form proposes a tuple of {prose, parameters, code} where the parameters can particularise or specialise the legal prose and the computer code in order to create a single deal out of a template or library of components.<ref name=Clack/> Also known as a Ricardian triple, it can describe blockchains, smart contracts, IoT devices and persons.

==Implementations==

There are several explicit extant implementations of the Ricardian contract design pattern and there are some projects which do so implicitly and others which are heading in that direction.<ref name=Webfunds/>
Amongst those explicitly using the pattern are:
{| class="wikitable sortable"
|-
! Project !! Comment !! Project lead
|-
| Ricardo
| An early payment system using a cryptographically signed transaction tree, which was the first implementation of "triple entry accounting". Ricardo was originally developed by Systemics Ltd. using SOX (Systemics Open Transactions) technology. Early applications included DigiGold, an online payments system backed 100% by gold.<ref>{{Cite web|title=Systemics - Ricardo|url=http://www.systemics.com/docs/ricardo/|access-date=2021-09-11|website=www.systemics.com|language=en}}</ref><ref>{{Cite web|title=DigiGold|url=https://cryptome.org/jya/digigold.htm|access-date=2021-09-11|website=www.cryptome.org.com|language=en}}</ref> ||Ian Grigg
|-
| Open Transactions
| "Open-Transactions implements financial instruments as Ricardian Contracts, which are contracts that can be understood by humans as well as manipulated by software."<ref>{{cite web |first=Chris |last=Odom |title=Open-Transactions: Secure Contracts between Untrusted Parties |date=2015 |url=http://www.opentransactions.org/open-transactions.pdf}}</ref> Like [[Pretty Good Privacy]], Open-Transactions secures financial transactions using multiple cryptography algorithms.<ref>{{Cite web|title=Bitcoin Mania: How To Create Your Very Own Crypto-Currency, For Free|url=https://www.forbes.com/sites/reuvencohen/2013/11/29/bitcoin-mania-how-to-create-your-very-own-crypto-currency-for-free/?sh=11a82a9213c8|access-date=2021-10-11|website=www.forbes.com|language=en}}</ref> || Chris Odom
|-
| [[OpenBazaar]]
| "The Ricardian contract is a means of tracking the [[Legal liability|liability]] of one party to another when selling goods to each other in OpenBazaar. Fundamentally, a contract represents a single unit of a good or service. Ricardian contracts should be used in OpenBazaar as they are means of effectively tracking legitimately signed agreements between two parties, which cannot be forged after the contract has been signed. Ricardian contracts make use of a chain of digitally signed and checksum hashed contracts to create an unalterable record of agreement for an exchange on a peer-to-peer network."<ref>{{cite web |first=Washington |last=Sanchez |title=Ricardian Contracts in OpenBazaar |date=2014 |url=https://gist.github.com/drwasho/a5380544c170bdbbbad8#example}}</ref> "Trades on the OpenBazaar network are based on Ricardian Contracts,<ref>{{Cite web |url=http://iang.org/ricardian/ |title=Iang - The Ricardian Contract |website=iang.org |language=en|access-date=2017-06-06}}</ref><ref>{{Cite web |url=http://iang.org/papers/ricardian_contract.html |title=The Ricardian Contract |website=iang.org |access-date=2017-06-06}}</ref> i.e. an electronic document that defines the terms of a trade such that it is readable by computers and humans, and is cryptographically signed. Apart from selling physical and digital products, OpenBazaar can also be used to trade speculative contracts, which can be readily represented by Ricardian Contracts"<ref name=Wörner/> || Washington Sanchez
|-
| Monax Legal Markdown
| Allows for dual-integration of [[smart contract]] code and prosaic contract language.{{citation needed|date=July 2018}} Monax uses a beacon - or agreements beacon - as the smart contract within the Monax Digital Agreement platform.<ref>{{Cite web|title=Monax - Integrating with the agreements beacon|url=https://monax.io/help/advanced/nft-integration/|access-date=2021-10-11|website=www.monax.io|language=en}}</ref> This allows users to manage and automate business obligations, tasks and procedures related to digital contracts in real-time.<ref>{{Cite web|title=Monax Releases New Blockchain-Based Contract Management Platform - Legaltech News|url=https://www.law.com/legaltechnews/2019/02/13/monax-releases-new-blockchain-based-contract-management-platform/|access-date=2021-10-11|website=www.law.com|language=en}}</ref>|| Nina Kilbride, Casey Kuhlman
|-
| Askemos
| Ricardian contracts are described as a reification of an Askemos class.<ref>{{Cite web | url=http://ball.askemos.org/Abb8999dd38524dcc113f977d378a9ee0?_id=3145&_v=footnote | title=Askemos}}</ref> Askemos uses a set of cooperative "notaries" or nodes to securely exchange information. These notaries can run an autonomous "agent". An agent is an operation run by each notary in consensus. A user's personal notary can sign off on their information before distribution to others for agreement. The presentation of the information can be regarded as a Ricardian Contract.<ref>{{Cite web|title=Implementations of Ricardian Contracts|url=https://www.webfunds.org/guide/ricardian_implementations.html|access-date=2021-10-11|website=www.webfunds.org|language=en}}</ref>|| Jörg Wittenberger
|-
| [[Barclays]]' Smart Contract Templates
| Ricardian contracts are described as foundational to "an agreement whose execution is both automatable and enforceable."<ref>{{cite web |publisher=R3 CEV | title=Smart Contract Templates Summit | date=29 June 2016 | url=http://r3cev.com/s/R3-Smart-Contract-Templates-Summit-_FINAL.pdf | language=en | archive-url=https://web.archive.org/web/20170304032317/https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/5784f5dbebbd1aba2d3e400e/1468331499513/R3+Smart+Contract+Templates+Summit+_FINAL.pdf | archive-date=2017-03-04}}</ref>{{Primary source inline|date=June 2017}}<br>Further details in Smart Contract Templates: foundations, design landscape and research directions<ref name=Clack/> || Dr Lee Braine
|-
| R3's Corda
| "in a system that perhaps had an express design goal of having the code be dominant, there is a need to have a broader contract that explains what happens in the event that things do go wrong"<ref>{{cite web |last=Allison |first=Ian |title=R3 extends collaboration with Smart Contract Templates Summit |date=July 13, 2016 |work=International Business Times |url=http://www.ibtimes.co.uk/r3-extends-collaboration-smart-contract-templates-summit-1570121}}</ref> || Richard Gendal Brown
|-
| LegalThings
Live Contracts
| A Live Contract has a textual representation and a machine interpretable representation in the form of a Finite state machine. Each state transition must be digitally signed and is subsequently stored with the contract, forming a private blockchain. Anchoring to a global blockchain is used for time stamping and proof of existence.<ref>{{Cite web |url=https://medium.com/legalthingsone/ricardian-contracts-legally-binding-agreements-on-the-blockchain-4c103f120707 |title=Ricardian contracts — legally binding agreements on the blockchain |last=Cardon |first=Diederick |date=2017-11-30 |website=Medium |access-date=2018-01-07}}</ref>
|Arnold Daniels
|-
| Mattereum
| "The Ricardian contract solves the above problems. It takes the legal prose of the lawyers or the legally adept business person, incorporates the signature, and then hashes the agreed document."<ref>{{cite web |url=https://www.mattereum.com/upload/iblock/af8/mattereum_workingpaper.pdf |title=Smart Contracts, Real Property |publisher=Mattereum |first1=Vinay |last1=Gupta |first2=Rob |last2=Knight |first3=Aeron |last3=Buchanan |first4=Christopher |last4=Wray |first5=Ian |last5=Grigg |first6=Casey |last6=Kuhlman |first7=Mihai |last7=Cimpoesu |first8=Michael |last8=Mainelli |first9=Clive |last9=Freedman}}</ref>{{Primary source inline|date=July 2018}}
|Vinay Gupta
|-
| Chamapesa
| Extends the Ricardian contract to a use case called a "Distributed Ricardian Contract."{{citation needed|date=July 2018}}
| Ian Grigg
|-
| Tokenized
| "Our smart contracts are a comprehensive form of Ricardian contracts, that allow for machine-readable/enforceable terms and conditions, as well as human-readable prose."<ref>{{cite web | url=https://medium.com/tokenized-blog/introducing-tokenized-c397d3b5cae3 |date=March 31, 2021 | title=Introducing Tokenized API | publisher=James Belding | first1=James | last1=Belding}}</ref>{{Primary source inline | date=March 2021}}
| James Belding
|}

==Intellectual property==
The Ricardian contract is free of any intellectual property restrictions, other than the request that any implementations cite the author and link to the paper.<ref>{{cite web |last=Grigg |first=Ian |title=IP Concerns over Ricardian Contracts |date=2016 |website=Financial Cryptography |url=http://financialcryptography.com/mt/archives/001595.html}}</ref> It was fully published as design and implementation in 1996, and was described in an academic paper presented in 2004. No patent or other intellectual property mechanism was ever asserted by its inventor, Ian Grigg nor by Systemics.


==References==
==References==

Latest revision as of 15:09, 7 June 2024

The Ricardian contract, as invented by Ian Grigg in 1996, is a method of recording a document as a contract at law, and linking it securely to other systems, such as accounting, for the contract as an issuance of value.[1][2][better source needed] It is robust through use of identification by cryptographic hash function, transparent through use of readable text for legal prose and efficient through markup language to extract essential information.

A Ricardian contract places the defining elements of a legal agreement in a format that can be expressed and executed in software.[3]

The method arises out of the work of Ian Grigg completed in the mid-1990s in contributions to Ricardo,[4][better source needed] a system of assets transfers that was built in 1995-1996 by Systemics and included the pattern.

Definition

[edit]

A Ricardian contract can be defined as a single document that is[1]

  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 (like a contract on paper),
  4. readable by programs (parsable like a database),
  5. digitally signed,
  6. carrying the keys and server information, and
  7. allied with a unique and secure identifier

Diagram

[edit]

The Ricardian contract separates the agreement of parties across time and domain. On the left of the "Bowtie" representation,[clarification needed] the negotiation and formation of a legally binding contract leads to a single parent document that defines all of the intent of that agreement. On the right, the performance of that agreement might involve many transactions to be accounted for, logically separated from the meaning of the issue.[citation needed] The join between the legal world and the accounting world is formed by the hash — each transaction locks in the terms and conditions of the precise deal of the parties by including the hash of the contract in every relevant transaction record, yet the operation of the transactions and the issuance of the contract are cleanly separated and thus perverse incentives are eliminated.[5]

BowTie diagram of Ricardian contract elements & generatives
[edit]

The role of the Ricardian contract is to capture the contractual relationship between contracting parties to assist later performance of that contract by programs.[citation needed] In its contractual form, it is the recording of an offer from an issuer to a holder. The offer is signed digitally within the format by the offerer, typically using a plaintext digital signature such as provided by OpenPGP.

The acceptance of the contract is typically formed by signing/agreeing to a transaction that refers to the hash of that contract. Within the context of a high-performance payment system, a secure payment will cite the hash of the contract of the instrument being paid, as well as paying and payee parties and a quantity of units.[6] In a smart contracts system, the acceptance would be performed by operating the contract's code to move the state of the agreement forward.

Relationship to smart contracts

[edit]

Smart contracts, as defined in the work of Nick Szabo are an abstract concept relating to the automated performance of an already agreed contract,[7] whereas the Ricardian contract is a design pattern to capture the intent of the agreement of the parties, before its performance.[citation needed]

By means of hashes within as references or links to external documents, above, the Ricardian contract form easily extends to refer to code.[3][8][better source needed] The explicit referral to the code can pass legitimacy from overarching legal prose to the code, thus implementing the concept of the smart contract.[9]

Refactoring to describe blockchains and to integrate references to smart contract logic created a hybrid version of the Ricardian contract.[8][10] This form proposes a tuple of {prose, parameters, code} where the parameters can particularise or specialise the legal prose and the computer code in order to create a single deal out of a template or library of components.[3] Also known as a Ricardian triple, it can describe blockchains, smart contracts, IoT devices and persons.

References

[edit]
  1. ^ a b Grigg, Ian (2004). "The Ricardian contract". Proceedings. First IEEE International Workshop on Electronic Contracting, 2004. IEEE. pp. 25–31. doi:10.1109/WEC.2004.1319505. ISBN 0-7695-2184-3.
  2. ^ Chohan, Usman W. (11 December 2017). "What is a Ricardian Contract?". Cyberspace Law eJournal. Social Science Research Network. SSRN 3085682.
  3. ^ a b c Clack, Christopher D.; Bakshi, Vikram A.; Braine, Lee (2016). Smart Contract Templates: foundations, design landscape and research directions. arXiv:1608.00771.
  4. ^ Grigg, Ian (February 2000). Financial Cryptography in 7 Layers. Proceedings of Financial Cryptography Conference 2000. LNCS. Vol. 1, 962. Anguilla, British West Indies: Springer Verlag.
  5. ^ Franco, Pedro (2014). "14.5 Open Transactions". Understanding Bitcoin: Cryptography, Engineering and Economics. John Wiley & Sons. pp. 240–241. ISBN 978-1-119-01916-9.
  6. ^ Howland, Gary (1996). "Development of an Open and Flexible Payment System". Systemics.
  7. ^ Szabo, Nick (1994). "Smart Contracts". Archived from the original on 6 March 2016. Retrieved 13 June 2016.
  8. ^ a b Grigg, Ian (2015). "The Sum of all Chains – Let's Converge". Coinscrum.
  9. ^ Brown, Richard Gendal; Carlyle, James; Grigg, Ian; Hearn, Mike (2016). "Corda: An Introduction" (PDF). Archived from the original (PDF) on 6 June 2017.
  10. ^ Grigg, Ian (2015). "On the intersection of Ricardian and Smart Contracts".
Retrieved from "https://en.wikipedia.org/w/index.php?title=Ricardian_contract&oldid=1227741505"