Your Ledger Stores Balances. I Built One That Stores Intentions.

There is a subtle way to get purpose-bound money wrong, and it is the cleanest way I know to explain why I changed what a ledger stores. A charity raises money for a cause. It spends some, writes up what it did, and publishes that report. Someone authorized to check the report signs off, and the sign-off releases budget for spending. That part is fine. The trouble is with the next donation. If the sign-off simply switched spending on, then every unit of money that arrives afterwards would be covered by an approval it was never part of. One check, done once, would quietly turn into standing permission to spend everything that comes later. A naive design walks straight into this. Getting the interaction right is most of the work, and it forced two changes to how the ledger behaves: what it is allowed to store, and when it is allowed to let money out. What the ledger is allowed to store For most of the systems I have worked on, the ledger has the same underlying type. In the account model it is a map: balances : Address -> Amount A quantity, indexed by an owner, and nothing beside it. The UTXO model keeps its books differently, with value sitting in unspent outputs, but the point survives the translation: an output records an amount and a spending condition, still not a purpose. That one type decision carries more weight than it looks like it should. A structure that only records how much someone holds has nowhere to put what that money is meant for, and a surprising share of what we ask money to do lives in exactly that missing field. I have spent more than five years with that type sitting under the systems I built: matching and custody at a crypto exchange, Web3 architecture and tokenomics I advised on, and the distributed-systems work that pulled me toward formal methods as a visiting researcher. In all of it, Address -> Amount was treated as if it were fixed by nature. It is a choice, and for one kind of problem it is the wrong one. The kind of problem is money handed over for a stated purpose by someone who will not be in the room when it gets spent: grant funding, restricted endowments, disaster relief, and the case that finally justified building a chain from the ground up, charitable donations. In plain terms. When you give money for medical care, nothing in the usual systems physically stops it being spent on something else. The label is a line in a report, not a rule anyone enforces. I rebuilt the ledger so the label is the rule: money given for one purpose cannot be moved to another, a fund can spend only after its report has been confirmed, and a donor can check all of it on the chain without any patient's private details ever being exposed. The blind spot every ledger inherited When Luca Pacioli wrote down double-entry bookkeeping in 1494, the smallest unit of the record was an amount set against an account. Over the next five centuries we rebuilt almost every trust assumption underneath accounting: append-only logs, digital signatures, Byzantine-fault-tolerant replication so that no single party can quietly rewrite the past. The one thing we carried over unchanged was that smallest unit. The core of an ERC-20 token is balanceOf(address) returning a number, which is the same shape as a column in a fifteenth-century book: an owner and a quantity. Purpose has no place to go, so it gets pushed off the chain into a database row, a spreadsheet cell, a paragraph in an annual report. Which is to say, into storage that one party can edit, reorder, and backdate. You can write a perfectly immutable transaction and still leave its meaning resting on a document nobody can verify. The strong guarantee and the thing people really care about end up in two different systems. Changing what the ledger stores Model the ledger as a deterministic replicated state machine. The change is to the index of the state. Instead of Address -> Amount key each position by owner and earmark together: (Address, Purpose) -> Amount A balance tagged education and a balance tagged medical under the same owner stop being one number with a note in the margin. They are two separate entries, and nothing in the protocol converts one into the other. A transfer takes from (sender, purpose) and adds to (recipient, purpose) for the same purpose. The transition function offers no rule that moves value out of the medical entry into the education entry, or out into anything untagged. Because that holds in the starting state and every transition preserves it, it holds across every state the system can reach, and the consensus layer makes every honest node agree on that state. The guarantee has the same character as conservation of value against double spending: nothing catches a violation after the fact, because no transition expresses the violation in the first place. transfer(from, to, purpose, amount): require state[(from, purpose)] >= amount # can't spend what isn't earmarked here state[(from, purpose)] -= amount state[(to, purpose)] += amount # purpose carries across the transfer # there is no rule anywhere that rewrites purpose The obvious objection lands right here, and it deserves a straight answer: this looks like a map I already know. It does. ERC-1155 keeps a two-dimensional balance, balances[id][account] , which is (id, owner) -> amount . Colored coins tagged Bitcoin UTXOs with asset identity a decade before that. The keying is not the new part and I would not claim it is. Three things set this apart. In those systems the second index is an asset you can mint, trade, and swap, with whole markets built on top of ERC-1155 ids. Purpose here is not an asset and has no conversion path. The transition function contains no swap and no re-mint, so there is no reachable state in which medical value turns into general value. The check runs at the base layer, in every validator, rather than as a convention inside one contract that other contracts are free to ignore. This is where the contribution sits: the purpose index is wired to a gate that controls disbursement rather than custody, and that gate depends on verified reporting. That wiring is the patent-pending method. Labeled balances are prior art, and standing up a blockchain is not itself an invention. What is new is the mechanism that makes targeted spending provable. There is an older version of this idea too, and the sharpest form of the objection comes from accountants rather than from crypto people. Charities and governments already track money by purpose. It is called fund accounting, and for U.S. nonprofits it is written into GAAP as net assets with donor restrictions under FASB ASC 958. A gift given for the building fund is booked so it can only be released to the building fund. So tagging money with its purpose is ordinary bookkeeping, not something I came up with. What changes here is where that rule lives and what keeps it honest. In fund accounting the restriction is a category the organization maintains in its own books, and a donor learns whether it held only after the fact, from records that one party keeps and can reorder. On this chain there is no category for anyone to maintain. The restriction is a property of the transition function that every validator checks at every block, and money cannot leave a restricted balance until a report tied to that balance has been confirmed on-chain. Fund accounting can state what money was for. I wanted a ledger where spending it on anything else is not a move you can make. When the ledger lets money out Tagging value is the part that demos well. The hard part is disbursement, and it is where the failure mode from the opening lives. The flow is short. A fund publishes a report anchor on the chain, an authorized verifier confirms it, and only then does spendable budget open. The subtlety is about time. If confirmation opens spending in a general sense, it also covers money that had not arrived when the verifier looked at the state. A one-time approval becomes a permanent one without anyone deciding that it should. This is a freshness problem, close in spirit to the classic time-of-check-to-time-of-use gap: a decision made against the state at one height gets reused against a larger state later. I call this particular shape sticky confirmation . The general fault is an authorization that was never tied to the state it was granted against, which is the same reason nonces and sequence numbers exist. The fix binds the authorization to a number instead of a yes-or-no. Confirmation mints a spendable quota equal to the amount raised as of the commit height. Disbursement draws that quota down. Anything that arrives afterwards is not covered and needs its own report and its own confirmation, and publishing a new report resets the quota rather than adding to it. Because the quota lives in the Merkle root of the state, every node computes the same figure at every height, and there is no off-chain number left for anyone to adjust. The ledger stops recording that a fund said it spent honestly. It makes spending beyond what has been accounted for something the system cannot express. Transparency that does not expose people The instinctive worry about charity on a blockchain is a permanent public list of sick people and their diagnoses. That is a real way for naive transparency to go wrong. So no personal data goes on the chain. What the chain holds is a hash that binds to an off-chain document, plus pointers that identify nothing about a person. The document itself, with the names and the details, stays off-chain. Change a single byte of it and the hash no longer matches, which makes tampering visible. Names, diagnoses, and identities are never written on-chain, and that exclusion is checked by explicit tests rather than promised in a policy. A donor can confirm that money reached its stated purpose without anyone being able to recover who was on the receiving end. People tend to treat verifiability and privacy as a trade-off. Here they come out of the same construction. Why not just a smart contract A lot of this could be approximated with contracts on an existing chain: sub-accounts, guarded transfer logic, a registry of purposes. So building a base layer needs a real reason rather than a preference. When you build on someone else's settlement layer, you take on their fee market, their governance, their upgrade schedule, and, for this use case, a volatile asset sitting in the middle of a charity's payment path. There is a cleaner reason too. A permissioned validator set with known membership removes the open-participation Sybil problem, and with it the reason public chains burn energy or lock up capital in the first place. Those mechanisms exist to make identity expensive when anyone can join, which is why such chains need a native speculative token. Replace open participation with a known validator set governed on the chain, under a Byzantine threshold, and the security argument becomes the classical one: safety as long as fewer than a third of the validators are faulty, with no coin anywhere in the path that matters. The mission does not have to share a ledger with a market. The unglamorous part, because crypto has earned the skepticism If you have read this far with an eyebrow up, that is a reasonable reflex. Blockchain and charity in one sentence usually come right before a token and a rug . The only answer worth giving is engineering you can poke at. Almost none of the machinery is new, and that is on purpose. The consensus core is a Byzantine-fault-tolerant replicated state machine in the Tendermint line, with prevote and precommit rounds, lock and unlock rules, and explicit detection of equivocation. It is written as a pure function from events to actions, with no I/O and no reading of the clock, because that purity is what lets a model checker enumerate the states it can reach. We specify it in TLA+ and model-check it for safety and liveness, on bounded configurations, including Byzantine and multi-round schedules. It is the same formal-verification approach engineers bring to smart contracts , and the same tool has found real defects in shipping chips and cloud systems at Intel, Microsoft, and AWS, so this is not decoration. Alongside the model we run a deterministic simulator in the style FoundationDB made standard, single-threaded and seed-reproducible, replaying partitions, crashes, and reordered messages. Every block carries its own finality proof, at least two-thirds of the validators' signed precommits, and that proof gets re-checked on every path a block can enter by, including when a node restores from disk. A node that loads a tampered database will still reject a block that was never properly voted on. This is the old Saltzer and Schroeder principle of fail-safe defaults from 1975: when something goes wrong, the safe state is the default one. The cryptography is deliberately dull. Deterministic ECDSA nonces on P-256 per RFC 6979 remove the nonce-reuse mistake that leaks private keys, enforced low-S signatures shut down malleability, and Merkle hashing with domain separation in the RFC 6962 style closes the duplicate-node ambiguity behind CVE-2012-2459. P-256 is the curve the browser exposes through WebCrypto, so the non-custodial wallet keeps the donor's key encrypted at rest and imports the session key as non-exportable, which means it cannot be pulled out even if the front end is compromised. I list all of this to be clear about where the novelty is not. TLA+, BFT finality, deterministic simulation, and RFC 6979 nonces are table stakes for anyone treating a ledger as critical infrastructure, and dressing them up as inventions would be its own kind of warning sign. The one new thing is the one above: the (Address, Purpose) index as a consensus-checked rule, wired to the report-verify-quota gate on disbursement. Everything else is standard work done carefully. When a project has that ratio the other way around, with dramatic claims about novel consensus and hand-waving over the basics, that is usually the one to walk away from. In production The network runs today with about 80 funds on it. It has settled well past 280,000 transactions across roughly 45,000 wallets, around 15,700 of them active in a given month. The number I keep an eye on is retention, because it tells me whether any of this matters to the people using it. Recent cohorts stay with the platform at close to twice the rate of the first one. That is the pattern you would expect, though not something retention alone can prove, if verifiability is doing real work. Once a fund's spending is something a donor can check instead of take on faith, the relationship stops resetting to zero every year. Where this still falls short Better that you hear the limits from me. The hard limit is one no ledger gets around. The chain can prove that value moved exactly as recorded. It cannot prove that the off-chain world it points at was telling the truth to begin with. A dishonest verifier or a fabricated report sits outside what cryptography can reach, which means the trusted base still includes the verifier and whoever files the report. This is the oracle problem , and I do not claim any exemption from it. What the protocol does is shrink that trusted surface to something small and explicit, and limit how much damage a failure there can do. Whatever trust is left after that is not a theorem. It has to be earned, and earning it is part of the job. In practice that means building credibility around the protocol on purpose: publishing the engineering, growing a technical community that can pick the design apart, and standing behind the system as a named team with an institution and a reputation attached, rather than an anonymous deployment. Cryptography sets a hard limit on how much anyone has to trust us. A track record people can check, and a community able to check our work, covers the rest. I would rather compete on that than ask anyone for the benefit of the doubt. This reaches past charity The thing I did not see coming is that purpose-bound value stops looking like a charity feature and starts looking like something a lot of systems are quietly missing. Think about how many places encode "this money may only be used for X" as a promise backed by an after-the-fact review rather than a rule enforced as the money moves: research grants, restricted endowments, public budgets, disaster relief, milestone-based escrow, transfers from a government with strings attached. In each of them the constraint lives in prose and is settled by trust. Charitable giving was simply where the gap was widest and the human cost of getting it wrong was highest, so it is where I started. Once a ledger can carry intent as a fact that consensus checks, "what was this money for" stops being a question you answer with a document and becomes one the system answers on its own. It is a small change to a data structure that has held its shape for five hundred years, and I suspect charity is only the first place it turns out to matter. Disclosure: I founded the project I have used as the running example here, so weigh what I have said with the skepticism a builder writing about his own system deserves. Wherever I could, I described behavior you can test rather than adjectives you are asked to admire. The platform is BLAGOCHAIN .