Skip to content

MPWR Token Economy — Research & Feasibility

This document answers three foundational questions before BNI commits resources to building MPWR: Is it legally permitted? Is it technically feasible? Can a third-party custodian handle it?

All references are vetted primary sources (SEC, FinCEN, IRS, W3C, GitHub) or attributed secondary sources with publication dates.

Executive Summary

Question Answer Confidence
Is MPWR legally permitted? Yes — with significant compliance requirements that must be addressed before any live redemptions HIGH (settled law on most points)
Is it technically feasible? Yes — all components have production-grade open-source or commercial solutions HIGH
Can a third-party custodian be used? Yes — strongly recommended. Stripe + Sila + Circle covers the full stack without BNI needing its own financial licenses HIGH
Can donor money fund the program without tokenizing acts of care? Yes — see Part 4. Three orthogonal patterns (donor blockchain transparency, community-resource staking, suspended-coffee micro-sponsorship) work with either the current MPWR per-act design or the time-banking alternative. MEDIUM (design space is well-mapped; specific BNI implementation is [HYPOTHESIS])

Note on scope expansion: Parts 1–3 of this document analyze the current per-act MPWR token design (the spec in MPowerUP Token Economy). Part 4 covers donor-funded alternatives that may replace, supplement, or run beside that design. Two companion docs in the mpowerup project develop the alternative direction further — both now published on this site under Sub-Project Docs → MPowerUP → Research:

Part 4's patterns are designed to fund either system.

1.1 Securities Law — Howey Test

Question: Is MPWR a security under US federal law?

Answer: Mixed signals. Attorney review is required before Phase A+ launch.

The Howey test (SEC v. W.J. Howey Co., 1946) asks whether there is: (1) an investment of money, (2) in a common enterprise, (3) with a reasonable expectation of profits from efforts of others.

Factors pushing MPWR away from security status:

  • Tokens are earned through labor (helping neighbors), not purchased — weakens the "investment of money" prong
  • Non-transferable in Phase A eliminates secondary-market profit expectation
  • Redemption is for utility (USD for food, housing) not investment returns
  • SEC v. Ripple (2023) established that programmatic sales to non-institutional parties are less likely to be securities

Factors pushing toward security status:

  • BNI controls ongoing ecosystem development and token backing
  • Community Fund yield distributions create profit expectations
  • Individual long-term stake with growth characteristics resembles an investment contract

Relevant SEC guidance:

Action required: Engage a securities attorney to analyze MPWR's token distribution mechanics and Community Fund yield structure against the current (March 2026) SEC framework before Phase A+ launch. Non-transferability in Phase A is protective but not conclusive.

1.2 FinCEN — Money Services Business Registration

Question: Does redeeming MPWR tokens for USD trigger federal MSB registration?

Answer: Almost certainly yes. FinCEN classifies BNI as both an administrator (issuing MPWR and authorizing redemptions) and an exchanger (converting virtual currency to real currency). Both categories are money transmitters.

FinCEN's position (2013 guidance, still current):

"A person that creates units of convertible virtual currency and sells those units to another person for real currency... is an administrator... [and] is a money transmitter."

Filing requirements:

  • File FinCEN Form 107 (Registration of Money Services Business)
  • File within 180 days of first operation as an MSB
  • Renew every 2 years
  • Implement a written AML/CFT compliance program
  • File Currency Transaction Reports (Form 112) for cash >$10,000/person/day

Penalties for non-compliance: Up to $1,000,000 per violation.

Primary sources:

Action required: Retain a financial compliance firm and file Form 107 within 180 days of first live redemption. Establish AML program before launch.

1.3 State Money Transmission Licenses

Question: Which states require additional licensing beyond FinCEN registration?

Answer: Most states require their own money transmitter licenses. 31 states have adopted the uniform Money Transmission Modernization Act (MMTMA). The remaining 19+ maintain independent, often stricter requirements.

High-priority states (large population, complex regimes):

State Regulator Notes
California DFPI Money Transmitter License; independent regime
New York NYDFS BitLicense or Trust Charter required for crypto
Illinois IDFPR Independent regime
Texas Texas DOB MMTMA adopter
Florida OFR Independent regime

Typical requirements across states:

  • Surety bond: $10,000–$500,000 (varies)
  • Net worth minimum: $25,000–$500,000
  • KYC/AML program documentation
  • Annual licensing fees

Key shortcut: Using a licensed BaaS provider (Stripe, Sila, Marqeta) means operating under their state licenses rather than obtaining your own. This is the recommended path for early-stage BNI.

Sources:

1.4 IRS — Tax Treatment of Earned MPWR

Question: How are MPWR tokens taxed? What are BNI's reporting obligations?

Answer: This is settled law. No attorney opinion needed — only correct implementation.

Participant tax treatment:

Tokens earned through labor (helping neighbors, facilitating Circles) are ordinary income at fair market value on the date received (IRS Notice 2014-21, still controlling). This applies whether the participant is:

  • An independent contractor (self-employed) → BNI issues 1099-NEC if >$600/year
  • A volunteer receiving consideration → treated as earned income

Form 1099-DA (effective 2025):

Starting January 1, 2025, digital asset brokers must report transactions on Form 1099-DA. The first filings cover 2025 transactions, reported January 2026. USDC/stablecoin transactions have a $10,000 de minimis threshold.

BNI's obligations:

  1. Establish a documented MPWR fair market value methodology (required before first redemption)
  2. Issue 1099-NEC to participants earning >$600 equivalent in a calendar year
  3. Implement broker reporting per Form 1099-DA rules when applicable

Critical issue for target population: Participants receiving SSI, SNAP, or housing assistance will have earned income reduced by SSI income rules (see 1.5 below). In-app disclosure is legally and ethically required.

Sources:

1.5 Benefits Impact — SSI, SNAP, Housing Assistance

Question: Will MPWR token redemptions affect participants' public benefits?

Answer: Yes — this is the most critical legal issue for MPWR's target population.

