Home › Blog › Credit Commons Protocol

The Credit Commons Protocol Explained: Interoperability for Mutual Credit Networks

What the Credit Commons Protocol is, how it enables mutual credit networks to trade across boundaries, and what it means for operators building community currency systems today.

The silo problem in mutual credit

Mutual credit networks work on a simple premise: members create money by trading with each other, and credit circulates within the group. A freelance designer earns credits from a plumber. The plumber spends those credits at a local farm. The farm hires the designer. No external currency required.

The model is resilient and community-owned — but it has an inherent ceiling. Every network is an island. A member of a time bank in Barcelona cannot trade with a member of a LETS group in London. A worker cooperative that uses an internal mutual credit system cannot accept credits from a neighbouring solidarity economy network, even if both groups share values and would benefit from the connection. Each network ends at its own membership list.

This silo problem is not technical — it is a lack of shared standards. And that is exactly what the Credit Commons Protocol is designed to solve.

What is the Credit Commons Protocol?

The Credit Commons Protocol is an open API standard that lets separate mutual credit networks exchange value across their boundaries. Think of it the way you think about email protocols. Gmail and Outlook are completely different software systems run by different companies, but they can send messages to each other because they both speak the same underlying protocol (SMTP). You do not need a Gmail account to receive an email from a Gmail user.

The Credit Commons Protocol does the same thing for mutual credit. Two networks running different software, governed by different rules, in different countries can still transact — as long as both speak the protocol. The credits do not teleport from one ledger to another; instead, the networks hold a bilateral credit line between themselves, and transactions are settled across that line according to rules both sides agree to in advance.

The key concepts: nodes, trunks, and bilateral credit lines

The protocol is built around a tree-like structure of network nodes. Each participating network is a leaf node — it has its own members, its own ledger, and its own governance. Leaf nodes connect to a trunk node, which acts as a clearing house between them.

Between any two nodes — leaf-to-trunk, or trunk-to-trunk in a larger federation — there is a bilateral credit line. This is an agreed-upon limit: how far can one network go into debt with another before transactions are blocked? The credit line is negotiated between network operators, not imposed by any central authority. Each network retains sovereignty over its own membership and its own internal rules.

When a member of Network A wants to pay a member of Network B, the transaction travels up to the trunk, the trunk checks the credit lines, and if the limits are within bounds, the transaction is recorded on both ledgers simultaneously. No intermediary bank. No conversion to fiat currency. The protocol handles the accounting; governance stays with the communities.

What it enables in practice

Imagine a time bank in Barcelona — call it Xarxa Temps — whose members exchange hours of care work, tutoring, and home repair. Across the channel, a LETS group in London — call it Southwark Exchange — runs a local currency for small trades: food, crafts, repairs, lessons.

Both networks have members who travel or work remotely. A translator in the Barcelona network does work for a member of the London network. Under the current siloed model, that transaction cannot be recorded in either system. The translator either works for free or steps outside the mutual credit economy entirely.

Under the Credit Commons Protocol, Xarxa Temps and Southwark Exchange establish a bilateral credit line. The translator earns London credits that are cleared against the line. Both ledgers update. The value stays inside the solidarity economy instead of leaking out to conventional payment rails.

Scale this up: a federation of twenty networks across five countries, each retaining its own membership criteria and governance, but able to trade at the edges where their communities overlap. That is the long-term vision the protocol is designed to support.

Current state of adoption

The Credit Commons Protocol is an emerging standard. The foundational design work was led by Matthew Slater, a longtime researcher and practitioner in complementary currencies, along with collaborators in the mutual credit and commons finance space. The protocol specification is open and publicly available.

As of 2025, adoption is in early pilot stages. A handful of networks in Europe have explored federation experiments. The protocol is not yet widely deployed at scale, which means operators building today are working at the frontier — they have the opportunity to shape how interoperability gets implemented in practice, rather than inheriting decisions made without them.

The important thing for operators to understand is that the direction of travel is clear. Interoperability between mutual credit networks is coming. How quickly depends on how many networks build on compatible foundations from the start.

What this means for operators building today

If you are launching a mutual credit network now — a time bank, a LETS group, a cooperative currency, a professional skills exchange — the protocol question matters even before your first transaction clears.

Building on proprietary infrastructure with closed data formats means a migration cost later, when your network is ready to federate. Building on standards-compatible software means you can add interoperability when your community is ready, without rebuilding from scratch. The architecture decision is low-cost today and high-cost to undo later.

There is also a governance question embedded here. Some networks will want to federate broadly and connect to as many other networks as possible. Others — particularly those built around a specific profession, geography, or community identity — will want to remain closed-member systems where the operator controls who can join and which external networks, if any, to connect to. Both models are legitimate. The Credit Commons Protocol supports both: federation is opt-in at the network level.

This is part of the design philosophy behind Denarii. Operators get a closed-member system they control — membership approval, credit limits, exchange rules — built on an architecture that does not lock you out of future interoperability. You decide whether and when to open a credit line with another network. That decision belongs to your community, not to the software vendor.

Building for the long game

The Credit Commons Protocol matters because the mutual credit movement has always had a federation problem. Individual networks can be robust and well-governed, but their economic impact stays local. Real resilience — the kind that lets communities weather disruptions to conventional supply chains and financial systems — requires networks that can trade across boundaries while preserving local control.

The protocol is the technical infrastructure for that future. It will not replace the social work of building trust between communities. It will not write your membership agreements or your exchange rate policies. What it does is remove the technical barrier so that those human decisions are the ones that matter.

For operators starting today: understand the protocol, build on compatible foundations, and keep your governance options open. The networks that will matter in ten years are the ones being designed with federation in mind right now.