Common Accord

= Cmacc - Legally enabled Crypto-Transacting: turning smart contracts into legally enforceable contracts

URL = http://commonaccord.org wiki

"CommonAccord is an open, collective and international effort for the standardization of law. We propose a collaboration to organize members of a global network of websites of legal content."

Description

1. Primavera de Filippi:

"CommonAccord plans to "open source" and automate the drafting of legal documents by creating a global template system of codified legal texts (i.e. something akin to the Incoterms rules for commercial transactions). The goal is to make the documents so modular that much of the text disappears, leaving parties with only specific deal points and clear relationships. These relationships can be 'rendered' at any time into full legal documents, for verification and enforcement. Technically, this is a data-model for text, an extremely simple and expandable data-model that consists of a series of nested lists that render into texts. The texts can be improved, extended and forked by the community. As such, CommonAccord is expected to play the same role in facilitating and accelerating collaboration on legal texts as git has played for code."

2. Website description:

"CommonAccord is a public website of legal materials intended to become a legal code for transactions in business, with government and in litigation. Fulfilling the goals of the Uniform Commercial Code and Napoleonic Code by open source methods – iteratively, rapidly and precisely.

Internationally, it is anticipated that each jurisdiction will foster it’s own website. These sites will interoperate with one another and with materials created by participants, trade groups and other publishers.

CommonAccord is based on collaboratively programmed documents. Parties privately define deal points and negotiated terms that rely on public or private forms and boilerplate. Participants can work simultaneously on different parts of a document without conflict or confusion. Versions are a chain of time stamped edits, each referencing the prior one.

Because the lists are labeled and linked to one another, everything can be immediately found. Paperwork can be automated reports, alarms and workflows established, best practices evolved, drafting aided, results predicted. The system learns with each use.

Confidentiality and data security are enhanced, because each participant can be given access to only the information they need, yet still contribute to the whole.

We will have clear, consistent, computable relationships."

Examples

Examples of use cases (switch between “Document” and “Source” to see the model in action)

• Frameworks of trust: NDAs; Master Agreements

• Licenses; Contribution Agreements

• Crowd-funding (Eris Assurance contract)

Status

Via James Hazard:

"The Swarm Common Accord] was started by Joel Dietz and James Hazard.

Commonaccord is a commons for legal documents, a kind of Civil Code 3.0, on GitHub, and compatible with P2P transacting systems such as blockchain. Primavera de Filippi did the software code and Marc Dangeard is using it in his company.

I put the License in at http://swarm.commonaccord.org/index.php?action=list&file=./Swarm/, along with some documents we did before.

The Participatory Orgs LLC agreement, which Joel sent my direction earlier, is now also in this repo, at http://swarm.commonaccord.org/index.php?action=list&file=./LLC/Form/."

Discussion

Primavea de Filippi:

"CommonAccord’s list-based template system provides a flexible, robust format for codifying and rendering legal texts from code.

This can be achieved in at least two ways:

Manual Matching

CommonAccord’s framework can be used to produce a legal document (whose torrent/hash can be incorporated into the blockchain as a proof of existence) to tie every smart contract to a real world one. Through inheritance, CommonAccord’s data model can express any smart contract as simple nested lists that can be rendered into legal documents, according to the selected jurisdiction and circumstances. This is a manual process that requires matching the prototype of the smart contract with the specific CommonAccord template that goes along with it.

Automated Matching

CommonAccord’s framework can be used as an API that returns matching snippets of code (both legal and technical code) whenever someone submits a request for a particular template, together with the necessary parameters requested by the template. This requires creating a database of independent ‘contract modules’ linking standardized code-snippets to their corresponding contractual provisions, which can be combined together into a collection of ‘contract-type templates’ (i.e. documents instructing how these modules can or should be incorporated into either a smart contract or a legal document).

Traditional contracts often share common "boilerplate" elements, and smart contracts are no different. CommonAccord’s inheritance system enables code reuse; this provides more convenience, as well as increased legal certainty. Many contracts will have relatively simple and easy to understand logic built on top of well-known and widely used modules. Modules could encompass basic functionality, or more advanced features such as a standard auction, escrow, or bond implementation.

The goal is to implement a modular template system which, after having been fed with specific parameters, can be rendered into both technical ‘dry’ code (i.e. self-contained code snippets) and legal ‘wet’ code (i.e. specific contractual provisions translating the code snippets into legalese) whose overall structure can be established directly through the CommonAccord template system.

Ideally, this would allow for the dynamic creation of sophisticated and highly customized smart-contracts, which are automatically rendered into a legal document enforceable between the parties.

Of course, both versions of the contract - the smart-contract, written into code, and the legal contract, written in human language - should cross-reference each other. The legal contract should include a reference to the smart-contract code (i.e. its blockchain address), whereas the smart-contract should incorporate a reference to the hash of the digitally-signed legal document, which should remain available on a decentralized storage system (which can be either public or private, according to the confidentiality rules). Those two versions may differ in certain regards. While there should be a 1:1 correspondence between the code and the specific template texts, the relationships established between these templates are uniquely defined in the code. As a result, the code version might be extremely unambiguous, but the generated legal text less so.

The question therefore arises as to which version should be relied upon in court in order to settle a dispute between the parties. Considering the current courts’ inability to understand computer code, it will most likely be the legal document. Yet, although it might be ignored at first, incorporating a reference to the smart-contract into the real-world legal contract might - in the long run - expand the opportunities for smart-contract enforcement, insofar as it might lead courts to consider the smart-contract code as evidence of how the legal contract should be effectively construed." (https://docs.google.com/document/d/1jm9t61JnqLqsV50cD9Mzwyu8cXWRmVFaI2XK-UaFggk/edit)

More Information

• source document from Primavera de Filippi: [[ Legal Framework For Crypto-Ledger Transactions]] [1]

• For more details on the CommonAccord data model, see:

http://commonaccord.org and http://beta.commonaccord.org/wiki/Main_Page.