Supplemental Security Income (SSI) — 2026:

  • Maximum federal payment: $994/month (individual)
  • Token redemptions count as earned income
  • SSI earned income exclusion: First $20 general disregard + first $65 earned disregard + 50% of remaining
  • Example: $400 USD redeemed → SSI counts ($400 − $65) × 50% = $167.50 → SSI benefit reduced by ~$168/month

SNAP (Food Assistance):

  • $65 earned income disregard applies, then standard calculation
  • Likely reduces SNAP benefits if household is near income limit

Housing Assistance (Section 8 / HUD):

  • Rent burden calculation includes all earned income
  • Even small amounts of MPWR income change rent contribution calculations

SSA Recent Change (Sept 30, 2024):

Food provided by friends/family is no longer counted as In-Kind Support and Maintenance. Informal mutual aid food support through MPowerUP Circles may be protected, but cash redemptions are not ISM and count as income.

Recommended response — PASS Program:

The SSA's Plan to Achieve Self-Support (PASS) program allows SSI recipients to set aside income and resources for a work goal without affecting SSI eligibility. BNI should partner with Work Incentive Planning and Assistance (WIPA) organizations to help participants use PASS to protect their SSI while building their MPWR stake.

Sources:

Action required: Partner with at least one WIPA organization in each operating region before any live redemptions. Add an in-app benefits impact disclosure screen at the point of first redemption.

1.6 Gift Card / Loyalty Exemptions — Not Applicable

Question: Can MPWR avoid MSB classification by structuring as a loyalty program or gift card?

Answer: No. MPWR's structure does not qualify for any of the available exemptions.

The FinCEN prepaid access exemptions require closed-loop redemption (MPWR-only, not USD), a $1,000–$2,000 daily cap, and no person-to-person transfers. MPWR's 50% liquid pool redeemable for USD via ACH exceeds these limits. The Community Fund staking component also introduces investment characteristics that move beyond a gift card model.

Sources:

Issue Urgency Who Does It Notes
FinCEN Form 107 (MSB registration) Critical — within 180 days of launch Financial compliance firm Non-compliance = up to $1M penalty
Securities attorney Howey analysis Critical — before Phase A+ launch Securities counsel Community Fund yield is the main risk
State MTL vs. BaaS partnership High — before launch Fintech legal counsel BaaS route avoids individual state licenses
Fair market value methodology High — before first redemption Tax counsel Required for 1099-NEC issuance
WIPA partnership + benefits disclosure High — before first redemption BNI partnership + product Ethical and legal obligation
Separate fund entity (LLC or trust) for Community Fund Medium — before fund exceeds $10K Corporate attorney Fiduciary duty protection
Form 1099-DA broker reporting Medium — 2026 filings BNI finance/operations Must report 2025 transactions

Part 2 — Third-Party Custodian Options

2.1 Why Use a Third-Party Custodian

BNI should not build its own financial custody infrastructure. The licensed custodian path:

  • Avoids the need for BNI to obtain individual state money transmitter licenses
  • Provides FDIC-insured USD custody, audited compliance programs, and KYC infrastructure
  • Reduces time-to-launch by 12–18 months vs. building in-house
  • Transfers regulatory liability to the licensed partner

Note: Synapse Financial Technologies filed for Chapter 11 bankruptcy in April 2024, freezing hundreds of thousands of customer accounts. It has been removed from consideration. Do not use Synapse or any Synapse-dependent platform.

This combination covers the full MPWR lifecycle without BNI needing its own licenses:

Layer Provider What It Covers
Card issuance + USD custody Stripe Issuing + Stripe Treasury Prepaid debit cards, USD balances, FDIC-insured
ACH redemption Sila (mission-aligned) or Dwolla ACH transfers, bank-to-bank payments
Stablecoin / DeFi layer Circle USDC + Programmable Wallets USDC for Community Fund, on-chain Phase B

2.3 Provider Detail

Stripe Issuing + Treasury

  • What it does: Issues virtual and physical prepaid debit cards; holds USD balances; supports ACH
  • Licenses: Stripe's bank partners (M&T Bank, Evolve Bank) hold money transmitter and card issuer licenses — Stripe passes compliance coverage to its platform users
  • API access: Full REST API; sample app for Issuing + Treasury integration
  • KYC: Stripe handles KYC/AML for cardholders; sensitive onboarding practices configurable
  • Minimum requirements: No disclosed minimum; scales from early-stage startups
  • Best for: Phase A prepaid debit redemption
  • Stripe Issuing docs | Consumer Prepaid Debit Cards | Treasury + Issuing integration

