Avelia — Payment & Identity Architecture

Date: 2026-04-11 Status: Decided. Implementation targeted for Phase 1 launch. Owner: Anton Anders Legal entity: Avelia Health GbR (Germany)

---

1. Summary

Avelia supports three user paths with progressive privacy/convenience trade-offs. All three are available on iOS and Android from day one. The Standard path is the default for ~90% of users. The Anonymous and Avelia Fund paths use the same in-app redemption flow.

Path	Who	Signup & payment	Identity visible to
Standard	Default. ~85-90% of users.	In-app signup (email + password). Apple IAP or Google Play Billing.	Apple/Google (not Avelia directly — via appAccountToken)
Anonymous (paid code)	Privacy-conscious users. ~8-12%.	In-app redemption of a pre-minted code obtained externally (clinic, midwife, gift).	Nobody. Avelia never sees a real-world identity.
Avelia Fund (free code)	At-risk users, underserved regions, financially constrained. ~2-5%.	Same as Anonymous, but code was issued free by a partner NGO from the Avelia Fund.	Nobody.

Core architectural principle: the three paths differ only at the user-facing layer (signup, payment). Internally, every account is represented by a UUID and every entitlement is keyed by hash(UUID). No database query in Avelia infrastructure should be able to answer "show me the content for user user@example.com".

---

2. Why this model

