2026-07-07 · Raiden Team
Italian merchants were keeping double-entry books by the early 1300s — about seven hundred years ago — and the practice was famous enough by 1494 that a Venetian friar named Luca Pacioli set it down in print. None of it was invented for a social network. It was invented to stop merchants from lying to themselves, and each other, about how much money they actually had. That's still exactly what it's for, and it's the same structure sitting underneath every number on Raiden's transparency page.
Single-entry bookkeeping is a list: you got $10, you spent $4, here's what's left. It's simple, and it's also easy to get wrong or fake, because nothing forces the numbers to reconcile against anything else. Double-entry bookkeeping works differently. Every transaction is recorded twice, as two equal and opposite entries: money leaving one account and landing in another. Nothing simply appears or disappears. It always moves from somewhere to somewhere.
That constraint is the entire point. If every transaction must have a source and a destination that match exactly, you can add up all the entries in the whole system at any moment and they must sum to zero. Not approximately zero. Exactly zero. If they don't, something in the books is wrong, and you know it immediately instead of finding out later.
Raiden isn't a bank — no user holds money here at all — but it has a similar trust problem: it publishes a weekly pot and a set of per-charity totals, and those numbers have to be trustworthy. When an advertiser pays for a campaign, that's an entry. When the week's pot forms from the charity portion of that revenue, that's matched entries, money moving from the advertiser side toward the pot. When the weekly distribution splits the pot per charity, and when a payout goes out through Every.org, those are matched pairs too. Advertiser money in, charity money out, every entry matched — and the path only ever runs advertiser → pot → charity.
At no point does a number just get typed into a field. Every dollar attributed to a charity can be traced back to a specific entry somewhere else in the system, because that's the only way it's allowed to exist. If someone tried to hand-edit a charity's total to make it bigger, there would be no matching entry to explain where that value came from, and the books would stop balancing to zero. The math itself would catch the change.
The weekly split has the same discipline. The pot is divided by impression share and each member's giving split using exact integer arithmetic with largest-remainder rounding, so the per-charity amounts sum to the pot precisely — no rounding dust quietly dropped, none quietly invented. Exactness isn't perfectionism here; it's what makes "the entries must match" a real constraint instead of an approximation.
Here's the detail that matters most: the totals you see — this week's pot as it's distributed, each charity's running total — are not numbers sitting in a field somewhere, waiting to be read off and displayed. They're computed from the full history of entries and each persisted weekly run. Every week's distribution and its per-profile attributions are recorded, and the totals are added up fresh from that record.
This sounds like a small technical distinction, but it changes what's possible. A stored number can be edited directly, by mistake or by design, and there's no way to tell after the fact that it happened. A computed number can't be edited at all; the only way to change it is to add a new, real entry to the ledger, which is visible, traceable, and has to balance against something else. You can't quietly bump a computed total any more than you can quietly bump the result of 2 + 2.
"The books balance to zero" just means that if you added up every single entry across every account in the entire ledger — advertiser payments, the weekly pot, per-charity totals, disbursement records — the total would be exactly zero. Every dollar that enters the system as an advertiser payment is matched somewhere by a dollar that exits toward a charity, with every intermediate step accounted for in between. During the founding preview, weekly runs are projections rather than payouts, but they're held to the same arithmetic: the projected per-charity amounts must sum to the pot exactly, or the run is wrong.
That's not a promise we're asking you to take on faith. It's a property of the accounting structure itself, the same one merchants were using seven centuries ago to make sure their own books couldn't lie to them. We didn't invent a clever new way to make our numbers trustworthy. We just used the old one, correctly.
Join Raiden — turn your scrolling into giving← Why We Built Raiden U.S. Tax Basics of Charitable Giving, Plainly →