Cooperativ
Published in

Cooperativ

Procedures vs. Contracts: a new(ish) agreement paradigm

Cooperativ Labs proposes using blockchain to create a new, more efficient, and more flexible approach to common business agreements, much in the same way Decentralized Autonomous Organizations (DAOs) already do.

Note to lawyers: the concept described below is not an attempt to replace law with code, but to create a superior user experience for otherwise standard contracts. Producing, reviewing, and signing legal documents, over and over, for every new relationship, is a horrible experience.

From describing rights to upholding a process

Traditional agreements — legal contracts — are designed to be enforced by a third party during a dispute event, and therefore focus on describing each party’s rights. If you agree to split revenue from a project with a business partner, for example, one of the parties typically has the power to distribute the first party’s share. If that distribution doesn’t happen, a third party (usually a court), has to arbitrate and ultimately enforce the agreement.

Procedures by contrast, can be enforced continuously: they do not position the parties to adjudicate disputes, but instead, uphold a process. They do not describe the parties’ rights, but rather, the parties’ powers in the process. A simple example might be a program that manages revenue according to “flows” that creators configure up-front. They could then establish a procedure that gives each party the power to vote on any proposed changes to those flows. This makes it possible to modify the “agreement” over time, while offering the parties a clear understanding of their power to influence those modifications.

Note: This kind of fund management is already common in DAOs. We are proposing that organizations that aren’t decentralized or autonomous should still use procedures.

Reducing reliance on courts

This approach to agreements does not rely on third-party adjudication and is therefore more suited to teams that want to get to work quickly, across borders, and without reliance on national court systems. Say, for example, that a team wants to make sure the person paying share tokens can’t dilute the other collaborators by sending lots of tokens to herself. A procedure could require a majority of current token-holders to approve payments to any new wallet address, giving them the power to prevent the creator from making herself a token recipient. A traditional legal contract, by contrast, doesn’t have this built-in enforcement. The collaborators would therefore have to take the creator to court, possibly in a foreign jurisdiction, if they suspect her of violating their agreement.

Increasing flexibility

Procedures, unlike traditional contracts, do not have to anticipate all the potential future outcomes of the relationship. Instead they specify what powers the parties will have to address those outcomes when they emerge. Our creator from the previous example may discover that she needs to set up another recipient wallet to cover expenses, and a majority of current token-holders could choose to approve it.

Anchors facilitate Procedures

Procedures only work if the assets they manage are on-chain, and most business assets are not. We therefore must connect the chain to the off-chain asset (or liability). We call this mechanism an “anchor.”

A simple example of an anchor might be a legal contract stating that a certain percentage of a business’ revenue must be sent to a specific smart contract address (see diagram above). In this case, the legal text could be short and clear, while the on-chain mechanisms could describe and execute complex agreements.

This legal contract could be paired with integrations. Revenue generating platforms such as Spotify, Steam, or Patreon (or an intermediary built for the following purpose) could offer configurations that send the business’ revenue to the contract directly.

We can judge an anchor’s quality using the following parameters:

  1. Simplicity & Transparency: Anchors should be as concise, narrow, and simple as possible. They should be easy for participants to understand and trivial to maintain.
  2. Automation: The best anchors move assets and liabilities on-chain automatically.
  3. Trustability & Predictability: The traditional economy is run by centralized parties, so getting assets from that economy on-chain will usually be a centralized activity. The more trustworthy the anchor party is, the better.
  4. Coverage: Ideally, it is impossible for any party to route value around the anchor. It would be destructive, for example, if a game studio could avoid its obligations to contributors simply by publishing content to a marketplace that directs revenue somewhere other than the studio’s smart contract. This sometimes means relying on, or at least backing, an anchor with a legal contract a court can enforce.

An Illustration

Imagine a small company working with a number of collaborators to build a prototype of a game they plan to sell on the Steam marketplace. There are two full-time founders. The collaborators work part-time, but some may become employees if the company grows.

Let’s see how we can get through all the way through the first fundraise using only two legal contracts to manage compensation and ownership:

Part 1: Building MVP

To get started, the founders pay themselves and the contributors in Contributor Credits.

What are Contributor Credits?: Each Credit is a token that represents promise to pay $1 in the future when the business raises a certain amount of money or reaches a certain amount of revenue (we call this “the trigger amount”). The trigger is defined in a legal contract (the “anchor”), and the tokens are sent on a blockchain network.

Let’s say the founders set the trigger at $5m in equity financing, and that the business pays out a total of 300,000 credits. When the business raises $5m, it has a legal obligation to send $300,000 to the Contributor Credit smart contract. The Credit holders can then send each Credit they hold to the smart contract and receive one dollar in exchange.

It’s effectively an incremental deferred compensation agreement covering any a number of people, all “anchored” by a single, simple, two page legal contract, and managed using tokens on a blockchain

You can find lot more detail about our Contributor Credits here.

Number of legal contracts: 1 (the Contributor Credit Contract)

Part 2: Setting Founder Equity

The company deploys a Permissioned Exchange in order to manage equity ownership. After six months of working together, the founders are confident in their relationship, and decide to exchange their Contributor Credits for Share Tokens. Instead of negotiating their respective share, then signing contracts agreeing to relinquish the Credits, then receiving share certificates, they simply issue share tokens into the Exchange, and purchase them with their credits.

Number of legal contracts: 1 (the Share Token Contract)

Part 3: The Fundraise

(disclaimer: slightly oversimplified for illustration purposes)

One year later, the company is approaching a deal with investors to raise $6m (over the $5m trigger). Some of the original collaborators have agreed to join full-time, and they want equity instead of Contributor Credits. The company is happy to reduce the Credit obligation going into negotiations with investors, so they agree to let these collaborators purchase shares using their credits at the share price set by the investors. No new legal contract needs to be created. The founders simply configure the exchange to accept the Contributor Credits at a value of $1, and the permitted employees make their purchases.

Number of legal contracts: 0 (Uses the Share Token Contract from part 2)

Conclusion

Procedures allow us to narrow the footprint of traditional legal contracts, creating a much simpler user experience for otherwise complex agreements. By applying this concept thoughtfully, we can make it easier for DAOs to operate like traditional businesses, and for traditional businesses to operate more like DAOs.

Cooperativ.io is building on this insight one tool at a time.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jake Chase-Lubitz

Jake Chase-Lubitz

Product strategist who sometimes builds things. Founder of Cooperativ Labs.