# PLENA Agreements & Contracts — Production Deployment Documentation

**Status:** Documentation for the operational steps required to move PLENA Agreements & Contracts from prototype (the current d19.248 build) to live commercial service. None of these steps can be completed by Claude Code or by automated tooling; all require PLENA GLOBAL LLC's legal, financial, and operational signature.

This document is the operational counterpart to [`whatsapp-integration-architecture.md`](./whatsapp-integration-architecture.md) (which covers the WhatsApp server-side handler in technical detail). Together they describe everything required to switch the prototype to production.

---

## 10.1 Required external accounts and integrations

### Payments and money movement

- [ ] **WhatsApp Business API provider account.** Recommended: Twilio for start (best documentation, easiest onboarding). Alternatives: 360dialog, Meta direct, MessageBird, Vonage.
- [ ] **Mobile-money merchant accounts.** Registered on an operator-by-operator basis as markets are activated, or aggregated through a payment processor. The relevant operators across the global informal-economy market include — but are not limited to — M-Pesa, MTN MoMo, Orange Money, Wave, Airtel Money, Tigo Pesa, and additional regional operators. Indirect path: a single **Flutterwave**, **Cellulant**, or **DPO Group** merchant account can aggregate access to several of these in one contract; this is the recommended operational starter so a market can be activated without negotiating individual operator agreements first.
- [ ] **Arweave wallet** and operating-capital funding. Recommend starting with approximately $100 worth of AR (or paying via Bundlr / Irys in MATIC). Sufficient for ~200 attestations at full 720p.
- [ ] **USDC receiving wallets** on Base, Polygon, Solana — with auto-conversion to USD via Coinbase Commerce or equivalent.
- [ ] **Bitcoin Lightning provider** — OpenNode recommended for start, or Strike, or self-hosted BTCPay Server.
- [ ] **Stripe account** for card processing. Enable Stripe Connect for multi-currency settlement to PLENA GLOBAL LLC's bank account.
- [ ] **Flutterwave account** as the global card processor alternative for users on issuers Stripe does not serve well.

### Hosting and operational infrastructure

- [ ] **Server hosting** — Render or Railway recommended for the starter deployment (zero-config, free tier sufficient at < 100 attestations/day). Move to Hetzner or AWS once volume justifies fixed-server pricing.
- [ ] **Managed Postgres** for the verification-code registry — Render Postgres, Supabase, or Neon all work.
- [ ] **Domain and DNS** — already in place at `joinplena.com`. WhatsApp media webhook needs a stable HTTPS endpoint; the provider gives it a sub-path on the existing domain.
- [ ] **Backup / IPFS pinning** — Pinata or web3.storage for the redundant IPFS upload (Phase 10.3 mitigation against Arweave-network risk).

### Legal and compliance

- [ ] **PLENA GLOBAL LLC** corporate documentation for each merchant-account application (already in hand — entity is "PLENA GLOBAL LLC", USPTO Class 35 registration in progress).
- [ ] **Local representative** for any country requiring a domestic legal representative for the WhatsApp Business account or the mobile-money merchant agreement (many jurisdictions require this).
- [ ] **Privacy / Terms updates** — the existing `/privacy.html` and `/terms.html` need a brief append covering the WhatsApp video-attestation product, the Arweave-storage permanence, and the verification-code retrieval policy.

---

## 10.2 Cost projections

### Operating cost at three volume tiers

| Monthly volume | WhatsApp API | Arweave (720p, 5 min avg) | Server/DB | Payment fees | **Total/month** |
|---|---|---|---|---|---|
| **100 attestations** | $5–$25 | $50–$100 | $0 (free tier) | $5–$15 | **approximately $50–$100** |
| **1,000 attestations** | $50–$250 | $500–$1,000 | $25–$50 | $50–$150 | **approximately $300–$600** |
| **10,000 attestations** | $300–$1,500 | $1,000–$2,500 *(volume bundling discount)* | $100–$300 | $300–$1,000 | **approximately $2,000–$4,000** |

### Revenue projections (assuming Basic-tier mix dominant — approximately 85% Basic, 13% Premium, 2% Institutional)

| Monthly volume | Basic revenue | Premium revenue | Institutional | **Total/month** | **Annual run-rate** |
|---|---|---|---|---|---|
| **100 attestations** | $255 | $39 | (excluded from estimate) | **~$300** | **$3,600/yr** |
| **1,000 attestations** | $2,550 | $390 | bespoke | **~$3,000** | **$36,000/yr** |
| **10,000 attestations** | $25,500 | $3,900 | bespoke | **~$30,000** | **$360,000/yr** |

### Unit economics

At the 10,000/month tier:
- Gross margin: estimated **70–85%** after payment processing fees, mobile-money operator fees, Arweave storage, and WhatsApp API costs.
- Institutional tier adds approximately $5,000–$50,000/month per institutional contract on top of the per-unit volume, at 90%+ margin (mostly API-call overhead, not per-unit Arweave or WhatsApp costs).

### Operating-capital implications

Operating capital from this product is intended to support the mission-aligned sector pages. The Institutional tier in particular is the high-margin component: a small number of notary firms, microfinance institutions, real estate companies, agricultural cooperatives, or NGO networks integrating via API substantially shifts the unit economics.

---

## 10.3 Risk register

Known operational and product-fit risks, with planned mitigations.

| Risk | Mitigation |
|---|---|
| **WhatsApp account suspension** — automated abuse-detection or template-policy violations can suspend a WhatsApp Business account, taking the primary rail offline. | Multiple verified WhatsApp Business accounts (one per country of operation); a `whatsapp-fallback@joinplena.com` operational mailbox monitored for suspension notices; the browser app at `/agreements-and-contracts-app` operates as a fully-functional secondary capture path so service continues during a suspension. |
| **Mobile-money operator policy changes** — operators can change merchant terms, fees, or KYC requirements with limited notice. | Maintain relationships with **multiple operators** in each country, or route through an aggregator (Flutterwave, Cellulant, DPO Group) that gives flexibility to switch underlying rails without reconfiguring the customer-facing flow. |
| **Arweave network changes** — Arweave's economic model assumes a multi-century endowment funding permanent storage; if assumptions change, retrievability is at risk. | Parallel upload to **IPFS** via Pinata or web3.storage as a redundant fallback. Bitcoin-anchored hash means the receipt is independently verifiable even if both storage layers fail — the parties still hold the original video on their phones. |
| **Bitcoin transaction-fee spikes** affecting Lightning payments | Lightning is a **secondary rail**; mobile money is primary in the launch markets and card payments are primary where mobile money is less prevalent. USDC and card payments are unaffected by Bitcoin fee spikes. PLENA absorbs short-term fee spikes via the operating-capital buffer rather than re-pricing the customer. |
| **Currency collapse in a target market** — some launch markets experience significant local-currency depreciation. | **USD-nominal pricing** throughout (the customer sees the local-currency equivalent at the moment of payment but the contract price is USD). PLENA converts mobile-money receipts to USD operating capital frequently — at minimum daily, ideally same-day via Wise or a local FX partner. |
| **Regulatory action against crypto payments** in a target country | **Mobile money remains primary** where it is established; crypto is secondary. If a country bans USDC or Lightning at the consumer level, the product remains operational on mobile money and card. Crypto rails are also used internally for PLENA-side settlement rather than customer-facing, where regulation is less restrictive in most jurisdictions. |
| **Liability exposure for content of attested videos** — a video might contain content (a contract for an illegal transaction, a defamatory statement, an unauthorized recording) that creates legal exposure for PLENA. | **Clear disclaimer** on every customer-facing surface that PLENA does not verify content. **Terms of Service** require the user to warrant they have consent of all parties on camera to be recorded. **Takedown policy** for content reported as unauthorized, with the takedown removing PLENA's surface-level retrieval but not invalidating the Bitcoin anchor or the OpenTimestamps proof. **Refusal log** (consistent with PLENA's existing refusal-receipts pattern) documents cases where PLENA declined to serve. |
| **Partner-institution turnover** — institutional distribution depends on individual people inside the partner organizations; staff transitions can disrupt referral flow. | Build PLENA-relationship continuity at the organizational rather than individual level (signed institutional MOUs not just individual relationships); cultivate at least two named contacts per partner institution; document partner-specific operational notes in PLENA's internal CRM. |
| **Reviewer-quality risk** for the human-reviewer queue — some languages have limited translator pools. | Machine translation is the floor on every language; contracted reviewer sign-off elevates a language as the reviewer comes online. The translation-roadmap page is the public surface for this. Founder-supplied authoritative glossaries override machine translation for specific terms where they exist (see auto-memory). |
| **Trust risk** — the product asks users to send sensitive contract videos to a US-domiciled LLC over WhatsApp. | Distribution through trusted local intermediaries (cooperative officers, microfinance loan officers, NGO networks, religious-institution networks) in the initial launch phase of any market; PLENA does not market direct-to-consumer in the early phase of a market. Once trust is established with the intermediary, the user is comfortable that the receipt PLENA produces is a real receipt and not a scam. |

---

## 10.4 Out-of-scope for this build

The following are explicitly out of scope for the d19.248 prototype and need separate tasks once production accounts are live:

- The actual WhatsApp server-side handler (Node/Python/Go). [`whatsapp-integration-architecture.md`](./whatsapp-integration-architecture.md) describes what it must do; building it is a subsequent task.
- The verification-code registry database schema and the production retrieval endpoint.
- The Premium-tier multi-witness coordination workflow (the WhatsApp flow that prompts witnesses to record corroborating statements within 48 hours).
- The Institutional-tier API and dashboard.
- The IPFS redundant-storage path (deferred to Phase 2 of post-launch hardening).
- The Premium-tier handover-packet generator (PDF assembly tailored to named jurisdictions).
- Live payment-rail integration beyond Stripe test mode (all rails are UI stubs in the prototype).

---

*Document version: d19.248. Last updated 2026-05-27. PLENA GLOBAL LLC. Contact: hello@joinplena.com.*