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.
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:
- Simplicity & Transparency: Anchors should be as concise, narrow, and simple as possible. They should be easy for participants to understand and trivial to maintain.
- Automation: The best anchors move assets and liabilities on-chain automatically.
- 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.
- 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.
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)
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.