Crypto (USDC) payouts ONLY for countries Stripe can't serve — non-US persons only, W-8BEN + OFAC compliance scoped first

## Scope — read this first

**Crypto payouts are ONLY for countries Stripe cannot serve. Nothing else.**

- If Stripe supports the provider's country (US, EU/EEA, UK, CA, CH today; AU/NZ/JP/HK/SG/… once recipient-agreement approval lands via #498), they use Stripe — **crypto is not offered to them, period**. Stripe's hosted onboarding makes the user complete all tax/KYC themselves (W-9/W-8, identity verification), so those obligations never land on us.
- **US persons are categorically excluded from the crypto rail.** US is Stripe-supported, and keeping US persons off crypto means we never touch 1099-NEC filing, TIN matching, or **24% backup withholding** — that entire compliance machine stays deleted by policy, not implemented.
- The crypto rail therefore serves exactly: **non-US persons in countries outside Stripe's coverage** (today: Taiwan, India, and the tail outside Stripe's recipient list — final list depends on the transfers-only approval outcome in #498).

Enforcement of the scope is part of the design: country gate (registry-driven payout-method matrix) + **W-8BEN certification of foreign status required before the first crypto payout**. Anyone who cannot certify non-US-person status (e.g. a US citizen living in Taiwan) is not eligible for crypto payouts — edge case explicitly closed, not handled.

## Problem

Even after #498 + Stripe's transfers-only approval, some provider countries have **no Stripe path at all**:

- Taiwan (asked for explicitly in #support), India (Stripe invite-only; user confirmed blocked), plus whatever remains outside Stripe's recipient-agreement country list.
- Multiple direct on-chain withdrawal requests in #support: *"Is it possible to withdraw to USDC on chain?"*, *"will there be a onchain withdraw system? My country is not in the list"*.
- We've publicly told users stablecoin payouts are on the roadmap.

Proposal: **USDC payouts** as the fallback rail, likely on Solana (deposit rails + treasury config already exist in `coordinator/billing`).

Prior art: wallet-based payouts existed and were removed in favor of Stripe-only (`cleanup_wallet_model_prices_v1` migration dropped `users.solana_wallet_address`; legacy `ProviderPayout` / `CreditProviderWallet` store methods remain). This is a revival — but last time the compliance half was skipped, and that's the actual blocker.

## Workstream A — Legal / tax / compliance (BLOCKER — must land before any code ships)

We are a US-based company (Eigen Labs, Inc.) paying foreign service providers. Because the scope above excludes US persons and Stripe-served countries, the counsel questions shrink to:

### Foreign-payee tax handling
- [ ] **W-8BEN** (individuals) / **W-8BEN-E** (entities) collection before first payout — substitute-form + e-signature requirements, 3-calendar-year validity/renewal tracking, secure retention. This is the certification that keeps US persons off the rail.
- [ ] Confirm our working position: compute performed on hardware physically outside the US by a non-US person is **foreign-source services income → no US withholding, no 1042-S**. Edge cases to put to counsel: our attestation/IP data can locate machines — what if a foreign person's machine is physically in the US? (Proposed answer: make US-located machines ineligible for crypto payouts too — same "close the edge, don't handle it" policy.)
- [ ] **FATCA/Chapter 4** relevance for these payments (expected: none for services, confirm).
- [ ] Paying in **USDC vs USD**: does crypto settlement change characterization or valuation? Document payment-date FMV position (USDC ≈ $1, still document). Confirm no **1099-DA** exposure (payor, not digital-asset broker).
- [ ] Confirm explicitly: with US persons excluded by W-8BEN certification + country gate, **no 1099-NEC / backup-withholding obligations attach to this rail** (this is the load-bearing assumption of the whole design — get it in writing).

### Sanctions / AML / licensing
- [ ] **OFAC**: country-level blocks (sanctioned jurisdictions never eligible) + **SDN/blocked-wallet screening** on every payout address at link time and payout time. Pick vendor (Chainalysis/TRM/Elliptic) or list-based approach.
- [ ] **KYC** depth required for foreign payees (Stripe did this for us on the other rail; who verifies identity here and to what tier).
- [ ] **FinCEN / money transmission**: written opinion that paying our own service providers for services is not money transmission (federal MSB + state MTL exposure).
- [ ] Anything chain-specific (USDC on Solana vs EVM) that changes the analysis.

### Company/process
- [ ] Update `docs/legal/privacy-policy.md` + `docs/threat-model.yaml` (new PII: W-8 data, wallet↔identity links; retention obligations).
- [ ] Payout ToS addendum for the crypto rail (finality, wrong-address risk, no reversals).

## Workstream B — Product / engineering (gated on A)

- **Eligibility gate (enforces the Scope section)**: payout-method matrix per country — Stripe-supported country → Stripe only, crypto never shown; unsupported country → crypto after W-8BEN. No user ever gets a choice between rails.
- **W-8BEN gate**: block first crypto withdrawal until the form is collected/validated; store data + certification timestamp/IP; renewal expiry blocks further payouts.
- **Wallet linking**: ownership proof (sign a nonce), sanctions screen at link + payout, address-change cooldown.
- **Payout execution**: USDC on Solana; idempotent on-chain sends keyed by withdrawal ID; min withdrawal + network-fee policy; explorer-link receipts.
- **Ledger integration**: same `DebitWithdrawable` flow and state machine as #498 (pending → sent → confirmed | failed+refund).
- ~~1099 reporting pipeline~~ — **out of scope by design** (no US persons on this rail).

## Acceptance criteria (investigation phase)

1. Written counsel guidance on Workstream A — above all: (a) foreign-source/no-withholding position, (b) confirmation that the US-person exclusion eliminates 1099/backup-withholding, (c) MTL opinion.
2. Decision doc: chain + token, screening vendor, W-8BEN collection flow, country eligibility matrix v1 (finalize after #498's Stripe approval outcome).
3. Follow-up implementation issues for Workstream B with compliance requirements baked in.

## References
- #498 (Stripe payout fixes; country-tier analysis in PR comments)
- #support threads: Taiwan bank request, India Stripe-unsupported, USDC withdrawal requests; #providers crypto-withdrawal question
- Legacy code: wallet-payout cleanup migration in `coordinator/store/postgres.go`, `ProviderPayout`/`CreditProviderWallet` store methods, Solana config in `coordinator/billing/config.go`

Start by reading #498 and the legacy wallet-payout references in coordinator/store/postgres.go and coordinator/billing/config.go, then review docs/legal/privacy-policy.md and docs/threat-model.yaml. Done means written counsel guidance, a decision document covering the chain, screening, W-8BEN flow, and country matrix, plus follow-up implementation issues for the engineering workstream.

Written by the indexing model from the issue text.