Most of the tools a community uses to trade are designed to take a cut. Not maliciously — just structurally. A percentage goes to a payment processor, interest goes to a bank, attention goes to an advertiser, and data goes somewhere nobody in the community chose. BeanPool is built to remove those exits.
Post-extraction means infrastructure that lets communities create and retain the value they produce, rather than having it captured by intermediaries. It is not a slogan about being nice. It is a constraint on how the software may be built — and things that would violate it don't get merged.
It is worth being concrete, because "extraction" is usually left vague. When a neighbour pays a neighbour through a conventional platform, value leaves the community through several doors at once:
The pattern above has been studied carefully, and named several times over, by people who have spent years on it. We think the analysis is right; where we differ is that we are trying to build the way out rather than describe the trap. If you want the argument in full rather than our summary of it, these are the places to start.
Treats the platform as a business model rather than a technology: position yourself between two groups who need to reach each other, then take a share of every connection. Because the value of the platform grows with the number of people on it, leaving gets harder as the cut gets larger.
Describes a second extraction running alongside the first. Ordinary human experience is treated as unclaimed raw material, refined into predictions about what people will do next, and sold to whoever benefits from knowing. The person the data came from is not the customer.
The sharpest version of the argument. What a platform owner collects is not profit from producing anything — it is rent, charged for access to a space they own. Varoufakis's point is that this makes the arrangement older than capitalism rather than newer: a landlord relationship wearing a technology company's clothes.
There is a plainer phrase for how that arrangement feels from underneath — digital sharecropping. You do the work, on land you do not own, and the owner takes a share of everything you grow. It describes the driver, the seller, the musician and the delivery rider equally well, which is usually a sign a description is getting at something real.
Our answer is not a fairer landlord or a smaller cut. It is that there should be no land to rent in the first place. Two neighbours trading an afternoon's work do not need to pass through a space that anyone owns. So the community holds the node, the protocol is open for anyone to run or fork, and the only charge that exists goes to the community's own Commons. There is no position in the middle for anyone to sell access to — including us.
A good way in, if you would rather watch than read: Benn Jordan's “You Are Witnessing the Death of American Capitalism”, which covers this ground and points to all three books above.
Each of these is a working part of the protocol, not an aspiration. They are described in full in The Rules.
BeanPool runs on mutual credit. When you do three hours of work for a neighbour, three hours of credit come into existence at that moment — your positive balance and their negative balance, created together by the trade. No bank issued it. No one lent it to you. There is no interest, because there is no lender.
This is the root of the whole design. If the money supply has to be borrowed into existence, someone outside the community owns a claim on its future work. If the community creates it by trading, nobody does.
A balance of zero means you have given about as much as you have received. That is the healthy state, and it is a genuinely different target from the one most economies set. There is no prize for accumulating beans, and no way to convert them into a claim on anyone outside the community.
Large idle balances gently reduce over time, at a progressive rate. The effect is to keep beans moving — spent with neighbours, put into local projects — rather than sitting still. An economy where the medium of exchange stops moving is one that has stopped working.
Crucially, what is reduced isn't destroyed and isn't taken as profit: it moves into the Commons Pool. Negative balances are never charged. Someone in the negative has drawn credit the community extended to them, and charging a person who is already behind would deepen the hole rather than get beans moving — the opposite of the point.
The Commons Pool holds what circulation and trade charges collect, and what it holds goes two places: absorbing bad debt when someone cannot repay, and funding projects members approve in voting rounds — tools for a shared garden, equipment for a workspace, whatever gets proposed and voted through. The community decides what its own surplus builds.
It is a closed loop by construction: value is generated locally, held collectively, and spent back into the same community.
When communities trade with each other, extraction can reappear in a subtler form — the wealthier town quietly draining the smaller one. This is the problem John Maynard Keynes set out to solve at Bretton Woods, and BeanPool's inter-community clearing is built on his answer.
Beans never cross the border. A trade between two communities settles through a pair of bridge ledgers, one held by each node, recording what each owes the other in work. Each side sets its own limit on how far that can run — so a neighbouring community can only ever owe you an amount you chose in advance.
Two things follow, and they are the reason this isn't just a spending limit. Clearing what you owe is never blocked — the cap restrains the direction that extends credit, never the direction that settles it. And a community holding a surplus doesn't simply sit on it: the more one town is owed, the more work it can commission from the town that owes it, turning an imbalance back into trade rather than leaving it as a debt.
Where the edges are, plainly: a community in deficit is never charged for being in deficit — Keynes' argument, and ours, is that pressure should only fall on someone with the power to act on it. The one remaining lever, a charge on a surplus deliberately left idle, is specified and deliberately unbuilt until it can pass that same fairness test. Clearing runs between pairs of communities rather than across a wider network, and each community's operator turns it on by choice.
These are the founding values every contribution to BeanPool is judged against. They are published in the project's contributor guide, and they have teeth: work that conflicts with them is declined, however good the code.
We build infrastructure that enables communities to create and retain value rather than having it captured by intermediaries. Contributions that introduce extractive dynamics — network effects that benefit a single controlling party, proprietary lock-in, surveillance-based monetisation — are not welcome.
Local communities should be able to run their own nodes, make their own governance decisions, and operate independently. Contributions that push decision-making upwards to a global authority, or that make local operation impractical, work against the protocol's goals.
The protocol should be understandable by the communities it serves — not only by software engineers. Specifications are written in plain language where possible, with technical detail layered underneath.
No feature should allow data to move without the explicit, revocable, auditable consent of the party it belongs to. Privacy-invasive features will not be merged regardless of their technical elegance.
We measure success by whether communities, ecologies, and commons are healthier because of BeanPool — not by growth metrics or token price.
A claim like this is only worth as much as the ability to verify it, so: