> For the complete documentation index, see [llms.txt](https://docs.onym.foundation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onym.foundation/seats/charity.md). # Charity (plan) *Seat page, draft 0.3 — 15 August 2026.* Charitable aid runs on trust, and trust is exactly what the people involved can't afford to spend. A donor wants to know their money reached a real, verified program — but "trust us" is all most programs can offer. A beneficiary needs help *now* — but asking for it usually means handing their identity, their documents, and their situation to strangers forever. The charity seat exists so that neither has to. Here's the whole idea in one paragraph: charity is an **open application seat composed of separately replaceable roles** — nobody's word is taken for anything another party can attest to instead. The charity operator runs the program; a credential issuer vouches for the organization under a named policy; a financial provider moves the money; a notary makes narrow claims verifiable; an auditor signs reports. The user's application pins exactly which of each it accepts, shows every claim with its author, and asks the user to authorize exact canonical terms — never a provider's bytes. A beneficiary can prove they are *eligible* without publishing who they *are*. And the whole contract surface is built to carry **zero intentional donor or beneficiary PII** in any public record. **Contract:** [`charity/Charity.md`](https://github.com/onymchat/onym-system/blob/main/charity/Charity.md) — the technology-free boundary this page summarizes — and [`charity/UI-Charity.md`](https://github.com/onymchat/onym-system/blob/main/charity/UI-Charity.md), the messenger-side application profile. Both are drafts. **Implementations:** [Stellar/Soroban](/seats/charity/charity-stellar.md) — a **plan**, its profile unwritten · [BNB Chain](/seats/charity/charity-bnb.md) — a **merged specification** ([`UI-Charity-BNB.md`](https://github.com/onymchat/onym-system/blob/main/charity/UI-Charity-BNB.md)) · [Cardano](/seats/charity/charity-cardano.md) — a **plan**, its profile unwritten · [Solana](/seats/charity/charity-solana.md) — a **plan**, its profile unwritten, and the only one that argues the on-chain settlement question now instead of deferring it. No charity code exists in any Onym repository, and no binding waits for another to deliver. This page stays deliberately free of any one blockchain, payment rail, or aid program — so does the contract, explicitly: it requires no ledger, no token, no particular zero-knowledge system. The seat is one merged boundary with two user-facing journeys, and this book presents it through them: **Donate** and **Ask for Aid**. ## The roles, kept apart on purpose The contract's first decision is that these are *separately replaceable* parties, and their identities must be **separately inspectable** — a brand, domain, or app-store listing binds none of them to another: | Role | What it does — and only that | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **User application** | Presents canonical intent, holds local keys and capabilities, verifies receipts. Never silently decides an organization is trustworthy. | | **Charity operator** | Defines the program, allocates aid, handles complaints. Makes the claims attached to a campaign — and owns their truthfulness. | | **Organization credential issuer** | Checks an organization under a named policy; issues and revokes a signed credential. | | **Eligibility issuer** | Attests that a beneficiary satisfies a named aid policy — preferably without publishing who they are. | | **Financial provider** | Quotes, settles, refunds, disburses, under its own legal authority. | | **Notary** | Records narrow public state and produces verifiable evidence. Nothing more. | | **Auditor / report issuer** | Signs claims about receipts, allocation, expenditure, impact — each attributed, none inherited. | One party may hold several roles, but every signed record still says which authority it exercises. The messenger publisher is not implicitly the operator, custodian, or auditor; the operator is not implicitly allowed to administer the messenger or read its user graph. ## "Verified" is always qualified The contract's central trust rule, worth quoting nearly verbatim: `verified organization` is never a universal state. It means *issuer I attested at time T that subject S satisfied policy P, version V, for scope C, until expiry or revocation* — and the UI must show the issuer, policy, scope, validity, and current revocation status, never collapsing them into an unqualified checkmark. A user's `TrustPolicy` pins which issuers and assurance levels they accept, and issuer trust is never transitive. Cryptographic evidence is equally narrow: a signature proves control of a key over exact bytes; a credential proves an issuer made a claim; a zero-knowledge proof proves its declared predicate; a settlement receipt proves a financial transition. **None of them alone proves absence of fraud, delivery of aid, or charitable impact** — and no conforming UI may pretend otherwise. ## Journey one: Donate A donor finds a **campaign** — a signed, revisioned record naming its operator, organization, credential, purpose, accepted assets, exact financial destinations, and its allocation, refund, and reporting policies. Campaigns live in one state machine: ``` draft → active → paused → active \-→ closed \-→ revoked ``` Before any money moves, the application fetches a fresh signed **Donation Quote** — gross amount, every fee with its recipient, net amount, destination, finality rule, refund rule, expiry — and shows one canonical confirmation. Only then does the user authorize a **Donation Intent** pinning the exact quote, campaign revision, and credential digest. The donation's life: ``` prepared → submitted → pending → finalized finalized → refund-pending → refunded | refund-denied finalized → reversed ``` with `expired` and `failed` exits along the way. `submitted` is not settlement; `finalized` means only that the pinned financial profile's finality rule was satisfied. A finalized **Donation Receipt** binds the digest of the exact intent bytes the donor authorized, and refunds run under the policy pinned by the *original* intent — never the campaign's newest one. What the donor is promised: * **Terms cannot mutate under your signature.** A changed amount, fee, destination, campaign revision, or privacy choice invalidates the preview and requires a new decision. * **No undisclosed cut, ever.** Any fee or revenue share deducted from your value is a named line — amount, rate, recipient, basis — in the signed quote and the finalized receipt. * **Reporting is aggregate and attributed.** Fund-flow reports carry their issuer's signature, state gross versus net explicitly, exclude duplicates, refunds, and reversals — and never contain donor or beneficiary identities. Fund flow, allocation, expenditure, and impact are four separate claims with four separate authors. * **Privacy is stated, not assumed.** A public rail can expose addresses, amounts, and timing even when the messenger carries no PII; the profile declares it and the UI warns before signing. "Anonymous" is never shown when the selected rail makes you identifiable. ## Journey two: Ask for Aid A beneficiary's journey is built backwards from one requirement: prove *eligibility*, not *identity*. A campaign's **Eligibility Policy** names a predicate ("eligible under policy P"), the issuers whose credentials count, the proof system, the public inputs, and a **nullifier scope**. The beneficiary's device builds an **Eligibility Presentation** locally — a proof of the predicate that, where the proof profile supports it, never publishes the underlying credential. The nullifier is **campaign- and epoch-scoped**: it stops the same entitlement being claimed twice in the same window, and it must never become a cross-campaign or permanent person identifier. An accepted presentation backs an **Aid Claim**, whose delivery details — payout address, pickup capability, shipping coordinate — are sealed to the named delivery provider alone. Public state may carry only the claim digest, the scoped nullifier, and a randomized, claim-scoped recipient commitment. The claim's life: ``` prepared → submitted → eligibility-verified → approved → disbursed ``` with `rejected` and `expired` exits at each review step. Approval is not disbursement, and the **Disbursement Receipt** records outcome, entitlement, fees, and evidence without repeating private delivery details. What the beneficiary is promised: * **No roster.** A beneficiary list is never published — not by the operator, not by the notary, not in a report. * **Failure is private.** A failed proof or a duplicate-claim refusal (`NULLIFIER_USED`) surfaces as a typed, scoped outcome — never a public person identifier, never leaked diagnostics. * **Case files stay with the responsible party.** Source credentials and documents remain with the issuer or operator under declared retention — never in public notary state, never shown to donors. * **Safe exit.** A beneficiary can abandon the flow without sending partial proofs, and no notification or screenshot surface reveals aid participation by default. ## The privacy boundary The base interface requires no real name, email, phone, device fingerprint, address-book upload, or referral token from anyone. A provider may lawfully need regulated data for a specific rail or jurisdiction — but that is a separate, explicit handoff with a named controller, purpose, and retention, never a silent default. No provider may ever demand the identity root secret or an unscoped key. The honest formulation — the contract refuses to promise more: the target is **zero intentional PII publication** in the messenger protocol objects and the charity contract surface, backed by negative fixtures. That is a testable design invariant, not a warranty that no endpoint can ever be compromised, and each deployment declares who controls which data set, for what purpose, and who answers when something goes wrong. Measurement follows the same rule: fund flow is measured, people are not. `eligibleDonationVolume` counts finalized, non-refunded receipts into pinned destinations — it proves qualifying financial flow and deliberately cannot prove that any particular person saw a message, installed an app, or was "converted." ## Where the code is Nowhere, yet — and this book doesn't pretend otherwise. The abstract boundary leaves ledgers, proof systems, and rails to implementation profiles, and four are planned: * [**Stellar/Soroban**](/seats/charity/charity-stellar.md) — the planned reference binding: Soroban contracts as the campaign's notary binding, riding the notary seat's running relayer and manifest infrastructure. Its profile document is unwritten. * [**BNB Chain**](/seats/charity/charity-bnb.md) — the EVM sibling: Solidity contracts with toolchain-generated PLONK **BN254** verifiers. Its profile is [merged](https://github.com/onymchat/onym-system/blob/main/charity/UI-Charity-BNB.md) — interface, errors, encodings, fixtures — with the code explicitly nonexistent. * [**Cardano**](/seats/charity/charity-cardano.md) — the eUTXO sibling: Plutus validators verifying the same **BLS12-381** proofs as the Stellar plan, reusing the notary's existing prover. Its profile document is unwritten, and the ledger model replaces `msg.sender`, mutable mappings, and typed reverts with mechanisms that cost something different. * [**Solana**](/seats/charity/charity-solana.md) — the one that composes rather than rebuilds: the Solana Attestation Service already carries the issuer, schema, policy, and expiry layer this seat's credentials need, and Groth16 **BN254** proofs verify through native syscalls. Its profile document is unwritten. Every binding leaves room for a later **financial** binding; this is the one that argues it now, because putting the beneficiary's payout address on a public ledger is a trade the page refuses to defer or assume. Two companion pages keep the seat honest at the system level: [the adversary's view](/seats/charity/charity-adversary.md) states what a public trail exposes and what the UI must disclose before anyone signs, and [the role-binding table](/seats/charity/charity-roles.md) records which abstract roles are actually held by which parties — today, almost all **unassigned**, on the rule that a role is held when a signed record says so. ## Next steps * [Notary](/seats/notary.md) — the seat a charity deployment binds to for narrow public state, and whose operator-manifest discipline the implementations reuse. * [Discovery](/seats/discovery.md) — where charity deployments and their provider bindings will be listed once they exist. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.onym.foundation/seats/charity.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.