1. Privacy without usability cliff. Standard users get the familiar mobile-app experience. Users who need anonymity can achieve it via a single well-understood pattern (gift-card redemption).
2. Externalised trust. Clinics, midwives, and advocacy NGOs already have trust relationships with at-risk populations. Making them the distribution channel is more effective than Avelia trying to build anonymous payment rails.
3. Apple/Google review friendly. Both stores explicitly allow gift code redemption in-app (Spotify, Microsoft Office, Adobe, Netflix all do this). No anti-steering issues.
4. Architecturally simple. No web-based Stripe signup flow. No dual-mode checkout. The entire anonymous flow is a single API endpoint (POST /api/codes/redeem) that returns an account UUID.
5. Strong moral positioning. "Avelia Fund" is a concrete mechanism, not a vague promise. "We're so committed to privacy that we give our app away free to people who can't safely pay for it" is a differentiator that competitors structurally cannot copy (they don't have zero-knowledge architecture to back the promise).

---

3. The three user paths — full flows

3.1 Standard (Apple IAP / Google Play Billing)

Signup:

1. User opens app, taps "Create account"
2. Enters email + password
3. Account UUID generated locally, sent to server with hashed password + email
4. Server creates records in auth_db:
   • account { id: UUID, auth_method: 'email', created_at }
   • account_email { account_id, email_hash, email_enc } — separate table, separate column encryption
5. Server returns JWT with account_uuid + session token

Upgrade to Premium (iOS):

1. User taps "Upgrade"
2. App calls StoreKit 2 with appAccountToken = hash(account_uuid)
3. Apple presents purchase UI, user confirms
4. Apple returns signed receipt (JWS)
5. App sends receipt to Avelia server
6. Server verifies receipt via Apple's verifyReceipt API
7. Extracts appAccountToken from verified receipt (which is hash(account_uuid))
8. Writes to entitlement_db:
   • entitlement { account_uuid_hash, tier: 'premium', source: 'apple_iap', valid_until, renewal_info }
9. Client polls / receives push update → unlocks Premium features

Upgrade to Premium (Android): Same pattern with Google Play Billing Library:

• PurchaseParams.obfuscatedAccountId = hash(account_uuid)
• Receipt verification via Google Play Developer API
• Same entitlement_db write

Key property: Avelia's server never sees the user's Apple ID or Google account. Only the opaque appAccountToken / obfuscatedAccountId hash.

Renewal/cancellation:

• Apple Server Notifications v2 → webhook handler → update entitlement row
• Google Real-time Developer Notifications → webhook handler → update entitlement row

3.2 Anonymous (paid code)

Obtaining a code:

• User gets a code via:
  • Their clinic or midwife (clinic bought a bulk pack from Avelia)
  • A friend who bought a gift code on avelia-health.com/gift (web, not app)
  • A partner reseller (future channel)

Signup & redemption:

1. User opens app, taps "I have a redemption code"
2. Pastes code (format: AVELIA-XXXX-XXXX-XXXX) or scans QR
3. App sends to POST /api/codes/redeem with the code
4. Server:
   • Hashes the code, looks it up in code_db
   • Validates: status=distributed (not yet redeemed), not expired, not revoked
   • Generates new account_uuid
   • Writes account { id, auth_method: 'code', created_at } to auth_db
   • Writes account_number { account_id, number_hash } (for future login)
   • Writes entitlement { account_uuid_hash, tier, source: code.source, valid_until }
   • Marks code { status: 'redeemed', redeemed_at, redeemed_account_uuid }
   • Returns { account_number: "7234-9182-6541-0398", account_uuid, entitlement }
5. App prompts user to set a passphrase
6. App generates Recovery Kit (QR code with recovery material) — user must save before proceeding
7. App stores account_number + encrypted Master Encryption Key locally
8. Subscription active, user is fully onboarded

Login on a new device:

1. User taps "Log in with account number"
2. Enters account number + passphrase OR scans Recovery Kit QR
3. Server verifies, returns session token
4. App syncs encrypted blobs

Key property: Avelia has no email, no card, no partner-linked identity for this user. The only data points are the code (which is not traceable to a real person) and the account UUID. The user is responsible for their own recovery.

3.3 Avelia Fund (free code)

Flow is identical to anonymous paid code, except:

• The code was generated via the partner portal (free of charge to Avelia)
• code.source = 'fund:<partner_id>'
• code.cost = 0 (for internal accounting)

User experience is indistinguishable from a paid anonymous code. This is intentional — Fund recipients should not feel like second-class users.

---

4. Database architecture

4.1 Separation principle

Four databases, strict access boundaries:

┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│   auth_db    │  │ entitlement  │  │  payment_db  │  │   data_db    │
│              │  │     _db      │  │              │  │              │
│ account      │  │ entitlement  │  │ apple_       │  │ blob         │
│ account_     │  │  (by uuid_   │  │  subscription│  │  (by uuid)   │
│  email       │  │   hash)      │  │ google_      │  │ sync_state   │
│ account_     │  │              │  │  subscription│  │              │
│  number      │  │              │  │              │  │              │
│              │  │              │  │ (no account  │  │              │
│              │  │              │  │  FK)         │  │              │
└──────────────┘  └──────────────┘  └──────────────┘  └──────────────┘
                         │                │
                         └────────┬───────┘
                                  │
                                  ▼
                         ┌──────────────┐
                         │   code_db    │
                         │              │
                         │ code         │
                         │ partner      │
                         │ mint_batch   │
                         └──────────────┘

Enforcement: different PostgreSQL instances (or at minimum, different schemas with different roles). The data_db role has no permission to query auth_db, payment_db, or entitlement_db. Application services that need to cross the boundary do so via explicit service-to-service API calls, not database joins.

4.2 Cross-database linkage rules

• data_db.blob.account_uuid is the only way to find a user's content
• entitlement_db.entitlement.account_uuid_hash = sha256(account_uuid) — a one-way mapping
• To check "does this account have Premium?": service receives account_uuid from session token, computes hash, queries entitlement_db. No lookup by email possible.
• payment_db stores Apple/Google subscription metadata keyed by the STORE's subscription ID, NOT by Avelia's account_uuid. The link exists only in the entitlement_db record that was written at purchase time.
• Under a court order: Avelia can produce payment records (keyed by Apple/Google subscription IDs, not emails), and content blobs (keyed by UUID). But it cannot join them without the entitlement_db as a bridge — and the entitlement_db stores only hash(UUID), not UUID. Producing the intersection requires knowing either the user's UUID in advance, or brute-forcing UUID hashes (4.3 billion candidates — impractical).

4.3 What a subpoena produces

If compelled by a court to "produce everything about user X":

Ask	Response
"All data for email user@example.com"	Payment records, if Standard path. Encrypted blobs found via the user's account UUID (stored in auth_db keyed by email). The content is unreadable — we return ciphertext only.
"All data for Apple ID X"	Empty. Avelia has no Apple ID.
"All data for code AVELIA-XXXX-XXXX-XXXX"	The code's redemption status and source partner. No link to encrypted blobs unless we also know the account UUID.
"All data for account number 7234-9182-6541-0398"	Encrypted blobs under the matching UUID. Ciphertext only — we have no decryption key.
"List of accounts linked to user@example.com"	For Standard users: one. For Anonymous: none.

The zero-knowledge promise becomes a legal defence: we cannot be compelled to produce what we do not have and cannot compute.

---

5. Code system

5.1 Format

AVELIA-XXXX-XXXX-XXXX

• 12 alphanumeric characters in 3 dash-separated blocks
• Character set: ABCDEFGHJKLMNPQRSTUVWXYZ23456789 (ambiguity-free: no 0/O, 1/I/l, B/8)
• ~57 bits of entropy (32^12 ≈ 1.15 × 10^18) — brute force impractical even without rate limiting
• Also rendered as QR code for in-app scanning (just the full code string, no special encoding)
• Speakable on a phone call for verbal distribution in clinics

5.2 Metadata schema

CREATE TABLE code (
  id UUID PRIMARY KEY,
  code_hash BYTEA UNIQUE NOT NULL,       -- SHA-256 of the plaintext code
  tier TEXT NOT NULL,                     -- 'light' | 'premium'
  duration_months SMALLINT NOT NULL,      -- typically 12
  source TEXT NOT NULL,                   -- 'fund:<partner_id>' | 'partner:<partner_id>' | 'gift'
  mint_batch_id UUID NOT NULL REFERENCES mint_batch(id),
  minted_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  status TEXT NOT NULL DEFAULT 'minted', -- 'minted' | 'distributed' | 'redeemed' | 'revoked' | 'expired'
  expires_at TIMESTAMPTZ NOT NULL,       -- default now() + 3 years (German statutory minimum for gift vouchers)
  redeemed_at TIMESTAMPTZ,
  redeemed_account_uuid UUID,
  notes TEXT                             -- free-text for operators
);

CREATE TABLE mint_batch (
  id UUID PRIMARY KEY,
  partner_id UUID REFERENCES partner(id),
  count INTEGER NOT NULL,
  tier TEXT NOT NULL,
  duration_months SMALLINT NOT NULL,
  cost_cents INTEGER NOT NULL,           -- 0 for Fund batches
  minted_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  minted_by TEXT NOT NULL                -- email of operator
);

CREATE TABLE partner (
  id UUID PRIMARY KEY,
  name TEXT NOT NULL,
  type TEXT NOT NULL,                    -- 'clinic' | 'midwife' | 'ngo' | 'reseller' | 'fund'
  country TEXT NOT NULL,                 -- ISO-3166
  contact_email TEXT,
  active BOOLEAN NOT NULL DEFAULT true,
  fund_quota_per_month INTEGER,          -- null for non-fund partners; monthly allowance
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

5.3 Lifecycle

1. Minted — Avelia operator or partner portal generates a batch. Codes are stored hashed; the plaintext is returned ONCE as a CSV/PDF to the partner. If the partner loses the file, the batch can be re-generated (with a new batch, revoking the old).
2. Distributed — Partner hands code to end user (patient, client, friend). Avelia doesn't track this explicitly; the status stays minted until redemption. Optional: operator can mark batches as "delivered" for accounting.
3. Redeemed — User redeems in-app. status → redeemed, redeemed_at and redeemed_account_uuid set.
4. Revoked — If a batch leaks or a partner relationship ends. All codes in the batch with status != 'redeemed' are marked revoked. New replacement batch can be minted for the partner.
5. Expired — Automatic job runs nightly, marks codes with expires_at < now() AND status = 'minted' as expired.

5.4 Expiration: 3-year minimum (Germany)

German civil law (BGB §195) sets the standard limitation period at 3 years. Gift vouchers in Germany cannot expire in under 3 years unless the shorter period is explicitly justified. Avelia codes are analogous to gift vouchers and follow this rule.

Default: 3 years from mint date. Partners can request longer (e.g., 5 years) for specific campaigns. Shorter is not permitted without case-by-case legal review.

Operationally: unused codes don't cost us anything, so the default is liberal.

5.5 Revocation mechanics

If a batch must be revoked (partner breach, loss of control, partner relationship ending):

1. Operator invokes /api/admin/batches/:batch_id/revoke with a reason
2. Server marks all codes in batch with status = 'minted' → 'revoked'
3. Codes already redeemed are NOT affected (the users keep their subscription)
4. Operator generates a new batch of equivalent size for the partner, delivers new codes
5. Event logged in audit trail

5.6 Anti-abuse

• Rate limiting on redemption endpoint: max 5 attempts per IP per hour, max 20 per 24h
• Invalid-code attempts logged with IP + user-agent (but not with any other PII)
• Codes are hashed server-side; never stored in plaintext after minting
• Code generation uses cryptographic RNG (not Math.random)
• Codes are always transmitted over TLS

---

6. Apple IAP integration details

6.1 Product configuration

In App Store Connect, set up auto-renewable subscription products:

• com.avelia.premium.monthly — €8.99/month
• com.avelia.premium.yearly — €79.99/year
• com.avelia.light.monthly — €2.99/month
• com.avelia.light.yearly — €26.99/year

Each product is part of a Subscription Group called "Avelia Plans" so users can upgrade/downgrade smoothly.

6.2 Purchase flow (Flutter)

final product = await InAppPurchase.instance
    .queryProductDetails({'com.avelia.premium.yearly'});

await InAppPurchase.instance.buyNonConsumable(
  purchaseParam: PurchaseParam(
    productDetails: product.productDetails.first,
    applicationUserName: sha256(accountUuid).toBase64(), // maps to appAccountToken
  ),
);

The applicationUserName parameter on iOS becomes appAccountToken in the receipt. On Android it becomes obfuscatedAccountId.

6.3 Receipt verification (Backend)

• For iOS: verify JWS signed receipt via Apple's App Store Server API (/inApps/v1/transactions/{transactionId})
• For Android: verify via Google Play Developer API (purchases.subscriptionsv2.get)
• Extract appAccountToken / obfuscatedAccountId from the verified payload
• Look up matching Avelia account_uuid via hash(account_uuid) = token
• Write entitlement record

6.4 Server notifications

• Apple Server Notifications v2 webhook at /api/iap/apple/notifications
• Google Real-time Developer Notifications via Cloud Pub/Sub subscription
• Both update the entitlement record for cancellation, refund, grace period, etc.

6.5 What Apple/Google know vs what Avelia knows

Data point	Apple/Google	Avelia
User's real identity (Apple ID / Google email)	Yes	No
Payment method	Yes	No
Subscription status	Yes	Yes
Tier	Yes	Yes
Avelia account UUID	No	Yes
Account content	No	Encrypted only — unreadable

The appAccountToken / obfuscatedAccountId is a hash of the Avelia UUID. Apple/Google cannot reverse it to identify the Avelia account. Avelia cannot resolve it to an Apple ID.

This is actually stronger privacy than Stripe web checkout, because Stripe would attach the card + email directly to Avelia's payment records.

---

7. Partner portal (Phase 2)

The partner portal is a lightweight web application used by clinics, midwives, and NGOs to manage their codes. Built in Phase 2, after the app and backend MVPs.

7.1 Phase 1 MVP (launch)

For launch, we provide a manual process:

• Partners email Avelia with their code request
• Operator runs a CLI script to generate a batch
• Operator sends the CSV/PDF to the partner by encrypted email
• Audit trail kept in a simple database table

This is tolerable because launch will have <10 partners. Scales to ~50 before pain.

7.2 Phase 2 portal requirements

Full-featured web dashboard at partners.avelia-health.com:

• Authentication: per-partner accounts with 2FA, role-based access (admin, operator, viewer)
• Batch management: generate new batches, view existing, download CSVs, mark as distributed
• Quota tracking: partners with Fund quotas see their monthly allowance and usage
• Revocation: one-click revoke with reason, automatic replacement batch generation
• Statistics: redemption rate per batch, expiry forecasts (no per-user data)
• Audit log: who did what, when
• Multi-language: EN, DE at minimum; FR, IT, ES as partners scale

7.3 Phase 2 technical notes

• Stack: separate Astro SSR app (same framework as the marketing website for consistency)
• DB: shares code_db and partner tables with the main backend, different auth
• Hosted under the same infrastructure (Caddy + Docker) as other services
• Partner credentials: standard password + TOTP (no SSO in V1)
• Export: CSV + PDF. PDF includes the codes formatted for printing (one per page, with QR code and the code text in large print, ready to give to patients)
• Delivery: email a signed download link valid for 7 days; after download, the link is invalidated

---

8. Avelia Fund

8.1 Purpose

Free Avelia Premium licenses for users who cannot safely pay for the app themselves. Distributed via partner organizations, not directly by Avelia.

8.2 Funding

Budget: 5-10% of net revenue, reserved as a Fund line item in Avelia Health GbR's internal accounting. Each year's budget determines the number of Fund codes available.

Not reliant on external donations in Phase 1. Avelia Health GbR self-funds the program from subscription revenue. This keeps the program immediately viable without dependency on grant cycles.

Future: once the program is running and has a track record, apply for grants from:

• Mozilla Foundation (Privacy Not Included partners)
• Open Society Foundations (reproductive rights)
• Ford Foundation (technology + women's rights)
• German federal grants (BMFSFJ — gender equality, anti-violence)
• EU Daphne programme (violence against women)

Optional: "Sponsor an anonymous license" add-on at Premium checkout: +2€/month goes directly to the Fund. Opt-in, explicit, transparent. Introduces a user-driven funding flywheel.

8.3 Distribution partners

Tier A (launch partners):

• Hilfetelefon Gewalt gegen Frauen (Germany)
• Frauenhauskoordinierung (Germany — women's shelters umbrella)
• Pro Familia (reproductive health, Germany)
• bff — Bundesverband der Frauenberatungsstellen und Frauennotrufe (Germany)

Tier B (year 1 expansion):

• Women's Aid (UK)
• RAINN (US sexual assault support)
• 1800RESPECT (Australia)
• WAVE — Women Against Violence Europe (EU-wide)

Tier C (ongoing):

• Regional fertility advocacy organizations
• Refugee support organizations
• Student / low-income advocacy groups

8.4 Partner agreement

Each partner signs a simple MOU with Avelia Health GbR covering:

1. Purpose: partner may distribute Avelia Fund codes to individuals who would benefit from them, at the partner's discretion
2. No personal data sharing: partner does not share recipient identities with Avelia; Avelia does not request them
3. Monthly quota: agreed number of codes per month (can be adjusted)
4. Responsible distribution: partner will not publish codes publicly, will not redistribute to unauthorized third parties
5. Revocation rights: Avelia may revoke unredeemed codes at any time with notice, and issue replacements
6. Term: 12-month renewable, either party may terminate with 30 days' notice
7. Liability: partners act independently; Avelia is not liable for partner's distribution decisions

8.5 Operational model

Monthly cadence:

1. 1st of month: system checks partner quotas, generates new batches if needed
2. Operator reviews and approves batches (manual step in Phase 1, automated in Phase 2)
3. Batches delivered to partners via encrypted email
4. Partners distribute throughout the month
5. End of month: usage report generated, internal review

Annual transparency report:

• Total codes minted, total redeemed, breakdown by partner category
• Total budget spent
• NO per-user or per-recipient data — this is a structural privacy choice
• Published on avelia-health.com/avelia-fund/transparency-report-YYYY

8.6 Branding

Primary name: Avelia Fund Alternate name (if needed for specific audiences): Avelia Access Programme

The two names are interchangeable. Internal docs standardise on "Avelia Fund". Some partners may prefer the more clinical-sounding "Access Programme" in their own materials — that's fine.

8.7 Discovery for at-risk users

• Dedicated website page at /[lang]/avelia-fund
• Listed on the Safe Mode page alongside crisis helplines
• Referenced on the pricing section of the homepage with subtle "Can't safely pay? Learn about the Avelia Fund →" link
• Partner organizations mention Avelia in their own materials (website, brochures, hotline call scripts)
• Listed in llms.txt / llms-full.txt for LLM-driven discovery

---

9. Gift codes (web purchase, later rollout)

Not required for Phase 1 launch, but planned for year-1 expansion.

• Web flow at avelia-health.com/gift (not in-app, to avoid Apple IAP complications)
• User pays via Stripe (1-year Premium code, non-recurring)
• Receives code by email + displayed on screen
• Passes code to recipient by any means
• Recipient redeems in-app like any other code

Why web-only: Apple and Google both restrict "buying gift cards inside an app" because it looks like a payment workaround. Web is the clean path.

Privacy consideration: the purchaser's email is on the purchase record, but there's no link from purchaser to redeemer. Avelia knows "email X bought a code, code Y was redeemed" — the bridge is the code string, which is not a durable identifier of the purchaser.

---

10. Economics

10.1 Per-user contribution (rough)

Source	% of users	Retail price	After fees	Gross to Avelia
Apple IAP Premium (yearly)	~45%	€79.99/yr	-15% Apple	~€68
Google Play Premium (yearly)	~35%	€79.99/yr	-15% Google	~€68
Apple IAP Light (yearly)	~5%	€26.99/yr	-15% Apple	~€23
Google Play Light (yearly)	~4%	€26.99/yr	-15% Google	~€23
Partner clinic codes	~6%	€60 bulk (vs €79.99 retail)	-0%	~€60
Gift codes (web)	~3%	€79.99/yr	-3% Stripe	~€78
Avelia Fund codes	~2%	€0	Cost center	-€10 avg cost

10.2 Fund budget

5-10% of net revenue → Fund cost center.

Example: at €500k/yr net revenue, Fund budget = €25k-€50k/yr. If Fund code "costs" ~€10 each (server + support amortised), that's 2,500-5,000 free licenses per year — enough for a meaningful distribution across tier A partners.

10.3 Breakeven

With ~90% of users on IAP and ~10% on codes, the blended gross revenue per user is ~€65-70/yr. Fund costs amount to a small percentage that can be absorbed as marketing/brand investment.

---

11. Implementation roadmap

Phase 1 (launch)

• App: IAP integration (Apple + Google) with appAccountToken / obfuscatedAccountId
• App: in-app code redemption flow (separate from IAP signup)
• App: account-number + passphrase login for anonymous users
• Backend: receipt verification service (Apple + Google)
• Backend: code mint/redeem/revoke endpoints
• Backend: entitlement service (reads: app, writes: IAP webhook + code redeem)
• Backend: auth_db, payment_db, entitlement_db, code_db — separated as specified
• Operations: CLI script for generating partner batches (no web portal yet)
• Partners: 3-5 clinics in Berlin, Hamburg, Leipzig + regional midwives
• Fund partners: 2-3 launch NGOs in Germany (Hilfetelefon, Pro Familia, bff)
• Website: /avelia-fund page with partner list + how to request codes
• Website: Safe Mode page links to Avelia Fund
• Legal: partner MOU template
• Legal: updated privacy policy explaining the payment model
• Legal: tax treatment of Fund codes (consult accountant)

Phase 2 (3-6 months after launch)

• Partner portal at partners.avelia-health.com: full-featured web dashboard
• Gift code web flow at avelia-health.com/gift (Stripe)
• Expansion: onboard 10-15 more clinics, 5-10 more midwives, 3-5 more NGOs
• Partner automation: monthly batch generation, quota enforcement, auto-delivery
• Transparency report: first annual report published

Phase 3 (year 2+)

• External funding: apply for Mozilla / OSF / BMFSFJ grants
• Retail distribution: physical prepaid cards at pharmacies (dm, Rossmann)
• "Sponsor a license" checkout option
• International expansion: partners in UK, US, Australia, France, Italy, Spain, Netherlands

---

12. Open items

1. Tax treatment of Fund codes — need accountant guidance. Are they marketing expenses? Sponsorships (Sponsoring)? Charitable contributions (even from a GbR, which is not a recognized charity)? Resolution needed before Phase 1 close.
2. Partner agreement template — draft by legal advisor, reviewed by first 3 launch partners for feasibility.
3. Billing descriptor for the (few) web-based gift purchases — needs to be set in Stripe. Proposal: "AVELIA-DE" or "AVL-DE".
4. Code expiry notification — do we email partners when unredeemed codes are approaching expiry? Phase 1: no, manually checked. Phase 2: automated.
5. Monitoring — Matomo can't observe code redemption without leaking privacy. We need a separate, aggregated-only metric source (e.g., monthly code redemption counts) that has zero per-user data.
6. First CLI script — should generate codes, output CSV + PDF for printing, and encrypt delivery. Simple Node script or Python. Priority for Phase 1.
7. In-app "redeem code" screen wording — needs UX review. Must be clear that this is an alternative to email signup, not a "cheaper way to pay."
8. Fund quota defaults — each launch partner starts with N codes/month. N = 25-50 depending on partner size. Revisit quarterly.

---

13. Cross-references

• Product spec: avelia-product-spec.md §Payment & Identity Architecture
• Marketing: avelia-marketing-strategy.md §Avelia Fund
• Partner briefing: avelia-partner-briefing.md §Monetization strategy
• Roadmap: avelia-product-roadmap.md §Phase 1 + Phase 2
• Ops runbook: avelia-ops-runbook.md (to be updated with payment env vars)
• Privacy page (website): /[lang]/privacy/zero-knowledge, /[lang]/privacy/safe-mode
• New public page: /[lang]/avelia-fund