We built something super useful on Ethereum. It’s called Contributor Credits, and it’s a financial tool that makes the compensation relationship between our company and our early contributors (of work) very clear, doesn’t dilute equity, avoids tax complexity, and gives contributors a stake in the company’s success. If you are interested in trying it out, you can reach me at firstname.lastname@example.org.
When we started our company, we needed a way to compensate people who helped build and design our MVP. We had only a little bit of cash, certainly not enough to pay market rate for work. Friends and even members of our extended network thought the idea was pretty cool and wanted to help, and in some cases they would have helped for free or at a steep discount.
But accepting free work didn’t feel right (in addition to creating some IP issues down the road). Everyone was fine with the idea that the whole project may fail and that none of us would get paid, but what if it succeeded?
The go-to answer here is equity, but the problems with promising equity to contributors are myriad. First, any discussion of ownership in a project at this stage borders on philosophical. You negotiate based on potentially very different estimates of the company’s value over an asset that may not have a market for years. What’s the difference between 1% and 10% of nothing? Second, the relationship with contributors is fragile and could change or end without warning. People get jobs, get bored, have kids. You don’t want to service a legal obligation to a person who was only around for a month, Investors don’t like when a long-gone team-member complicates the cap table, and the contributor herself doesn’t want the open-ended responsibility that comes with open-ended compensation.
We needed a compensation mechanism built for the following challenges:
- We didn’t have much cash.
- Contributors were perfectly happy not to get paid if we didn’t either, but would have felt very exploited if our project was successful and they still didn’t get paid.
- We wanted contributors to be able to come and go without complicating our cap table.
- We wanted to be really transparent — to tell people in clear terms what they would get and when, and let them agree to that with confidence.
We created Contributor Credits, written “C²”, using Ethereum (more on the blockchain parts later).
C² give early contributors a predictable stake in the success of our company in exchange for services being discounted up front. Each C² is a promise to pay the contributor one dollar (or any currency) upon a particular trigger, such as securing a round of investment or reaching a revenue target.
For example: If an entrepreneur pays 300 C² with a trigger of $1,000,000 in investment, then she must pay the holder of those C² $300 when her project raises $1,000,000 (or more). If the business never reaches the trigger, then it doesn’t have to pay.
The entrepreneur pays C² in the same fashion that one would pay cash — per project, per hour, per day, etc. — except that they pay more C² than they would dollars because of the risk that the business will not reach the trigger.
When a business promises C² instead of equity, it is putting a specific dollar value on the payout rather than telling the recipient that she will get some percentage of an unknown value at an unknown time. For that reason, the estimated current valuation should matter less and only the question of whether the company will actually reach the trigger valuation in the future should remain. And given that the company has an interest in avoiding large cash payouts all at once, there is good reason for the employee and the company to negotiate the conversion of C² to equity as the company grows and the value becomes more clear.
How we use it
We are now using C² to pay members of our team, and it’s working fantastically well. Here is how:
Setting the trigger:
We picked $2 million in investment (the amount raised, not the valuation) as the trigger, because we think that’s a good indicator of early success. Less than that wouldn’t indicate sustainable success, and wouldn’t provide the cashflow needed to fund the C². We also set $700,000 in 12-month trailing revenue, and a sale of the company as triggers. That way, there isn’t any way the company can be successful without hitting a trigger.
Paying out C²:
How many C² should contributors be paid? It has to be more than their normal dollar rate because they are taking a risk. We decided to take their normal rates, multiply those by three, and use that as the number of C² to pay. For example, a designer who normally charges $100/hour would charge 300 C²/hour. If the company reaches the trigger that designer makes $300 for every hour he worked. This mechanism has the added benefit of letting us mix cash and C². Say one of our engineers (normally $100/hour) needs to be paid at least $20/hour in cash. We can afford to pay that $20, so we take the remaining $80, multiply that by three, and pay her $20 and 240 C² per hour. In this way, we base the compensation negotiation on the real market value of the contributor’s work.
Funding the C²:
When our company reaches any of the triggers defined above, it’s obligated by a legal contract attached to the smart contract to “fully fund” the smart contract. This means that we have to send an amount of money equal to the total number of C² that have been paid. If we pay 10,000 C² to one contributor, and 5,000 to another, then we would be obligated to send $15,000 to the smart contract when we reach the trigger. The holders of those C² can then cash them in.
Partially funding C² (advanced):
It is possible for our company to, at its option, “partially fund” the C² before the trigger is reached. Say for example that we raise $1 million. We may decide that the good-faith thing to do is fund the C² 50% (or 50 cents per C²). Any of the contributors can cash in some or all of their C² at that point and receive $0.50 for each, or they can choose to hold on to them until the company reaches the trigger. Once we put funding in, we cannot take it out, so the contributor is guaranteed to get at least $0.50 for each of her C² whenever she chooses to cash them in. We like this mechanism because it doesn’t force a choice on the contributor. She can just let the money sit there if she wants and know that in no case can the value drop.
Trading C² for equity (advanced):
It is possible for contributors to “relinquish” C²; to send them back to the smart contract without cashing them in. The contributor might want to do this in exchange for some other form of compensation, such as equity. In fact, part of the idea is that the contributor’s negotiating power for equity increases with the company’s obligation to fund her C²s. Investors probably don’t want us paying out $200,000 immediately after they give us $2 million, so contributors with a lot of C² are in a good position to ask for equity just before a round of funding. Our plan is to let our larger contributors use the C² to pay for shares at the market rate set by the round (with one C² equalling 1$ towards a share). A the same time, the company is in a position to keep long-gone contributors off of our cap table.
The blockchain part
Each C² is an ERC20 token on the Ethereum blockchain. Once it is created, it is a permanent and public record. No one can delete them, and it doesn’t matter if our company goes out of business. As long as the Internet exists, so do the C². (This is the reason we used blockchain technology)
To create a class of C² — a class is a group of C² with the same issuer and the same triggers — you use our interface to first publish a smart contract on Ethereum (the smart contract terminology is misleading, it’s really more of a small program), then “establish” that contract by inserting a hash of a standard legal agreement (longer discussion of this legal agreement below). You can download a copy of this agreement and, at any time in the future, confirm that it is the original text by checking it against the hash stored in the smart contract. This is what permanently binds the legal text to the smart contract. The combination of the two is what constitutes a class.
Each C²/token is created by this class. When the project/business owner wants to pay C², she instructs the smart contract (using our interface) to create and send the C² to the recipient. The recipient holds them in an Ethereum wallet. The smart contract keeps track of the number of outstanding C², but it doesn’t care who has them.
To fund the C², the project/business owner actually sends the funds to the smart contract, not to the C² holders. The C² holders can then send some or all of their C² to the smart contract, which sends back dollars proportional to the amount the smart contract has been funded; if the project owner has funded the smart contract only 70%, then the smart contract sends $0.70 to anyone who sends it a C² (note that C² holders can send their credits to the smart contract at any time, including before it’s fully funded). This is why we say that the project/business must “fully fund” the C² when the trigger is reached.
A few key technical points:
- A smart contract cannot send actual dollars (not yet at least, the Fed is working on a digital dollar). Instead, we send “stablecoins,” crypto currency that is pegged to the dollar. Users can easily exchange stable coins for USD on exchanges like Coinbase.
- For now, we are blocking transfers of Contributor Credits because we don’t want our customers worrying about accidentally creating a secondary market for the C² they pay.
- Technically, users can make promises denominated in any currency, not just dollars. They could use bitcoin, a Euro stablecoin, or anything else. Our frontend interface, however, will only support a handful of options to discourage users from denominating C² in shady cryptocurrencies (tokens that are obscure, untested, or have questionable backing).
The legal part
It’s helpful to think of each individual C² as a deferred compensation contract worth $1, except that one can pay out these contracts without the parties having to sign each contract every time. We did this by making the legal obligation to fund the smart contract, not to pay the contributor. To understand how this works, it helps to understand how a “class” of Contributor Credits is created.
To set up a class of C², the issuer uses our interface to fill out legal text that precisely defines the triggers. The user simply selects the amount and currency of each of the triggers, and the token they will use the to pay the obligation, often a “stablecoin” like DAI or USDC (we call this the “Backing Token”). We populate the rest of the text with the user’s business information and the address of the associated smart contract (among other things).
As described above, the contract obligates the issuer to fully fund the contract when their business reaches the triggers. Legally, we define “fully funded” using a function built into the smart contract. The ‘isFunded’ function returns “true” when the amount of Backing Token equals the number of C² outstanding. The contract specifies that the issuer must make a payment or payments of the Backing Token to the smart contract until the ‘isFunded’ function returns “true.”
Put simply: When the business reaches any of the triggers, it must keep sending money to the smart contract until ‘isFunded’ turns true. That’s the only obligation.
The contract built into our system currently is the one we used for our own team. You can read it here. (Please note that this contract is also an “alpha” and we are constantly working with our lawyers to improve it)
The only way to get the money back out of the smart contract is to cash in the C². For a fully funded smart contract, 1 C² = 1 Backing Token. The holders of the C² can cash in as many C² as they like, whenever they like.
Note that Contributor Credits should be used in conjunction with some other documentation of the contributor’s work, such as a consulting agreement or an invoice, that specifically mentions C² in the payment terms. This ensures that a contributor is a party to the Contributor Credit Contract.
A few key legal points:
- Our company doesn’t maintain and issue Contributor Credits on behalf of our customer, we simply provide a toolset for our customers to create and manage their own tokens.
- Contributor Credits DO NOT include a technical mechanism for ensuring that the business is honest about whether or not hit has reached the trigger. We rely on courts for this. A contributor would certainly have the standing required to insist that a business disclose its status vis a vis the trigger.