Sila

  • What it does: Money API for fintech — ACH transfers, USD custody, KYC, token issuance
  • Licenses: Works with Fortress Trust (licensed custodian) for custody
  • Mission alignment: Explicit mission — "make finance work for all"; focused on financial inclusion
  • SILA tokens: 1:1 backed by US Treasury money market fund (can mirror MPWR's backing model)
  • KYC: Progressive disclosure model — low-friction for unbanked/underserved populations
  • API access: Full REST API
  • Best for: ACH redemption; mission-aligned choice for MPWR's target users
  • Sila Money API

Circle USDC + Programmable Wallets

  • What it does: Stablecoin infrastructure; programmable wallets; USDC for Community Fund
  • Licenses: Circle holds licenses in multiple jurisdictions; USDC is regulated stablecoin infrastructure
  • API access: Full SDK and REST API; wallet-as-a-service for embedded wallets
  • Best for: Phase B Community Fund USDC staking; on-chain wallet infrastructure
  • Circle Developer Platform | Programmable Wallets

Marqeta (Scale Path)

  • What it does: Card-as-a-service; real-time card issuing and processing; powers Square, Uber, Coinbase
  • Licenses: Works with partner banks (card networks + issuers); $200B+ annual TPV
  • API access: Real-time, API-first; best-in-class card issuing
  • Minimum: Negotiable volume-based pricing; startup-friendly at lower tiers
  • Best for: Phase A+ / Phase B when card issuance volume justifies switching from Stripe
  • Marqeta Platform | Card Issuing APIs Guide

BitGo, Fireblocks, Anchorage Digital, Coinbase Prime, and Gemini Custody all hold the right licenses (FinCEN MSB, OCC charters, state trust charters) but target institutional clients with $1M+ AUM minimums and enterprise pricing. These are appropriate for Phase B on-chain custody — not Phase A.

Provider Licenses Min Requirements Phase
BitGo FinCEN, OCC Bank charter, NYDFS trust Enterprise ($1M+ implied) Phase B only
Anchorage Digital OCC national bank charter, NYDFS BitLicense Enterprise Phase B only
Gemini Custody NY State Trust Company $30/month/asset min Phase B consideration
Circle Multi-jurisdiction Developer-friendly Phase B (USDC layer)

2.4 KYC for Vulnerable Populations

MPWR's target users (reentry, recovery, houselessness) face higher KYC friction:

  • Limited or no government ID
  • No credit history or bank account history
  • ID documents may be expired or missing

Recommended approach — Progressive KYC:

  1. Tier 1 (earning only): No KYC. User earns tokens and sees balance. No USD redemption.
  2. Tier 2 (redemptions <$600/year): Mobile-first eKYC — photo ID capture via NFC/OCR. Phone number verification. Low friction.
  3. Tier 3 (redemptions >$600/year): Full KYC — government ID + SSN or ITIN + 1099-NEC issuance.

KYC provider recommendations: - Stripe Identity (built into Stripe Issuing) - Persona (identity verification platform for fintechs) - In-app live chat/video support for users who struggle with documents

Source: au10tix — KYC Fintech Trends 2026

Part 3 — Technical Feasibility

3.1 USDC DeFi Staking Yields

Current USDC yields (May 2026):

Protocol APY Risk Network
Aave V3 3.70–4.41% Low (battle-tested) Ethereum, Base, Polygon
Compound V3 (Comet) 2.56–3% Low Ethereum, Base
Morpho Blue 4–8% Medium (curator-dependent) Ethereum, Base
Lido EarnUSD Blended (~4–6%) Medium (multi-protocol) Ethereum

Recommendation: Morpho Blue via a conservative curator for optimal yield with managed risk. Aave V3 as the fallback. Deploy on Base L2 to reduce gas costs by 10–100x vs. Ethereum mainnet.

Key risks:

  • Smart contract exploits: Use only audited, battle-tested protocols. Never use unaudited forks.
  • USDC depeg: Silicon Valley Bank collapse (March 2023) temporarily depegged USDC to $0.87. Diversify stablecoin reserves (USDC + USDT) for the Community Fund.
  • Bridged vs. native USDC: Always use native USDC on L2 (not bridged). Bridged USDC inherits bridge contract risk.

Sources: - Aavescan rates dashboard - Morpho Protocol 2026 - Stablecoin Yield Guide 2026 - Federal Reserve — SVB failure and stablecoin impacts - Lido EarnUSD launch — The Block

3.2 Token Ledger — Phase A (Centralized)

Two production-ready options for the mpwr-ledger backend:

  • Language: Go; exposes REST API (Node.js-friendly integration)
  • Features: Double-entry ledger, balance snapshots, inflight transactions, automatic reconciliation, append-only immutable log
  • License: Apache 2.0
  • Status: Production-grade; used by fintech companies
  • GitHub — blnkfinance/blnk
  • Language: Node.js + Mongoose + MongoDB (native to existing BNI stack)
  • Version: 7.2.0 (actively maintained, May 2026)
  • Features: True double-entry accounting, audit trails with non-destructive voiding, transaction atomicity
  • npm — medici | GitHub — flash-oss/medici

For maximum auditability: Custom append-only event log in PostgreSQL (no library needed). Every balance change = an INSERT, never an UPDATE or DELETE. Replay events to compute balances. This is the simplest pattern and the most auditor-friendly.

3.3 ERC-20 MPWR Token — Phase B

Standard: OpenZeppelin ERC-20 v5.5.0 (May 2026)

Recommended network: Base (L2)

Network Tx Cost Deploy Cost Notes
Ethereum (L1) $1–15 $200–500 Too expensive for micro-redemptions
Base $0.01–0.05 $1–3 Cheapest, Coinbase-backed, EIP-4844
Arbitrum $0.05–0.30 $5–10 Established alternative
Polygon $0.02–0.10 $2–5 High liquidity

Source: L2Fees.info | Base vs Arbitrum vs Polygon 2026

3.4 Community Fund — ERC-4626 Vault Standard

The right standard for the Community Fund is ERC-4626 — the tokenized vault standard for yield-bearing assets.

Why ERC-4626:

  • Standardized deposit/withdraw interface (compatible with all wallets and DeFi tools)
  • Share-based accounting — participants get proportional vault shares
  • Yield auto-compounds into shares
  • Production-pattern used by Yearn Finance vaults, Aave, and others

Reference implementation (unaudited — review only): - nickncn/Stable-Yield-Aggregator — ERC-4626 vault routing USDC across Aave v3, Compound v3, and Idle - Do not deploy to production without an independent security audit

Yearn Finance vault pattern (production reference): - Yearn yVaults documentation

Gas costs (Base L2): - Deploy vault: $1–3 - Deposit: $0.05–0.20 - Harvest/rebalance: $0.10–0.50 (automated via keeper bot)

3.5 W3C Verifiable Credentials + Identity

MPowerUP already uses did:key (Ed25519) for user identity. The integration with Phase B on-chain wallets requires a bridging decision:

Challenge: did:key uses Ed25519; Ethereum uses secp256k1. They are not directly compatible.

Recommended approach:

  • Keep did:key for identity credentials (KYC attestation, phone verification, Circle membership proofs)
  • Issue a separate Ethereum HD wallet (BIP44: m/44'/60'/0'/0/0) for on-chain custody
  • Link them in the MPWR ledger: user_id → { did_key, ethereum_address }
  • In Phase B: issue W3C Verifiable Credentials attesting to stake balance and KYC status

W3C standards: - W3C DID Core v1.0 - did:key specification - W3C Verifiable Credentials Data Model - W3C Universal Wallet Interop Spec - DID and VC Tech Landscape 2025 — GS1

3.6 Mobile Wallet Integration (React Native / Expo)

Phase A: No crypto wallet needed. USD redemption via Stripe prepaid debit (no wallet UX required).

Phase B: On-chain MPWR requires wallet integration.

Solution Embedded Wallet External Wallets Status Best For
WalletConnect v2 No 500+ Production Connecting user's existing wallets
Privy Yes Yes Production Creating wallets for new users
Thirdweb v5 Yes Yes Production All-in-one; newest SDK
Dynamic.xyz Yes (MPC) Yes Alpha (RN) Future multi-chain

Recommendation for Phase B: WalletConnect v2 for connecting existing wallets; Privy or Thirdweb for creating embedded wallets for users without an existing crypto wallet (likely most of MPWR's target users).

Sources: - WalletConnect React Native docs - walletconnect-expo-example - Privy React Native - Thirdweb React Native v5 - Dynamic.xyz React Native

3.7 Technical Stack Summary

Phase A (BNI-managed)
├─ Ledger backend:  Medici (npm) → PostgreSQL (MVP) | Blnk Core API (scale)
├─ Card issuance:   Stripe Issuing (prepaid debit)
├─ ACH redemption:  Sila (mission-aligned) | Dwolla (alternative)
├─ USD custody:     Stripe Treasury (FDIC-insured)
└─ KYC:             Stripe Identity + Progressive disclosure tiers

Phase B (on-chain)
├─ Network:         Base L2 (cheapest gas, Coinbase-backed)
├─ Token:           ERC-20 (OpenZeppelin v5.5.0) + ERC20Permit + ERC20Burnable
├─ Community Fund:  ERC-4626 vault → Morpho Blue / Aave V3 (USDC yield)
├─ Stablecoin:      Circle USDC (native on Base, not bridged)
├─ Mobile wallet:   WalletConnect v2 (existing wallets) + Privy (new users)
└─ Identity bridge: did:key (credentials) + BIP44 Ethereum wallet (custody)

Feasibility by component:

Component Ready Risk
Centralized ledger (Phase A) ✅ Multiple production options Low
USDC DeFi staking ✅ Live 3–8% APY Medium (depeg, exploit)
ERC-20 MPWR token ✅ Battle-tested standard Low
ERC-4626 Community Fund ✅ Standard + OZ implementation Medium (needs audit)
Mobile wallet (Phase B) ✅ Production SDKs available Low
did:key ↔ Ethereum bridge ⚠️ Non-standard, needs design Medium

Part 4 — Donor-Funded Models (Alternative & Supplementary Funding Patterns)

Validation status: [HYPOTHESIS] throughout this section unless a specific external reference is cited. Patterns described below have operating precedent in other contexts; their application to BNI's specific projects has not been piloted.

Why this section exists: The funding model in Parts 1–3 — BNI LLC commits 10% of revenue to a Backing Pool that prices participants' acts of care in USD — creates the specific harms the red team documented (motivation crowding-out, SSI cliff, fiduciary obligation on vulnerable people's pooled money). Part 4 maps three structurally different funding patterns that donors can use to support the program without requiring tokenized pricing of individual mutual aid. These patterns are orthogonal: any subset of them can run alongside MPWR-as-currently-designed, or alongside the time-banking alternative (now also published on this site under Sub-Project Docs → MPowerUP → Research), or on their own.

Cross-references: [[red-team-mpowerup#Challenge 1]] (motivation crowding-out), [[red-team-mpowerup#Finding 2]] (Samaritan / Beam / GoodDollar precedents), [[red-team-mpowerup#Challenge 2]] (SSI cliff), MPWR Alternative — Time Banking Model (the candidate replacement these patterns can fund), Circle Governance and Milestone Economy (synthesis layering Pranis circle process and milestone economy on top of time banking).

4.1 Donor Blockchain Infrastructure

Question: Can a blockchain layer add value to donor funding of MPowerUP without becoming blockchain-theater or creating new harms?

Answer: Yes — in narrow, well-defined roles. The patterns below name what blockchain genuinely adds, what it cannot add, and what it makes worse.

What a donor blockchain is for

Three functions that benefit from blockchain primitives, distinguished from functions that don't:

Function Blockchain adds value? Why
Donation transparency / public attribution Yes Immutable, publicly-readable donation log without a trusted operator
Programmable escrow (donor funds → conditional payout to a merchant/vendor) Yes Smart-contract escrow released on signed event; no platform staff in the loop
Receipt / tax-record generation Yes (modest) Non-fungible receipt token (ERC-721 or soulbound ERC-1155) — donor keeps a verifiable receipt without BNI database dependency
Quadratic funding for donor matching Yes Gitcoin Grants pattern; small donors gain matching weight, reducing wealth-weighted distortion
Donor governance / voting No — actively harmful 1-dollar-1-vote is wealth-weighted democracy at a charity. Use traditional 501(c)(3) board governance or participatory budgeting instead.
Recipient identity / consumption tracking No — actively harmful On-chain recipient identities = permanent public surveillance of the most vulnerable. See 4.3.
Replacing a coordinator / human role No The Cahn-model evidence is unambiguous: coordinator-mediated matching outperforms pure-protocol matching. Blockchain cannot replace this.

[HYPOTHESIS] — this design has not been piloted by BNI.

Donor → Front-end DApp (or simple web form with embedded wallet)
       ↓
   Donation flow:
       USDC on Base L2 → MPowerUP Donor Pool smart contract (ERC-4626-style)
       ↓
   Receipt mint:
       Soulbound ERC-1155 receipt token → donor wallet (non-transferable, tax-friendly)
       ↓
   Pool routing (governed by 501(c)(3) board, not on-chain vote):
       ├── Operations bucket → off-chain ACH to coordinator stipends, hosting, partner orgs
       ├── Community resource staking bucket → see 4.2
       └── Suspended-merchant escrow bucket → see 4.3 (smart contract releases on merchant claim)
       ↓
   Public donation explorer (read-only block explorer + friendly UI showing
       aggregate flows; NO recipient identities)

Why Base L2: Already justified in §3.3 — lowest gas, Coinbase-backed, native USDC, Proof-of-Stake consensus inherited from Ethereum post-Merge. Carbon footprint per transaction is [HYPOTHESIS] orders of magnitude lower than pre-Merge PoW chains; treat the specific magnitude as illustrative until measured.

Per the Sustainability & Carbon Awareness Standing Directive (canonical in big-nerd-idea/CLAUDE.md in the repository root): No Proof-of-Work chain is acceptable for this use case. Bitcoin, Bitcoin SV, Bitcoin Cash, Ethereum Classic, and Dogecoin are out. Stake-based chains (post-Merge Ethereum, all major L2s, Solana, Cosmos chains) are in. Carbon claims about "blockchain has lower footprint than X" should remain [HYPOTHESIS] unless measured against a stated methodology.

Reference implementations (operating donor-blockchain projects)

Project URL Pattern Notes
Giveth giveth.io Open-source donation platform on Ethereum/Optimism/Celo; quadratic matching Strongest existing open-source codebase; verified projects model
Gitcoin Grants gitcoin.co/grants Quadratic funding rounds with matching pools The originating quadratic-funding implementation
Endaoment endaoment.org Donor-Advised Fund (DAF) on-chain; IRS-compliant 501(c)(3) US tax-deductible giving with on-chain receipts
Octant octant.app Golem Foundation; community-driven public goods funding via staked ETH yield Yield-funded model — donor stake earns yield that funds grants
Optimism RetroPGF optimism.io/retropgf Retroactive public-goods funding by community vote Pattern: fund the work after it's done, not before
The Giving Block thegivingblock.com Crypto donation processor for 501(c)(3)s Easiest integration if BNI Foundation has 501(c)(3) status

What this does NOT solve

  • Coordinator labor is still needed — see 4.2 and the time-banking doc; smart contracts do not replace humans for matching, orientation, dispute resolution, or community trust-building.
  • KYC/AML still applies to redemptions on the back end — donor side may be permissionless; recipient cash-out side is not.
  • Privacy gap on the recipient side — donor anonymity is solved by default in most wallet-based donations; recipient anonymity is hard and requires deliberate architecture (4.3).
  • 501(c)(3) tax-deductibility for US donors requires the receiving entity (BNI Foundation) to have IRS 501(c)(3) status. The on-chain receipt is a convenience; the legal tax treatment is determined by the recipient entity's status. BNI Foundation is currently [HYPOTHESIS] — forming, per [[../about/index]].
  • Donor blockchain ≠ securities offering. As long as donors expect no financial return (the receipt is non-transferable, no yield flows back), this is a charitable donation, not an investment contract. Crossing this line is what makes Section 4.2 require careful design.
  • FinCEN treatment: A donor-pool smart contract that accepts USDC and pays out to vetted merchants/coordinators is functionally a charity wallet, not money transmission. Confirm with counsel before scaling.

4.2 Community Resource Staking

Question: Can donors "stake" funds toward shared community resources — Kitchen Garage cookware, Second Boot refurb tools, wholefolk procurement capital, a community fridge — in a way that is ethically clean and legally tractable?

Answer: Yes, but the investment-vs-grant boundary is the entire ethical and legal content of the design. Cross it the wrong way and the model becomes a securities offering with vulnerable people's money in it.

The boundary that matters

If the donor expects... Then it is... Implications
No return of principal, no yield Donation Tax-deductible (if 501(c)(3)), no SEC issue, no fiduciary structure required beyond charitable governance
Return of principal only (after N years), no yield Interest-free loan / patient capital Not a security; resembles a CDFI deposit. Requires contractual clarity.
Return of principal + yield generated by the resource Investment contract Securities territory. Howey test applies. Requires SEC review or exemption (Reg CF, Reg D, Reg A+). Do not implement without counsel.
Return of principal + yield, with donor governance Equity / cooperative shares Cooperative corporate form may apply; state-specific.
"Impact bond" — return of principal only if outcomes met Pay-for-success contract Complex; established in social impact finance but legally heterogeneous.

The current MPWR Community Fund (Parts 1–3) is described as "30% of every participant's tokens flow into a single collective fund... DeFi staking protocols in USDC, generating yield for the entire community... 40% distributed pro-rata → individual long-term stakes." That structure has investment-contract characteristics, which is why §1.1 above flags it as the main Howey-test risk. Community resource staking faces the same boundary and the same analysis.

Patterns that stay clean of the securities boundary

[HYPOTHESIS] — implementation in BNI projects is unbuilt; concept maps to existing community-finance precedents.

Pattern A — Patronage / sliding-scale (recommended baseline). Donors fund a community resource (Kitchen Garage, refurb lab, community fridge, suspended-coffee pool). Recipients access free or on sliding scale. Donors receive a receipt and gratitude, no return of any kind. Simplest legal posture; cleanest ethics. This is just charitable giving with extra steps.

Pattern B — Time-locked patronage (donor commits for N years). Donor commits funds for a multi-year program. Smart contract releases funds in tranches (annually, quarterly). Donor sees programmatic delivery. No yield back. Adds discipline without adding investment characteristics. Compatible with on-chain or off-chain implementation.

Pattern C — Yield-back-to-operations (donor principal preserved). Donor stakes USDC in a vault (ERC-4626, §3.4). Yield generated by DeFi staking flows to operations (coordinator stipend, suspended-coffee pool, refurb lab supplies). Principal is returned to donor on request after a lock-up period. This is structurally a charitable variant of a CD: donor lends capital, earns no yield personally, but supports community work via the yield stream. - Securities analysis: because the donor expects no yield to themselves, the Howey "expectation of profits" prong is weakened. Still requires counsel review — the line is subtle. - DeFi risk inherits everything from §3.4 and red team Challenge 3. This is not safer than the existing Community Fund design — it has the same depeg, contract-exploit, and yield-compression risk. The only thing that changes is whose money is exposed (donors who chose this with eyes open vs. participants who earned through care). - Recommendation: if this pattern is used, the smart contract MUST be audited (Trail of Bits, OpenZeppelin, Spearbit) and insured (Nexus Mutual, InsurACE) before any non-test funds enter.

Pattern D — Cooperative shareholding. Donors buy shares in a cooperative entity (the Kitchen Garage co-op, for example) and become voting members. State cooperative corporate law applies. This is cleaner structurally than the investment models above (cooperatives have specific securities exemptions in many states) but adds organizational complexity. Not recommended as a first-instantiation; valid for mature projects.

Pattern E — Impact bond / pay-for-success. Donor stake returned only if program meets outcome targets (X people housed, Y devices deployed, Z meals served). Legally complex; works for sophisticated donors and foundations. Not appropriate for retail donors or for early-stage programs without baseline outcome data.

Mapping to existing BNI projects

Resource Most suitable pattern Notes
Kitchen Garage (community kitchen) A (patronage) initially; D (cooperative) at maturity Cooking equipment, food sourcing, utility costs. Cooperative form aligns with Kitchen Garage's mission framing.
Second Boot (refurb lab) A or B (time-locked) Tools, parts, lease for makerspace. Time-locked patronage aligns with multi-year program planning.
wholefolk (procurement capital) C (yield-back) — but only after smart-contract audit and insurance Working capital for bulk-buy aggregation; yield-back model could fund the coordinator role while preserving donor capital.
Toaster Chef Trike (real-world) A (patronage) Capital cost for build; ongoing operating costs are stipend-funded.
MPowerUP coordinator role (under time-banking alternative) A Direct charitable grant to fund a paid coordinator; simplest model.
MPowerUP Backing Pool (under current per-act design) A or B If the per-act design is kept, donor money to the Backing Pool is the cleanest source of backing — and avoids the "BNI LLC revenue must materialize" dependency from red team Challenge 7.

Carbon framing (per Sustainability Directive)

Community-scale shared resources are inherently carbon-reduction patterns: a shared kitchen replaces N household kitchens for community meals; a refurb lab extends device lifespans; community-pooled procurement reduces logistics distance. These align with the Sustainability Directive's core thesis and should be framed as such in funder materials — [HYPOTHESIS] on specific tonnage until measured.

  • Securities attorney review of Pattern C (yield-back) before any non-test funds enter.
  • State-specific cooperative-law review if Pattern D is pursued.
  • Pay-for-success contract counsel if Pattern E is pursued.
  • For Patterns A and B (the recommended baselines), standard charitable-giving documentation and 501(c)(3) compliance — no novel legal work.

4.3 Micro-Sponsorship — The Cup-of-Coffee Pattern

Question: Can donors directly sponsor small consumables — a coffee, a sandwich, a transit ride — for community members in need, in a way that preserves dignity and avoids paternalism?

Answer: Yes, but only in specific architectural shapes. The same surface idea — "I want to pay for someone's coffee" — produces opposite ethical outcomes depending on how it's wired. This section names the seven design rules that separate the dignifying pattern (caffè sospeso) from the documented failure mode (Samaritan / GiveSafe).

The two patterns in this design space

[EMPIRICALLY VALIDATED] for the existence of both patterns; [HYPOTHESIS] for which one BNI's specific implementation would land on.

Pattern: Caffè sospeso (suspended coffee). Originating in Naples in the late 1800s and persistent today across Italy and globally. A patron pays for two coffees but consumes one — the second is held by the café for anyone who asks. The asker is not identified, not pre-qualified, not surveilled. The café and the patron preserve the asker's full dignity by treating them as a regular customer claiming a regular product. The model has spread to "suspended meals" at restaurants, "suspended haircuts" at barbers, and to broader community-fridge / pay-it-forward models. It is fundamentally a dignity-preserving architecture.

Pattern: Samaritan / GiveSafe. Operated in Seattle (2017–2022). Houseless individuals were given Bluetooth beacons; donors saw them via app and donated. Spending was restricted to approved merchant categories (food, hygiene, clothing, prescriptions — not, say, a bus ticket to leave town or a haircut for a job interview). Recipients had to check in monthly with a nonprofit counselor or have their beacon deactivated. Critiqued in Jacobin (2019) and subsequent reporting as paternalistic surveillance dressed as charity. The model treats the recipient's financial decisions as requiring external gatekeeping. Documented in [[red-team-mpowerup#Finding 2]].

Same surface idea. Opposite ethics.

The seven design rules that separate them

[HYPOTHESIS] synthesis from the comparison above; these are testable design rules, not validated outcomes.

  1. Anonymity of donor → anonymity of recipient. The donor does not know who claims it. The recipient is not identifiable as "the person who got the donated coffee." Suspended coffee works because the recipient is just another customer.
  2. Recipient chooses, donor doesn't. The donor funds a pool; the recipient picks what to consume from a broad menu. The donor does not get to specify "must be a sandwich, not a coffee" or "must be food, not cigarettes." Spending categories are recipient-controlled.
  3. No conditions, no check-ins. The Samaritan deactivation-if-no-counselor rule is the canonical violation. Suspended coffee just sits at the café; anyone can ask.
  4. Broad merchant network, not narrow. "Sponsor a coffee" only works if many cafés participate — recipient autonomy depends on having choices. A single approved merchant is a gatekeeper.
  5. Donor money goes merchant-to-merchant, not platform-to-recipient. Smart-contract escrow releases to the merchant on a signed "claim" event. The platform never holds the recipient's money. The recipient interacts with the merchant, not the platform.
  6. No spending-tracking back to donor. The donor sees aggregate metrics ("N coffees funded this month, M coffees claimed"), not individual events. "Alice ate a sandwich at Joe's Deli at 3pm" is surveillance. "120 sandwiches claimed this week across our network" is reporting.
  7. Reciprocity option built in. Best models let recipients also contribute to the pool when they're able — fluid roles, not fixed donor/recipient binary. This preserves dignity and prevents permanent labeling.

These rules are not optional architecture details. Violating any one of them moves the system from caffè-sospeso toward Samaritan.

Donor wallet → SuspendedPool.sol (ERC-4626-style escrow on Base)
              ↓
       Donation event emits:
         { donor: address (or anonymous), merchant_category: string, amount_usdc }
       Receipt NFT minted to donor (soulbound ERC-1155)
              ↓
   Recipient (anonymous, anyone) approaches a participating merchant
              ↓
   Merchant signs a "claim" transaction (web2 → web3 bridge):
         { merchant_id, category, amount_usdc, timestamp_only — NO recipient identity }
              ↓
   Smart contract releases USDC to merchant's wallet
              ↓
   Public dashboard shows aggregate flows only (no recipient data)

Critical architectural notes:

  • The "claim" transaction is signed by the merchant, not the recipient. The merchant is the on-chain participant. This is what preserves recipient anonymity.
  • Merchant onboarding is a vetted off-chain process (real-world relationships matter here — these are local partnerships, not anonymous wallets). KYB (Know-Your-Business) applies to merchants; KYC does NOT apply to recipients.
  • Pool can be category-restricted (the donor chose to fund "food" not "general") — but only at the category level, never at the individual transaction level. This preserves donor agency without surveilling recipient.
  • Pool size limits per merchant per day (rate-limiting against fraud) are operationally necessary; communicate these as merchant-side controls, not recipient-side ones.

Why blockchain helps here (genuinely, not as theater)

  • Smart-contract escrow removes platform liability: BNI does not custody the funds in transit between donor and merchant. The smart contract is the escrow.
  • Transparent aggregate metrics to donors without needing to publish recipient data.
  • Cross-platform compatibility: merchants accepting USDC payouts can be in the BNI network or any merchant accepting Base USDC, lowering onboarding friction.

Why blockchain hurts here if done wrong

  • If recipient identities are on-chain in any form, you have built permanent public surveillance of the most vulnerable. This is worse than a centralized database because it cannot be deleted. Do not link recipient DIDs to claim events.
  • If merchant claim events include recipient signatures, see above.
  • If the chain is Proof-of-Work, the carbon cost of providing a sandwich is morally absurd. PoS only.

This pattern is genuinely cleaner than per-act tokenization on most regulatory dimensions:

Concern Status under suspended-coffee pattern
FinCEN MSB registration Almost certainly not required. Donor → merchant payment via charitable pool is not money transmission. Confirm with counsel.
Securities (Howey) Not applicable. No investment, no expectation of return.
IRS — income to recipient Not income. Food/coffee received via this mechanism is in-kind support, not earned income. Per the SSA's Sept 30, 2024 rule change, food provided by "friends, family, or others" is no longer counted as ISM for SSI. A community-funded suspended-sandwich pool falls squarely in this category.
IRS — donor side Tax-deductible if BNI Foundation has 501(c)(3) status. Receipt NFT is sufficient documentation.
State MTL Not applicable. No interstate money transmission to recipients.
Sales tax Merchant collects normally on the transaction; pool funds the merchant's gross receipts. Standard merchant tax handling.
KYC KYB on merchants only. No KYC on recipients.

The SSA rule change cited above is the single largest regulatory advantage of this model for the MPWR target population. Per §1.5 above, food provided informally is no longer ISM. Suspended-coffee and suspended-sandwich models are explicitly the kind of informal community food support the SSA's revised rule protects. This sidesteps the SSI cliff problem entirely for the categories it covers (food, and arguably other in-kind goods).

Concrete BNI implementations to consider

[HYPOTHESIS] — none are committed.

  • Suspended-coffee partnership in Charleston WV with 2–3 independent cafés willing to accept USDC settlement weekly. Pool funds visible on dashboard at [bignerdidea.com] (when live). MPowerUP Circle members ask at the counter; no app interaction required.
  • Suspended-sandwich at Kitchen Garage when Kitchen Garage opens. Kitchen Garage operates as the merchant; the pool funds free meals available to anyone walking in. No identification, no qualification.
  • Suspended-refurb at Second Boot. Donors fund a "scholarship pool" that covers the curriculum-completion cost for a participant who has completed the 8-module curriculum. Pattern: cost is real (the laptop costs to refurb); the recipient is anyone who completed the work; donor money pays the program, not the participant.
  • Suspended-transit. Donors fund a pool that pays for bus passes at local transit agencies. Recipient asks the driver / transit office. Most operationally complex (transit agencies are not USDC-ready); least theoretically novel.

What this does NOT do

  • It does not provide cash to recipients. Same limitation as time-banking (peer-aid layer). If cash is needed, the stewardship-stipend layer from the time-banking doc remains the right vehicle.
  • It does not scale automatically — every merchant must be onboarded individually. The labor of building merchant relationships is real and ongoing.
  • It does not replace mutual aid between peers — it supplements it by providing a backstop pool that donors fund for moments when peer aid is insufficient.

4.4 Pattern Selection Matrix

A summary view across all funding patterns now documented in BNI:

Pattern Donor sees Recipient experience Cash to recipient? Major risk Doc home
Per-act MPWR token Pool balance, action ledger, token rate Earns priced tokens for individual acts of care Yes (USD redemption) Crowding-out, SSI cliff, GoodDollar-class exploit Parts 1–3 above; [[MPowerUP Token Economy]]
Time banking Coordinator funded, member-org exchange logs Reciprocal hours, no $ at peer layer No (or via stewardship-stipend pairing) Coordinator dependency, skills-mismatch mpowerup/.../MPWR Alternative — Time Banking Model.md
Stewardship stipend Wage records on commons-labor roles Paid work on community resources Yes (wage) Employment-law surface; SSI cliff if not capped Time Banking doc, Option A
Donor blockchain (operations float) Public donation log, receipt NFT Indirect benefit (platform/coordinator exists) No (donor pays operations) Blockchain operational complexity, smart-contract risk §4.1 above
Community resource staking — Pattern A "I funded the Kitchen Garage" Free/sliding-scale access to shared resource No (resource access) None novel beyond charitable governance §4.2 above
Community resource staking — Pattern C (yield-back) Principal preserved, yield supports ops Free/sliding-scale access No DeFi exploit, depeg, yield compression §4.2 above
Micro-sponsorship (suspended coffee) "N coffees funded this month" aggregate Anonymously claims at merchant counter No (consumable received) Paternalism if any of the seven rules is violated §4.3 above

No combination is mandatory. Each row is an independent funding pattern. BNI can run any non-empty subset. The combinations most worth exploring:

  • Time banking + stewardship stipend + suspended coffee + community resource staking (A). The "everything except per-act tokenization" stack. Cleanest ethically; most distance from the red team findings; least cash-promise to participants.
  • Per-act MPWR + donor blockchain. Keeps current design; adds transparency and donor receipts. Does not address the underlying red team concerns.
  • Time banking + suspended coffee. Smallest viable program. Donor money funds coordinator + suspended pool; peer layer is time-credited. Zero on-chain identity exposure for recipients.

4.5 Action Items for Part 4

[HYPOTHESIS] — these are unresolved decisions. None should be marked complete without the corresponding artifact existing.

Action Owner Status
Decide whether 501(c)(3) status (BNI Foundation) is formed before any donor-blockchain pattern is implemented BNI leadership Pending
Securities counsel review of Pattern C (yield-back staking) if pursued Securities attorney Not started
Smart contract audit for any donor-pool contract (4.1) or yield-back vault (4.2 C) Audit firm (Trail of Bits / OpenZeppelin / Spearbit) Not started; budget item
Identify 2–3 Charleston WV merchant partners for suspended-coffee/sandwich pilot BNI partnerships Not started
Choose initial pattern combination — see "combinations most worth exploring" above BNI leadership Pending decision
Verify SSA Sept 30, 2024 ISM rule change interpretation with WIPA counselor WIPA partner (pending) Pending
Quadratic-funding integration evaluation (Gitcoin Grants / Octant) BNI engineering Not started
Decide donor-blockchain governance model (explicit rejection of 1-dollar-1-vote) BNI leadership Pending

Appendix — Full Reference List

Document Publisher Date URL
Application of FinCEN Regulations to Virtual Currency Administrators FinCEN March 2013 link
FinCEN MSB Registration FinCEN Current link
SEC Framework for Investment Contract Analysis SEC 2019 (superseded 2026) link
SEC Project Crypto — 2025 approach SEC 2025 link
SEC v. Ripple Howey analysis Fenwick July 2023 link
SEC 2025 token guidance explainer CoinTelegraph 2025 link
CSBS Money Transmission Modernization Act CSBS Current link
Money Transmitter License Requirements by State RidgewayFS 2026 link
NYDFS Money Transmitter Licensing NYDFS Current link
IRS Notice 2014-21 — Virtual Currency Tax Treatment IRS March 2014 link
IRS Form 1099-DA Instructions 2025 IRS 2025 link
IRS FAQ on Virtual Currency IRS Current link
IRS Final Regs — Digital Asset Broker Reporting IRS 2024 link
SSA POMS SI 00820.500 — Earned Income Exclusions SSA Current link
SSA — Understanding SSI Income Rules SSA Current link
SSA 2026 Guide to SSI SSA 2026 link
Justice in Aging — SSI In-Kind Support Rules Justice in Aging 2024 link
USDA SNAP Eligibility USDA FNS Current link
FinCEN Final Rule on Prepaid Access FinCEN July 2011 link

Technology

Resource Publisher URL
Blnk Finance Core (ledger) Blnk Finance GitHub
Medici (Node.js double-entry) flash-oss GitHub / npm
OpenZeppelin Contracts v5 (ERC-20) OpenZeppelin GitHub / docs
ERC-4626 Tokenized Vault Standard Ethereum Foundation EIP / docs
OpenZeppelin ERC-4626 OpenZeppelin docs
Stable-Yield-Aggregator (reference only) nickncn GitHub
Yearn yVaults Yearn Finance docs
Aave V3 Aave app / Aavescan
Morpho Blue Morpho morpho.org
W3C DID Core v1.0 W3C spec
did:key specification W3C CCG spec
W3C Verifiable Credentials W3C spec
WalletConnect React Native Reown docs
walletconnect-expo-example clxyder GitHub
Privy React Native Privy docs
Thirdweb React Native v5 Thirdweb docs
L2Fees.info Community l2fees.info

Custodians & Fintech Providers

Provider URL
Stripe Issuing stripe.com/issuing
Stripe Issuing — Consumer Prepaid Debit docs
Sila Money API silamoney.com
Circle Developer Platform circle.com/developer
Circle Programmable Wallets blog
Marqeta marqeta.com
Dwolla dwolla.com
Modern Treasury moderntreasury.com
BitGo Licenses bitgo.com/company/licenses
Anchorage Digital Custody anchorage.com/platform/custody
Gemini Custody gemini.com/institutions/custody
KYC Fintech Trends 2026 au10tix

Donor-Funded Models (Part 4)

Resource Publisher URL
Giveth (open-source donation platform) Giveth giveth.io
Gitcoin Grants (quadratic funding) Gitcoin gitcoin.co/grants
Endaoment (on-chain DAF, 501(c)(3)) Endaoment endaoment.org
Octant (yield-funded public goods grants) Golem Foundation octant.app
Optimism RetroPGF Optimism retropgf
The Giving Block (crypto donation processor) Shift4 / The Giving Block thegivingblock.com
Caffè sospeso — Wikipedia overview Wikipedia Suspended coffee
Cahn, Edgar S. No More Throw-Away People (2nd ed., 2004) Essential Books Foundational text for time-banking. Free to Read: Internet Archive
TimeBanks USA — Cahn's founding organization TimeBanks.org timebanks.org
hOurworld — practitioner time-bank platform hOurworld hourworld.org
Quadratic Funding paper (Buterin, Hitzig, Weyl) arXiv arxiv.org/abs/1809.06421
SSA — Sept 30 2024 ISM Final Rule (food no longer counted as ISM) SSA SSI policy changes 2024 — verify URL with counsel before citation
Jacobin critique of Samaritan/GiveSafe (2019) Jacobin (cited via [[red-team-mpowerup#Finding 2]]; primary URL to be verified)
Trail of Bits (smart-contract audit firm) Trail of Bits trailofbits.com
OpenZeppelin (audit + library) OpenZeppelin openzeppelin.com
Spearbit (audit firm) Spearbit spearbit.com
Nexus Mutual (DeFi insurance) Nexus Mutual nexusmutual.io
InsurAce (DeFi insurance) InsurAce insurace.io