Article
Why community points need double-entry bookkeeping
Community currencies die the same way: arguments about who owes what. Double-entry bookkeeping — every point a debit somewhere and a credit somewhere else — is the 700-year-old fix.
Every neighborhood has tried it: the babysitting co-op, the tool library, the "I'll fix your fence, you watch my dog" economy. And every one of them hits the same wall — not economics, but accounting. Someone feels they gave more than they got. Nobody can prove otherwise. The goodwill evaporates over a disagreement nobody can resolve.
The fix is seven hundred years old.
What double-entry actually buys you
In double-entry bookkeeping, every transaction touches two accounts: a debit somewhere, a credit somewhere else. Issue 50 points to Maria for three hours of garden work, and the ledger records both sides — the community pool debited, Maria credited. The books always balance. Not as a feature — by construction.
That structural guarantee is what single-entry point systems lack. A spreadsheet column of "points" can be edited, misremembered, or disputed with no way to reconstruct the truth. A double-entry ledger can always answer: where did every point come from, and where did it go?
The three community patterns
Labor earns points. Neighbors contribute work — packing harvest boxes, hosting pickup, maintaining the common garden — and earn points. The ledger records the community as the issuer and the member as the earner. Transparent, auditable, boring in the best way.
Barter leaves a paper trail. "I'll trade you ten tomato seedlings for an hour of plumbing advice" works fine face-to-face. It breaks at community scale, across time, between people who don't know each other. The ledger records both sides of every trade — the end of "I thought you owed me."
Sponsors fund the commons. A local business funds a point pool — say, 5,000 points for park cleanup weekends. The sponsorship is a ledger entry like any other: sponsor debited, pool credited, distributions tracked. Real support, real records.
The fiat firewall
The design decision that matters most: points are not money, and the ledger must never confuse them. Produce is paid in fiat. Labor earns points. Both are tracked, but they're tracked separately — because the moment points start looking like currency, you inherit currency's problems: speculation, resentment, tax questions nobody wants.
Double-entry makes the separation structural. Fiat accounts and point accounts are different books. The community can see both, and neither contaminates the other.
Disputes resolve against records
This is the whole point. When two members disagree about a trade, the process isn't "who do we believe" — it's "pull the record." Who sent what, when, witnessed by the ledger both parties could see all along. Most disputes die at this step, because the record is unambiguous. The ones that survive get decided on evidence.
When you don't need it
A dozen neighbors trading favors can run on trust and a group chat — and should. Bookkeeping has overhead, and overhead needs a reason. The ledger earns its keep at the crossover: when trading volume passes what anyone can hold in their head, when sponsors put real value in, or when the first serious dispute arrives and there's nothing to check it against.
Communities don't fail for lack of generosity. They fail for lack of records. The ledger is the memory the community can't afford to lose.

Creytix IDE
The IDE that runs the business — see how →
Editor, AI agent panel, browser tab, and terminal in one governed workspace — the same IDE running Creytix's own multi-brand fleet today.
See how it worksNext step
See the platform behind this story
Case studies show the same discipline applied across the live Creytix portfolio.
