Benefits With Rules and Accountable Disclosure

A family loses a month of food money overnight because a card reader at a corner store was skimmed. A fuel subsidy meant for a village is resold by the truckload. A refugee buys bread and worries about who can connect that purchase to her identity. These situations expose a difficult design problem: how can a programme control misuse without collecting or distributing more personal information than it needs?

A useful starting point is to model the benefit as a programmable entitlement with its rules attached. Eligibility, spending limits, permitted vendors and expiry can then be evaluated together, with an explicit decision about what each participant may see. That does not eliminate fraud or settle the privacy question. It gives us a concrete design to test. We are putting that proposal on the table and inviting the people who run these programmes to take it apart with us.¹

Scope update, 14 September 2026: This is a proposed benefits application, not a deployed programme. The update replaces absolute theft, diversion and privacy guarantees with specific design goals. Our proofs guide separates integrity checks, controlled disclosure and zero-knowledge proofs.

What existing programmes teach us

The World Food Programme's Building Blocks programme showed the world that aid can be redeemed by people with no bank account, at the scale of a million-plus beneficiaries, across agencies sharing one ledger, with dramatically lower financial-service fees. Those are the right goals and they were hard-won.

That experience raises useful questions for any next design: which parties hold identifying information, what purchase details must they retain, which rules can be checked at redemption, and what can a beneficiary or auditor verify independently? Long-lived records also need a cryptographic migration plan. These are evaluation questions for our proposal, not claims that Building Blocks lacks controls or that a different database alone would improve its outcomes.

The core idea: a benefit is an entitlement, not a balance

"One hundred and eighty food-ration units, eligible items only, redeemable at authorised vendors, non-cashable, non-transferable, expiring at month end." That sentence is the benefit. The proposed 8DB application would represent it as a governed object: a permission rule, a budget, a scope, transfer and cash flags, an expiry and an access level. A funder would issue it, a beneficiary would hold a credential on a phone or suitable token, and authorised vendors would request redemption. The digital check could enforce the encoded restrictions, provided the vendor supplies accurate item and transaction information. Cryptography cannot verify which goods were actually handed over without trustworthy evidence.

Four design goals to evaluate

1. Reduce the value of a copied credential. A holder-bound credential and durable spent-state checks could reject a copied code that lacks the required authorization or has already been used. Device compromise, coercion, recovery abuse and offline double use remain separate threats. We would measure those limits rather than call the benefit theft-proof.
2. Check spending rules at redemption. Item eligibility, quantity limits and quotas would be evaluated before an accepted redemption commits. Programme rules still depend on reliable catalogues, vendor integration and accurate transaction inputs.²
3. Accountability with less disclosure. The goal is to let an auditor check a defined spending rule or reconciliation without receiving every participant's full record. Authorized views and attestations can limit disclosure. A claim that the proof itself hides purchase details needs a separately validated zero-knowledge protocol, including its issuer and verifier views. Neither a signed receipt nor a valid proof establishes that no diversion occurred outside the recorded inputs.³
4. Constrain digital transfers and cash conversion. Non-transferable and non-cashable rules could block those operations through the supported redemption path. They cannot stop someone handing over a device, colluding with a vendor or reselling physical goods. Those cases need programme design and field controls alongside software.

Two further questions matter in the field. Conditional transfers, such as school attendance or clinic visits, need reliable attestations, correction routes and human review when evidence is missing or disputed.⁴ Disconnected redemption also needs a defined protocol: spending limits, freshness, rollback resistance and conflict resolution must be tested before claiming offline double-spend protection or final settlement.

How a proposed redemption would work

The proposed redemption would bind the entitlement, applicable rules and resulting state change in one transaction. Authenticated membership proofs and signed commitments can support integrity checks, but are not zero-knowledge proofs merely because they omit the full record. Proving a spending predicate while hiding its witness requires a specific construction and privacy review. End-to-end cost also needs measurement across the actual redemption path.⁵

