This is the second in a series of articles looking at the development of Mutual Credit Services (MCS), whose mission is to help build local mutual credit ‘clubs’ in the UK and overseas, and to link them together to form a global moneyless trading network – the ‘Credit Commons’. Here we provide a basic explanation of the Credit Commons Protocol. We want to make all this information accessible to a general audience. Most people have no interest in code, apart from knowing what it can do.

At Lowimpact.org, we’ve been talking about the potential for mutual credit to bring about necessary, large-scale change for three or four years. Mutual credit is a tool that can help decentralise the economy, boost small businesses at the expense of multinational corporations, build community and shrink the power of banks. Together with associated ideas, it can form the basis for a new kind of economy.

Members of the Lowimpact.org co-op are involved with Mutual Credit Services. We’re often asked about the current state of play, and so we’ve put together a series of 6 articles to explain what progress we’ve made.

Here’s the list of articles:

1. Introduction:
   Covid, the birth of Mutual Credit Services, and building a team.
2. Basic explanation of the Credit Commons Protocol:
   The Credit Commons is the mechanism by which mutual credit and other groups all over the world can be connected to form a new global trading system – presented in an easy-to-understand way.
3. Business-to-business ‘Trade Credit Clubs’ and credit clearing: A very simple way to introduce the mutual credit idea to small businesses – trade credit, something they’re already familiar with.
4. Local authorities & anchor institutions: Introducing the concept to local authorities – as a way to help their local businesses that are having cashflow problems.
5. Community groups & individuals: How to allow community networks and individual consumers to play too!
6. Investments, savings and location: How to develop non-extractive, interest-free savings and investments in communities, alongside mutual credit trading; and why physical location is important.

2. Basic explanation of the Credit Commons Protocol

Thomas Greco coined the term ‘Credit Commons’, to describe a global system of mutual credit networks linked via a protocol. Here’s a (non-technical) explanation of the Credit Commons Protocol. If you think of a game, like chess, then the protocol represents the rules of the game. It can be written down in a non-technical way, that describes how to play chess. People have played chess by post, with pencil and paper, speed chess, chess where the pieces are human, with many different kinds of chess boards and pieces – and in Star Trek they even played something called ‘tri-dimensional chess’. But the rules (in our case, the protocol) still apply to all these different versions of the game. If you’re not using the rules, you’re not playing chess – you might be playing something else, like draughts (checkers, for Americans).

The rules of the Credit Commons game are:

1. If you want to trade with somebody, you have to already be in a club; and members of the club have to have agreed about credit limits.
2. When you want to trade, you say so in a certain format, like: I want to owe that person this much – and the other person has to agree.
3. If you want to stop trading, you have to bring your balance back to zero.

So in the chess analogy, a Mutual Credit Club is like a chess club. Members agree to come together around a protocol. They can add a lot of things on top of the protocol, depending on their own preferences and agreements, how their software works, their fees, their name, logo, website etc. But if someone turns up from another country, they’ll immediately recognise it as mutual credit, in the same way that a chess player would recognise chess, and be able to join in, whatever colour or size the chess pieces are, or whether it’s speed chess etc. But if you decide that in your chess club, each player has two kings, then you can’t join in with international chess tournaments, because it’s not chess any more. The rules of chess are controlled by the World Chess Federation, who don’t ‘own’ chess – they just look after the rules about what chess actually is, and make it possible for anyone to play against anyone else. There will be a similar group controlling the Credit Commons Protocol for global mutual credit trading.

So now we can see two layers to the system: the Protocol – the fundamental rules – which everyone in the space has to agree on; and the Implementation – the specific local culture/agreements layered onto the Protocol. Implementations can vary wildly, without breaking up the system, as long as they can speak the language of the Protocol, so that different groups can interact with confidence.

The Protocol itself is written in plain English – or at least logical English. It’s like the rules of chess that come with the chess set that you buy. This is public property – ‘Open Source’ – anyone can use it freely. If you understand open-sourced code, you can see the Credit Commons documentation and repository on GitLab (which also includes ways to ask for help if you get stuck). You can even copy and alter it to make your own version; no-one will stop you – although groups using your altered version may not be able to interact with others. If you don’t understand open-sourced code or Gitlab, don’t worry, we can sort out that side of things for you. 

To be useful, and able to connect with accounting software (such as QuickBooks) and payment gateways (equivalent to Paypal), the ‘plain English’ Protocol also needs to be stated in computer code – in software. The modern way to do this is to make two sets of code – the ‘back end’ (an Implementation of the Protocol) and the ‘front end’ (the app that a user will see on their screen). Things are set up this way so that the front end can adapt to local needs (like local chess clubs), while the back end can be as simple and robust as possible – doing nothing else but implementing the unchanging Protocol (the rules of chess).

The back and front ends need to interact, of course – instructions from users need to be interpreted as actions defined by the protocol. (As with the chess example, clubs can choose to have different ‘front ends’ – for example, one might be an ordinary chessboard; another might be a computer screen; another might be an entirely text-driven system, where a player types things like ‘Knight to King’s Bishop 3’. For the back end to know exactly what move is intended, any action, whether on a board, a screen or via text, has to be converted into a description that it will understand. What’s required to do this conversion is an API (application programming interface). Again, this is free and open-sourced and available on GitLab. This makes it possible for programmers to write their own implementations of either back-end or front-end code (or both), in confidence that their code will be able to interact with other Credit Commons implementations. Again, non-techies needn’t worry about this. 

At that point, we had the Protocol, the API, and a reference implementation of the back end – the whole accounting system machinery, including the ability for ledgers to interact, but not the front end software so that people could actually create transactions. Another member of the team (Chris Reay) provided that for us.

Next week: ‘Trade Credit Clubs’ and credit clearing: A simple way to introduce the mutual credit idea to small businesses – trade credit, something they’re already familiar with.