There are many different ways of accounting and things to be accounted for; Despite its simplicity, I've had some difficulty in the past explaining mutual credit accounting, even to educated people, so this blog is an attempt to express it clearly, for the record.
Credit commons is a way of recursing mutual credit accounting. A mutual credit ledger contains a list of accounts and transactions between them, denominated in a common unit of account. There a no assets 'on' the ledger, nothing ever enters or leaves the ledger. It is purely a record of credits and debts between the accounts. For that reason I sometimes think of it as 'closed' accounting.
When a debt is incurred between two account holders, say for 10 units, the debtor's account is decremented by 10 and the creditor's account is incremented by 10. Thus the sum of all accounts on the ledger never departs from zero. When an account's balance = zero that means it neither owes nor is owed by anyone else on the ledger. If the system is being used as a medium of exchange, zero means that that the user's exchange is complete, that their debts cancel out their liabilities, that their production and consumption are balanced with respect to the other accounts.
As a medium of exchange system there is usually a minimum and maximum balance for each account to prevent them straying too far from equilibrium and reduce their risk of their not being able to return to zero.
If accounts are not returned to zero, or stray to far from zero then the system can become distorted, with members struggling to earn or spend the units, or perhaps trading them at a discount or a premium.
That is why, in the event of an account holder departing with a positive or negative balance, the account must be returned to zero before it can be closed, which means the surplus or deficit must be shared out between other account holder according to some pre-arranged system. Typically there might be an account for that purpose which could collect transaction taxes, membership fees, or even redistribute prizes in case of a surplus.
Another way to think about mutual credit is as a rolling contract. All signatories agree to return their accounts to zero, and the ledger simply records their obligations to earn or spend before they can withdraw from the contract.
Credit Commons accounting means joining existing accounting systems together using the Credit Commons mutual credit protocol. In order to participate in a mutual credit system a would-be member needs only
The same applies when a local currency project opens trade relations with a neighbouring group, or better still, a coalition of groups which has already set up its own ledger. Instead of entering into bilateral relations where trade must be balanced within every trading pair, mutual credit is a multilateral system, which means each group maintains a single balance of trade account with respect to all the other members.
The new group prices its goods by declaring a conversation rate between its own unit in which its members' goods are priced and the coalition's unit. The coalition then grants the new project a credit limit.
All inter-group transactions go across the shared ledger, which both enforces balance limits and acts as a third party record. The shared ledger therefore reflects the balances of the balance-of-trade accounts (BoT) of all its members, the sum of which is zero.
So let us track a payment of #10 from Alice in Aylesbury to Bob in Brixton, where Aylesbury and brixton are both members of London.
| Alice -10 | BoT +10 | BoT -70 | Bob +70 |
| Aylesbury -10 | Brixton +10 | ||
Note that Brixton's unit is not worth #1, but 1KWh so the debt is converted in the same way that kilometers are converted to miles, by multiplying. Each system must have a chance to validate the transaction to sure that its internal balance limits are respected. For example Bob or the Brixton account in London may already be near their maximum balances. Note that even though Brixton in London and the BoT account in Brixton are effectively mirror images of each other, nonetheless they could have different balance limits, and either could block the transaction. If the account balances ever didn't match, for any reason, Brixton would not be allowed to trade until the discrepancy was ironed out.
This was just a quick technical description, but a much more interesting subject I shall cover soon is the economics implied by this way of accounting as opposed to fiat money and free market exchange.
Comments4
Thanks for this, Mat!
Thanks for this, Mat!
Since a while now, I find it useful to see mutual credit accounting as a better way of understanding money in general. (Whereas many people think of certain instances of mutual credit systems) For me that was a big aha, but I still can not say what the deal is. What is the merit of this perspective? Does it make any new predictions? I only have a feeling of this view must be very useful for something. Because they keep myself thinking about that, I am very grateful for your posts. <3
Marvin
Let me struggling try to explain, what I mean by this perspective: 1. Bank money, can be seen as a special example of "Mutual Credit". Namely (without the mutual part) where only the bank is allowed to have a negative balance. The positive balances of customers accounts are called "deposits" (The "account" of the bank itself is usually not thought of as on the same level as the accounts of its customers, though). The unit of account is burrowed from central bank money.
2. Central banks are behave pretty much the same, but with their own unit of account (that is usually of undefined real world value). They are in the same role as "London" in your example, when "Aleysbury", "Brixton" etc. were private banks.
3. In a hirarchical structure of nested mutual credit systems (like central banks and private banks, or like in your example), with a conversion of the involved units of accounts, one could also see the whole thing as one big mutual credit system. This, however, may ignore/distract from the restricting rules of the different layers. Like in your example. This relates for instance to the confusion about the meaning of the TARGET2 balances.
4. Similarly one can use any partition of the set of accounts in a MC system to construct a hierarchy out of it. For each part we introduce a new MC system. All the accounts in that part are now considered as accounts of this lower level MC system. Because they wont add up to zero by default, a new account needs to be introduced, that mirrors the in-debtedness of this subcommunity (like BoT in your example). The top layer MC system has only one account for each part/subcommunity.
I think of it not only in the sense of literally splitting off the ledgers, but alternatively in a merely conceptual sense. For example, one can partition all accounts into say "private households", "companies" and "the state", to derive insights on the debt and trust relationship in between them.
5. One could even stretch this notion so far as to see physical commodity money like gold as an instance of MC. Here the nature account is the only one that can go negative and the amount of gold in existence constitutes its credit limit.
6. Note that in most of these examples, there is only one account, the account of the issuer, that can go below zero. In the other cases there is also a single entity constituting the credit limits. Therefore, examples of mutual credit with mutually agreed upon rules for credit and debit limits are truly generalizing our current monetary system.
Hey Matthew, thanks for
Hey Matthew, thanks for writing this article!
I want to share some thoughts I had, mostly about conversion between different units (or possibly bridging between communities). This is something I dealt with in the initial design sketches for Offset, and also in the recent protocol design.
1. The problem of rounding: In most cases two units of value will not map 1:1, and some multiplicative constant will be required for conversion. As you will keep accounting of balances up to only certain amount of accuracy, this means that some value will be lost during the conversion/multiplication. A bit different kind of problem occurs when the units differ in granularity. For example, if the smallest amount of value you can express in one currency greatly differs from the smallest amount of value you can express in another currency.
2. Arbitrage and negative cycles: Conversion rates between different units of value depend on external events that are beyond the control of the mutual credit network. This means conversion rates should be updated in a real time fashion, or otherwise smart users will be able to find "negative cycles" in the network and exploit them to make "free money".
3. Federerated discovery of routes: If you ever plan to allow different communities to federate, and send value along longer routes in an automatic fashion, you might want to allow discovery of routes with multiple conversions of units along those routes. I attempted to find a sound way to do this that is also reasonably decentralized, but never managed to solve this. For example, if you let everyone advertise their conversion rates, and set up servers that collect all of those rates and find good routes, you might run into Denial of Service issues: I could open a new member, and advertise that I exchange 1 USD for 100 EUR, but I will never actually do that. Everyone will want to send their money through this new member I created, which will cause the whole system to halt.
For the design choices I have taken: In the current design of Offset it is not possible to make transactions that involve more than one currency. In addition, index servers (Servers that find routes of flow for credits between nodes) will only provide routes contain single currency. In other words, there is no built in discovery for currency exchange prices.
That said, the protocol does allow exchange of two different currencies in atomic way, but this has to be done manually. You have to find someone that is willing to be paid X units of currency A in exchange for Y units of Currency B, and you can make the swap in atomic way.
One last thing I had in mind is (cryptographic) auditability of transactions.
I think that it could be cool if the ledger of transactions you made could be somehow audited. In other words, making invoices and receipts created using this system some kind of an official document, with a cryptographic signature, and possibly incremented numbering, like we do with real invoices. This could really help convincing tax authorities that this is "good money" for the state. Instead of helping people to evade taxes, it will help people to keep everything neat and tidy, and you will not have to keep chasing people for their paper invoices, like we do these days (At least this is what I'm doing).
I dedicated some time to think about how to do this, hope to share a more serious documentation soon.
Member for
16 years 1 monthMarvin I agree with you that
Marvin I agree with you that it is possible to view the whole money system as a one big mutual credit, and also that it is a helpful perspective. It shows what a privileged position banks are in, and how money is an expression of trust more than a commodity.
This perspective could also help to make sense of MMT (Modern Monetary Theory) in which governments create money 'out of nothing'.
Member for
16 years 1 monthThanks for your comments Bar.
Thanks for your comments Bar.
1. Rounding is a problem mathematically, but I'm not sure its important to chase tiny fractions of pennies for payments, especially because they don't all accumulate somewhere, but more likely cancel each other out. Is it fair to say that all calculations be done to 5 decimal places, even if the end user only sees integers?
2&3. In a credit commons tree there is only one possible 'route' between any two accounts so routing isn't a problem and nor is arbitrage. See my earlier blog for a more detailed understanding of the difference between Credit Commons and mesh credit protocols.
What I haven't talked about here, because it is more 'economics' than 'accounting' is the preference for fixed exchange rates. This is the opposite to how most systems work in this post-bretton Woods neoliberal era. Do read up on Mundell's trilemma if interested.
With fixed rates, credit can be 'converted' as miles to kilometers rather than bought and sold, as long as any group's credit stays within the agreed margins.