1. Check the credential's authority, expiry and available balance against the accepted current state.
2. Check the declared amount and item against budget and scope, retaining the source of the item classification.
3. Evaluate the programme's eligibility and other applicable rules. Deny or hold the request when required evidence is missing, stale or fails a rule.
4. Commit the balance change and spent marker together, then produce the evidence and authorized views defined for that programme.

A donor, agency and auditor may need different views. The design should state which identity, item, amount and timing information each receives, and what remains linkable. ML-KEM and ML-DSA provide post-quantum key establishment and signatures in supported 8DB paths; they do not establish a zero-knowledge or post-quantum security guarantee for an additional proof protocol. The proofs guide explains that distinction.

Two scenarios

Humanitarian. A pilot could test a monthly food entitlement on a phone or an appropriate low-cost token, with a route for people who have neither.⁶ Vendors would request redemption against the programme's catalogue. The evaluation would ask whether donors can reconcile recorded spending while receiving less identifying purchase data, and whether the design remains usable when connectivity fails. It would not assume that digital records prove the physical delivery of every item.

Domestic. A benefits administrator could evaluate whether holder-bound authorization reduces copied-card abuse, whether item rules can be enforced reliably, and whether auditors can work with a narrower disclosure set. A programme like SNAP provides useful design context, not evidence of adoption or guaranteed results. Checkout accessibility, privacy and stigma would need evaluation with recipients and retailers.

The invitation

We are asking for a conversation: a workshop, a pilot design, a working group, a talk. Digital Fabric ↗ is our financial infrastructure implementation on 8DB, with its own claims and evidence matrix ↗. Its policy and transaction mechanisms inform this proposal, but they do not constitute a deployed benefits system or validate the privacy and fraud outcomes described here.⁷ If you administer benefits, fund aid, or research this space, we would like to work through those questions with you.

• One programme's rules. Bring eligibility, restrictions, conditions and audit requirements. We can map the proposed entitlement and the evidence each reviewer would need.
• Your worst fraud pattern. Bring skimming, resale or diversion examples. We can separate what a digital rule could prevent from what requires physical or operational controls.
• A possible pilot. Start with a bounded workflow and agree on privacy, security, accessibility and outcome measures before any deployment.

Write to hello@8braid.com with the subject "Benefit disbursement proposal: conversation". You will hear back from an engineer.

Sources and further reading

• World Food Programme: Building Blocks ↗
• USDA Food and Nutrition Service: replacing stolen SNAP benefits ↗
• NIST FIPS 203: ML-KEM ↗ and FIPS 204: ML-DSA ↗
• 8DB: Compliance You Can Replay
• 8DB: What Comes After Blockchain? Money That Carries Its Own Proof

This is an open architecture proposal, published so the field can build on it regardless of who deploys it. 8Braid has no affiliation with any aid agency, benefits administrator or programme referenced here, and we are not selling a system.

Footnotes

1. This is an open architecture proposal, not a product offer. 8Braid has no affiliation with any aid agency or benefits administrator, and we are not selling a system. ↩

2. Vendor and point-of-sale integration is real work, and item eligibility still comes from the programme's catalogue. ↩

3. Issuer knowledge, vendor records, proof transcripts, timing and repeated presentations can all affect linkability. The proposed purchase-layer privacy goal is not an established anonymity guarantee. ↩

4. Conditions need a trusted attestation source, and the quality of that signal is upstream of us. ↩

5. No end-to-end benefits throughput or witness-hiding proof-size result is claimed here. Merkle path size alone does not measure a complete redemption or establish zero knowledge. ↩

6. Card-less and phone-less beneficiaries exist, so the device can be a cheap dedicated token, but inclusion has to be designed in rather than assumed. ↩

7. This is an architecture proposal. A real deployment still needs a pilot, co-design with an agency, and independent security review; no pilot has yet been run. ↩

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work