Federated Bookkeeping is the vision of connecting existing bookkeeping systems together.
It uses peer-to-peer messages to connect economic agents, independent of any central
In that sense, it basically builds
credit networks on top of
The bookkeeping messages replace the communication function of payments / currencies / money,
but payments are still used to allow trade with strangers.
Payments are taken out of the critical path of day-to-day business, but their role as an insurance
Bookkeeping messages are potentially much more efficient, expressive, and powerful than the
price signals carried in payments.
They allow coordination of
trade, cooperation, trust, credit, production triggers, and footprint reduction.
A common (status quo) situation for a business organisation or a human being is to use a mix between human memory and regular (non-federated) bookkeeping
to keep track of value flows, and then to use monetary payments to settle these flows.
Federated bookkeeping has several advantages over this.
In the short term, organisations and individuals who adopt federated bookkeeping (for instance, e-invoicing, federated timesheets) can get paid faster,
reduce errors, and reduce effort / personnel costs. The federation protocols take over tedious work from communication flows that would currently involve
human work and manual data entry.
Linked books will also offer the ability to communicate more relevant information like liquidity or fluctuations in output in real-time, depending on the
demand and proximity of both parties.
In the medium term, having more real-time data about the source and after-sales of your business will make you more conscious of the footprint of your actions.
This will hopefully lead to more informed, conscious and harmonious decisions around the social and environmental impact of business activities.
Shareholders generally want return on investment without too much consideration of what economists call "externalities".
In the long term, more transparency can lead to more trust in the supply chain, and more use of supplier credit (e.g. "pay this invoice in 90 days from now").
More mutual credit means less financial loans and less
shareholder primacy, meaning the team working on a project has more freedom to take conscious business decisions without referring to monetary profit as the
ultimate goal of any activity. Federated Bookkeeping can therefore be a tool that helps the Degrowth transition.
Also, as adoption of federated bookkeeping increases more and more, credit and debit can cancel each other out through third parties thereby increasing
the time until a settlement with anonymous currency is necessary, and further decreasing dependency on anonymous currencies.
Decentralisation of Power
Centralised power can lead to monopolies and rent extraction. Federated data architectures
(Personal Data Stores, Personal Cloud Servers, Federated Social Web, Local First, Federated Bookkeeping)
are therefore preferable over centralised data architectures. Even community currencies are generally administered by single-instance computer systems
and could (as Ryan Fugger already proposed long ago) be replaced with federated (multi-instance)
Guest Lecture at CERN about Federated Bookkeeping
Local credit networks
World Ledger Gossip
One approach to federated bookkeeping is world ledger gossip: nodes in the network gossip with each other
about transactions that happen between parties, and that together make up the world ledger. Each node has
only a partial view of the world ledger, so unlike in blockchain systems, no complete consensus is reached
(see also how gossip is used in for instance HoloChain and
The events this gossip reports on would have to be modeled in such a way that they can be meaningfully
compared and interrelated, so although it's always hard to pick a model and not end up bikeshedding about it,
a transaction on the world ledger would probably have the mandatory fields
"id", "from", "to", "date", by which transactions can be uniquely identified, located, and partially ordered on the world ledger.
When gossiping about a transaction between accounts at different network nodes, there will often be two representations of it: one
at the sending node and one at the receiving node.
Sometimes these are called two transactions (one on each account statement) that
together represent a transfer. In this context we don't model the account statement entries as objects in their own right; instead,
they are both a form of gossip about one single event (one transaction from Alice to Bob, or equivalently, one transfer from Alice to Bob).
A multi-hop chain of transactions (hops, transfers) is sometimes called a single transaction; for instance
Interledger assumes all transactions are multi-hop chains of local ledger transactions which
themselves are called (single hop) transfers, to distinguish them from (multi-hop) transactions. But since in current-day accounting
multi-hop is still an exception, on this website, we'll use the word "transaction"
to indicate a single hop, and use a word like "chain", "loop" or "cycle" to indicate when these transaction are linked into a multi-hop
or circular group.
Without a global view of the ledger it would be impossible to calculate a global balance, but using optional fields "amount / unit"
and "state" (confirmed, proposed, declined, etcetera) would allow the calculation of a local payable / receivable / current balance,
like in SNAP. With fields like "description" or "data", transactions could be
linked to off-ledger events, and transactions could also link to each other on-ledger to establish a complete ordering of accepted
transactions, and/or to indicate when two hop transactions form part of the same multi-hop chain or cycle.
Apart from transactions, a bookeeping system would generally also model Purchase Orders, Invoices, Cost Centers, Loans, Mortgages,
Shipments, Stock, etcetera. If a supplier and a customer both have a bookkeeping system (most companies and even many individuals do
have a bookkeeping system of some sort), then they can federate their bookkeeping systems
('connect their books') to make changes in
one system immediately show up in the other system, thereby greatly reducing the friction and miscommunication in everyday trade.
Since Federated Bookkeeping is not in itself a digital asset, participation in the world-wide
bookkeeping network does not require a Money Transfer Agent license.
Solid's MoneyPane is a first implementation of a
simplistic bookkeeping system that supports Federated Bookkeeping. It is still under construction.
The design consists of several components:
- Ledger, using Synchronized Network Accounting Protocol (SNAP)
- Synchronized Purchase Orders
- Synchronized Invoices
See the Network Money mailing list for a discussion forum
around the topic of Federated Bookkeeping.
See the GitHub repo for this website if you
want to propose changes to the HTML content of this website.
See the blog page or our medium account for blog-posts about federated bookkeeping.