# ADR-009 — Relief-Grant Program (gifts of MBITE) - **Status:** Proposed (dormant — activates only when ADR-008 preconditions are met) - **Date:** 2026-07-22 - **Supersedes:** — - **Superseded by:** — - **Related:** ADR-006 (founder allocation / burn — the program is funded from disclosed, non-premine sources), ADR-008 (liquidity & merchant adoption — the precondition this ADR waits on). ## Context The project wants to eventually direct some MBITE toward people in genuine need — a "relief grant." The intent is charitable, but the design constraints are sharp, and getting them wrong turns a good intention into either fraud, an unregistered security, or unlicensed money transmission. Three hard truths shape this decision: 1. **MBITE has no established value yet** (pre-mainnet, unlisted, zero trades). Granting a thing of undefined value is not charity — it is theatre, and it invites accusations of pumping a worthless token. Per ADR-008, value only becomes honest once liquidity **and** spend-utility exist. **This program stays dormant until then.** 2. **A grant must be an unconditional gift of MBITE — nothing else.** The moment the program takes fiat, pays someone's bills, converts MBITE to dollars, or holds funds on a recipient's behalf, it crosses the crypto↔fiat boundary and becomes **money transmission** (MSB licensing, KYC/AML). It also must not be a payment *for labor or services* (that reframes it as compensation/airdrop) nor carry any promise of future price appreciation (that risks looking like an investment contract / security). It is a gift. Full stop. 3. **Grants funded from a common pool need an honest, tamper-evident source and a transparent decision process**, or the program becomes a slush fund and a reputational liability for a project whose entire brand (ADR-006/007) is "every rule is fixed in code and public." Four parameters were left open in earlier discussion and are decided here: **eligibility**, **per-grant caps**, **pool size/source**, and **who approves**. ## Decision Adopt a **dormant, opt-in, non-custodial relief-grant program** with the following rules. It does **not** run until the ADR-008 preconditions are live. ### 0. Activation preconditions (all required) - A functioning liquidity venue exists (ADR-008 order book has real, non-trivial two-sided activity, **or** MBITE is listed somewhere it can be exchanged). - Real merchant spend-utility exists (ADR-008 directory has active merchants and at least some real on-chain invoice settlements). - A published, auditable funding source exists (see §3). Until every box is checked, the program is documentation only. No grants issue. ### 1. Nature of the grant - Each grant is an **unconditional, one-way transfer of MBITE** to a recipient's **own** address. Non-custodial: the recipient controls the keys the moment it lands. - **No fiat leg. No bill-pay. No conversion. No custody.** The program never holds a recipient's funds and never touches money. - **No strings, no vesting, no clawback, no expectation of profit.** It is a gift, documented as such. The program makes **no** representation that MBITE will hold or gain value; recipients are told plainly it may be worth nothing. - It is **not** compensation. Recipients are never asked to perform work, promote the project, refer others, or complete tasks in exchange. That would make it an airdrop-for-labor / compensation event, not relief. ### 2. Eligibility (default) - **Self-attested need, lightweight.** An applicant submits their own MBITE address and a brief, honest statement of need. No fee to apply. - **One active grant per person and per address.** Anti-Sybil is handled by the per-grant cap and pool rate-limits (§3), *not* by collecting sensitive identity documents — the program deliberately avoids becoming a KYC data honeypot, which is consistent with the project's pseudonymity posture. - **Excluded:** the project's own maintainers, addresses associated with the funding source, and anyone using the grant as disguised compensation. - Eligibility rules are published; changes ship as an amendment to this ADR. ### 3. Pool size & source (default) - **Funded only from disclosed, non-premine MBITE.** Because ADR-006 burns founder allocation rather than holding it, the pool is **not** a premine slice. Permitted sources: voluntary donations to a published, watch-only program address, and/or a fixed, publicly announced allocation the community can verify on-chain. The source and every inflow/outflow are **publicly auditable on the chain**. - **Fixed, announced pool per cycle** (e.g. per quarter). The program never spends beyond the announced cycle amount; when a cycle's pool is exhausted, grants pause until the next cycle. No borrowing against future cycles. - The program address is **watch-only for observation**; actual disbursement keys are held by the approvers (§4), not by any server. ### 4. Approval (default) - **Multisig, m-of-n, no single signer.** Disbursements require an **M-of-N multisig** (default **2-of-3**) so no one person can drain the pool. Signers are publicly named (by pseudonym) at activation. - Every approved grant is **logged publicly** (grant id, amount, recipient address, date, and the on-chain txid) so the whole program is verifiable, matching the transparency standard of ADR-006/007. - Denials require no justification beyond "cycle exhausted" or "failed the published eligibility rules"; the process is not adversarial. ### 5. Per-grant cap (default) - A **small, fixed maximum per grant**, denominated in **MBITE** (not fiat — the program never references a dollar value, since doing so both implies a price and drifts toward money-transmission framing). The exact figure is set at activation relative to the then-current subsidy/emission, and published. Caps exist to make the pool reach more people and to blunt Sybil farming. ## Consequences **Positive** - The program can do genuine good *without* the project becoming a regulated money transmitter, a securities issuer, or a KYC data honeypot. - Full on-chain auditability (funding source, multisig approvals, every grant txid) keeps it consistent with MoonBite's "fixed in code and public" brand. - Dormancy-until-value prevents the worst failure mode: loudly gifting a valueless token and looking like a pump. **Negative / accepted trade-offs** - **The program does nothing for a while.** By design it waits on ADR-008. That is the honest cost of not overpromising. - **Light-touch eligibility is Sybil-imperfect.** We accept some gaming as the price of not building an identity-document honeypot; caps + fixed pools bound the damage. - **Self-attested need can be abused.** Mitigated, not eliminated, by public logs and small caps. - **Multisig coordination is slower** than a single signer — accepted, because no single party should be able to move the pool. ## Alternatives considered - **Run the program now, pre-value.** Rejected: grants of a valueless token are theatre and read as a pump (see ADR-008). - **Pay recipients' bills / give fiat.** Rejected: money transmission (MSB), the exact boundary the project refuses to cross. - **Condition grants on promotion, referrals, or tasks.** Rejected: that is compensation / an airdrop-for-labor, not relief, and muddies the gift framing. - **Collect ID documents for eligibility.** Rejected: builds a KYC honeypot at odds with the project's pseudonymity and privacy posture; caps + public logs are the chosen anti-abuse tools instead. - **Fund from a premine slice.** Rejected: contradicts ADR-006's no-premine burn; the pool must come from disclosed donations or a publicly verifiable allocation. - **Single-signer treasury for speed.** Rejected: unacceptable custody/rug risk; multisig only. ## Notes This ADR is intentionally **dormant**. Nothing in it should be presented publicly as an active program or a promise. When (and only when) the ADR-008 preconditions are met, activation means: publish the pool source and cycle amount, name the multisig signers, publish the per-grant cap in MBITE, and open applications. Until then it is a design record, not an offer.