In chapter 1 we introduced the concept of Mutual Credit, on which the ReSource protocol is built, and have outlined the way in which such systems are able to create their own commodity-backed currency in which interest-free credit can be extended.
We have shown how Mutual Credit networks allow their members to access liquidity, where and whenever it is needed, without them having to “rent” capital from 3rd parties such as banks, creditors or even investors. This of course raises an immediate and important question: If Mutual Credit systems are so consumer friendly, why haven’t they already out-competed established credit providers that aren’t generally known for their overwhelming friendliness?
Where’s the catch?
There are a few answers to this question, most of which can be backtracked to the way risk affects Mutual Credit networks. In short, traditional Mutual Credit networks are built in such a way that all network participants are exposed to the risks generated by all other participants. This means that the default of one member will directly affect all other members.
Later in this post we’ll show how ReSource has solved this problem, and a few other ones, to make Mutual Credit blockchain-ready. But first, let us explore why it is so challenging to contain risk in traditional Mutual Credit systems.
To do so, we need to go back to cryptography’s favorite triple: Alice, Bob and Carol.
In our previous post we have shown how Mutual Credit money is “spent into existence” once Alice overdrafts her account to purchase an item from Bob. Carol then does the same to purchase an item from Alice, closing Alice’s debt. Bob, the only one in the network with a positive balance, then uses his surplus to purchase an item from Carol. This returns all accounts in the system to 0, meaning no one owes anything to anyone and all obligations are fulfilled.
That is all fine and dandy, and works like clockwork, as long as Alice, Bob and Carol remain well-behaved little prosumers that are always willing and able to repay their debts in kind. However, what would happen if Bob tries to use his surplus of 100 credits to purchase an item from Carol, but Carol has nothing to sell? Since Carol is 100 credits in debt, she is technically obligated to accept Bob’s credits as a means of payment, but what if she refuses, or simply is out of stock, or worse: out of business?
In such a case Bob would be pretty much stuck with his 100 credit points, without being able to spend them. That’s tough luck for him, since he earned these credits when Alice purchased his services. Being unable to use his credits now means that he has worked for free. Alice, on the other hand, has already repaid her debt by selling to Carol and doesn’t owe anything to Bob. She may accept his 100 credits, or she may not, but no one in the system is now obligated to accept Bob’s credits, which debases their value.
Currencies carry risk
Bob’s example shows us that since Mutual Credit money is minted when credit is issued and destroyed when debts are repaid, unpaid debt results in inflation. If we enlarge this system to hundreds, or thousands of participants we can see how defaults debase the system’s currency over time, stealing everyones purchasing power.
Worse still, since this inflation is accompanied by less and less purchasable items (each default means that a vendor, Carol in our case, has left the system), we’re actually talking about stagflation, which is about the worst thing that can happen to an economy.
These dynamics are very familiar to anyone who has played around with community currencies such as LETS (local exchange trading systems). They all start optimistically, but ever so often deflate away over time, leaving its last members with heaps of unspendable currency.
This is the reason why Mutual Credit systems tend to grow slowly. Mutual Credit users need to trust that the network operator won’t allow bad apples to contaminate the network with excess risk, which is hard to get rid of once introduced into the system. It is this high degree of prudence, required to protect network participants from risky applicants, that often hinders the rapid growth which would be necessary to compete with the traditional financial sector.
The Gatekeepers
This brings us to our second problem. In most classic Mutual Credit systems, everything is “mutual”, except administration and gatekeeping. While the internal money supply is inherently decentralized, created “endogenously”, as a result of the activity of individual members - the system itself is controlled by a central administrator.
This administrator decides who’s allowed to join and who isn't. This may not sound all too different from how banks operate - they either approve your credit line or they don’t. However, there’s a big difference between banks and the gatekeepers of mutual credit systems. And dare we say the unthinkable - the former may be more accountable than the latter.
If a bank, or any other creditor for that matter, approves your credit line, they themselves will be on the hook if something goes awry. After all, if a creditor has lent you money and you can’t pay it back, it’s now the creditor’s personal problem. Gatekeepers of mutual credit systems are not in this position; if they let an uncreditworthy member join the network, it’s the network that pays the price, like Bob in our case, not them personally.
This is why we have built the ReSource Protocol
So finally we have arrived at the reason for which we have built the ReSource Protocol:
Mutual Credit has amazing features that could allow for the establishment of an accessible, fair and collaborative economy, while giving rise to stable currencies which are neither controlled by governments or corporations. However, to achieve these goals we need to address the following:
- Centralised and unaccountable administration
- Collectivised risk, spread across the entire network
- Slow growth
How this works exactly will be addressed in chapter 3 of this series, but to avoid dramatic cliff hangers, here’s a short summary:
The ReSource protocol has no centralised administration. Instead, protocol participants we call “Underwriters” form a distributed network that serves as a decentralised gatekeeping mechanism.
To join the network, new members must be assigned a credit line by an Underwriter. Following the logic introduced by PoS consensus algorithms, these underwriters need to stake SOURCE, the protocol’s utility token, to approve new credit lines. If this credit line defaults, the stake is slashed.
This confiscated SOURCE stake can then be used by the network to extract excess credit points from circulation and thus counterbalance inflation. This relieves network members from the credit risks of all other participants, and re-assigns them to Underwriters who have chosen to do so.
To understand how this is possible we’ll need another post, so stay tuned here and see you next week.
In the meantime,
Your friends at ReSource.