Contract

From Organic Design wiki
Glossary.svg This page describes a concept which is part of our glossary

Contracts are based on the principle expressed in the Latin phrase pacta sunt servanda, which means "agreements to be kept" ("Agreement" also links to this article). A contract is said to come into existence when acceptance of an offer (agreement to the terms in it) has been communicated to an offeror by an offeree and there has been consideration bargained-for induced by promises or a promise and performance. The offer and acceptance formula, developed in the 19th century, identifies a moment of formation when the parties are of one mind (unified).

The bottom line purpose of contracts is really about ensuring that there is a stable operating environment on to which we can build systems and organisations. As with trading, governance or any other aspect of the social mechanism, this stable operating environment can be achieved without the need of trusted third-parties. This stability can also be provided in a bottom-up peer-to-peer way by making assurance the foundation of contractual binding between members of a Platform.

Having assurance as the foundation allows individuals to only be required to form contracts with those they know and trust, and it's based on supporting our peers when they're unable to meet their obligations, rather than treating contracts as rules involving punishments for violations. In such a system, obligations are solidly met because people recognise the value of their trust networks and don't want to damage them.

Such agreements allow the creation of assurances which can then act as axioms for functionality on higher levels of abstraction in the system. Sets of simple agreements between members of trust groups can also form a foundation for alignment with the common vision.

The Platform specification inherits some default member agreements deriving from the common vision and the values. In a Platform, these contracts are documents that members can agree to by sending a signed secure email containing the contract text and a confirmation of comprehension and agreement to a number of other peers who then sign and return the message with a confirmation of having witnessed the signed agreement.

Contract trust

The first and most fundamental issue that one needs to understand is the distinction between a statutory trust and a non-statutory trust. A non-statutory trust is generally referred to as a common law trust.

Statutory trusts are those, which like corporations, are established by and through a law created by the legislature of your state. Such trusts are imbued by the legislature with certain "financial advantages" (e.g. exempting certain property from State taxation of one form or another). However, such trusts are 100% within the regulatory control of the State. If the legislature were to change its mind tomorrow and withdraw the trust's financial advantage, they would be doing nothing wrong and you would have no recourse. When you place property in a statutory trust, you are in effect saying to the legislature, "I agree that this property is within the State’s jurisdiction and it would be really great if you'd treat me fairly in the future". Placing one’s property within a statutory trust also makes that property ripe for administrative levy and/or seizure in the event that a tax agency makes a claim against the person who established the trust, or against the trust directly.

Conversely, common law trusts are not created by legislative fiat, but are created in the realm of Equity and under a Citizen's unalienable right to contract. For more information see Contract Trusts.pdf.

Smart Contracts

From Formalizing and Securing Relationships on Public Networks - by Nick Szabo
 The basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher. A canonical real-life example, which we might consider to be the primitive ancestor of smart contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and via a simple mechanism, which makes a freshman computer science problem in design with finite automata, dispense change and product according to the displayed price. The vending machine is a contract with bearer: anybody with coins can participate in an exchange with the vendor. The lockbox and other security mechanisms protect the stored coins and contents from attackers, sufficiently to allow profitable deployment of vending machines in a wide variety of areas.

Smart contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short.

As another example, consider a hypothetical digital security system for automobiles. The smart contract design strategy suggests that we successively refine security protocols to more fully embed in a property the contractual terms which deal with it. These protocols would give control of the cryptographic keys for operating the property to the person who rightfully owns that property, based on the terms of the contract. In the most straightforward implementation, the car can be rendered inoperable unless the proper challenge-response protocol is completed with its rightful owner, preventing theft. But if the car is being used to secure credit, strong security implemented in this traditional way would create a headache for the creditor - the repo man would no longer be able to confiscate a deadbeat's car. To redress this problem, we can create a smart lien protocol: if the owner fails to make payments, the smart contract invokes the lien protocol, which returns control of the car keys to the bank. This protocol might be much cheaper and more effective than a repo man. A further reification would provably remove the lien when the loan has been paid off, as well as account for hardship and operational exceptions. For example, it would be rude to revoke operation of the car while it's doing 75 down the freeway.

Ricardian Contract

A Ricardian Contract can be defined as a single document that is

  • A contract offered by an issuer to holders
  • For a valuable right held by holders, and managed by the issuer
  • Easily readable by people (like a contract on paper)
  • Readable by programs (parsable like a database)
  • Digitally signed, f) carries the keys and server information
  • Allied with a unique and secure identifier

In the simplest possible terms, a Ricardian Contract is a document defining a type of value for issuance over the Internet. It identifies the Issuer, being the signatory, and any terms and clauses the Issuer sees fit to add in to make the document stand as a contract.

The same document has to be both readable by people and parsable by programs. The Ricardian Contract is formatted as a text file that can be easily read (displayed or printed), and programs can convert it into internal forms for searching for name-value pairs. It includes a special section for each type of contract, such as bond, share, currency, etc. Further sections within describe, in program-parsable terms, usage of decimal points, titles, and symbols.

As legal signatory, the Issuer signs the document in the OpenPGP cleartext form with his contract signing key. He includes the full chain of OpenPGP keys within the document to permit programs to directly verify and authenticate.

To uniquely identify the contract, any user can calculate a canonical message digest over the clearsigned document. This message digest is included in all records of transactions, and provides a secure (unforgeable) link from the document to the accounting of the issue.

For example, e3b445c2a6d82df81ef46b54d386da23ce8f3775 is the full message digest for Systemics Inc's issue of prepaid services dollars. Commonly called a hash, the message digest is a cryptographic technique to create a relatively small number that is one to one with the document. That is, for each document, there is only one hash, and the hash refers uniquely to that document. The algorithm is the well-known standard, SHA1.

Concern: The treatment of the Ricardian Contract as a contract may raise more legal questions than it answers. For example, is this form indeed a contract? How do distinct jurisidictions view the concept (common law, civil law, UCC, Koranic code)? Is this a negotiated or a form contract? When did the user accept the contract? How strong, or rebuttable, is the presumption that the user has the contract?

Social Contract

Quote.pngHow have a hundred men who wish for a master the right to vote on behalf of ten who do not? The law of majority voting is itself something established by convention, and presupposes unanimity, on one occasion at least.
— Rousseau - The Social Contract (1.5)

Quote.pngThe problem is to find a form of association which will defend and protect with the whole common force the person and goods of each associate, and in which each, while uniting himself with all, may still obey himself alone, and remain as free as before – this is the fundamental problem of which the Social Contract provides the solution.
— Rousseau - The Social Contract (1.6)

See also

Retrieved from "https://organicdesign.nz/wiki/index.php?title=Contract&oldid=122688"