# V1 Crypto Regulatory Review — No-KYC, Non-Custodial, Crypto-Primary Billing

Status: compliance planning baseline, created 2026-06-12 to close
`V1_V7_PLAN_SET_AUDIT_2026-06-12.md` §6.2 (V1: "no regulatory analysis for
no-KYC crypto payments incl. Monero across jurisdictions"). This is internal
planning by non-lawyers structuring the questions and a defensible default
posture; **every region gate in §7 requires an outside-counsel memo before it
opens** — that requirement is the control, not this document.

## 1. The design being assessed

Per `V1/features.md:5421-5427`: payment acceptance **without custody, without
KYC at the payment layer, without a centralized processor**. Self-hosted full
nodes, watch-only/view-only wallets on the app server, air-gapped 2-of-3
multisig signing for refunds and sweeps (`V1/DEPENDENCIES.md:433`). Rails:
BTC (on-chain + Lightning), LTC, **XMR**, ETH L1 + L2s, ADA, ERG, SOL, TRX
(USDT-TRC20), TON, plus USDC/USDT/DAI per the accept-list
(`V1/DEPENDENCIES.md:392-427`). Trust tiers A/B/C disclosed on every invoice
(`V1/features.md:5458-5481`). Fiat (Stripe-class) is V1.x optional.

**The load-bearing legal characterization:** Oshun accepts crypto **as a
merchant, for its own services, into wallets it controls non-custodially**. It
never transmits value *for others*, never exchanges *for others*, never
custodies *customer* assets. Essentially every licensing regime below regulates
doing these things *for third parties*. The recurring risk is
**re-characterization** — features that drift toward third-party service
(e.g., holding refundable balances as a stored-value account, operating a
swap, paying out to third parties) would change the answer. Product rule:
**any feature that moves value to anyone other than Oshun or back to the
original payer goes through Counsel review before build.**

Launch-locale regions in scope (`V1/features.md:2679-2680`: en-US, es-US,
fr-FR, de-DE, ar, he, ja-JP, pt-BR) plus the UK as a significant
English-language market.

## 2. Money-transmitter / VASP analysis per market

### 2.1 United States (en-US, es-US)

- **Federal (FinCEN):** under FIN-2019-G001 and 31 CFR 1010.100(ff), a person
  that accepts CVC as payment for its **own** goods/services is a **user**,
  not a money transmitter; the "integral to the sale of goods/services"
  exemption (1010.100(ff)(5)(ii)(F)) covers acceptance flows. Refund of a
  customer's own payment and sweeping/selling Oshun's own crypto are
  own-account activity. **Posture: no MSB registration required** for the V1
  design. Counsel memo must confirm: refunds, Lightning hold-invoices for
  refundable flows, and AMP/keysend metered streaming
  (`V1/DEPENDENCIES.md:407`) all stay inside the user/merchant
  characterization.
- **State money-transmitter laws:** most follow the same "for others"
  perimeter; **NY BitLicense (23 NYCRR 200)** explicitly excludes merchants
  receiving virtual currency solely as payment for goods/services
  (§200.3(c)(2)). Counsel deliverable: a 50-state + DC survey memo flagging
  any outlier states; contingency is geo-gating crypto checkout per state, not
  licensure.
- **Tax/reporting:** crypto received is ordinary income at fair-market value
  at receipt (the invoice-time locked rate, `V1/features.md:5406-5407`, is the
  bookkeeping anchor). IRC §6050I's digital-asset extension (IIJA) is enacted
  but Treasury has stated it is not effective pending regulations — Counsel
  tracks; if it activates, receiving > $10k in digital assets in one
  transaction would require collecting payer identity, which **breaks the
  no-KYC design above that threshold**. Mitigation already compatible with
  design: per-invoice cap of $9,500 on any single crypto invoice (planning
  assumption adopted 2026-06-12; under the 6050I threshold with margin —
  larger institutional contracts settle via tenant-scoped invoicing on fiat
  rails, `V1/features.md:5399-5400`).
- **Sales tax:** unaffected by settlement rail; locale/tax-aware billing is
  already spec'd (`V1/features.md:5404-5407`).

### 2.2 European Union — MiCA (fr-FR, de-DE; EU-wide)

- **MiCA (Reg. 2023/1114):** CASP authorization attaches to providing
  crypto-asset *services for third parties* (custody, exchange, transfer,
  etc.). Merchant self-acceptance is **not** a listed crypto-asset service.
  **Posture: not a CASP.** German note: BaFin's crypto-custody perimeter
  (now subsumed by MiCA transition) likewise targets custody *for others*.
- **AMLR (Reg. 2024/1624) / AMLD6 package:** obliged-entity status covers
  CASPs and (for cash) goods traders above thresholds — a digital-services
  merchant accepting crypto directly is not an obliged entity under the
  current text. The 2027 privacy-coin restrictions bind **CASPs** (no
  anonymity-enhancing coins, no anonymous accounts), not merchants — but the
  practical consequence is §3's off-ramp problem: by 2027-07 no EU CASP can
  accept Oshun's swept XMR.
- **TFR / travel rule (Reg. 2023/1113):** binds CASPs. When Oshun sweeps to an
  EU exchange, the exchange must verify self-hosted-wallet ownership for
  transfers > €1k — operational requirement on the **sweep** path (signed
  ownership proof from the sweep wallet), not on customer acceptance.
- **VAT:** unchanged by rail; OSS registration for B2C digital services across
  member states is a gate item (§7).
- **Consumer protection:** see §5 (UCPD adequacy of tier disclosures;
  14-day withdrawal right for digital services and its waiver-on-delivery
  consent must appear in checkout copy).

### 2.3 United Kingdom

- **MLRs 2017 cryptoasset registration** (FCA) covers exchange and custodian
  wallet providers acting *by way of business for others* — merchant
  self-acceptance is out of perimeter. **Posture: no registration.**
- **Financial promotions regime (FSMA s21 + 2023 Order):** promotions of
  "qualifying cryptoassets" to UK consumers require an authorized
  communicator. Accepting payment is not promoting an investment, but
  marketing copy matters: "pay with crypto and save 10 %" could be argued to
  *invite engagement in crypto-asset activity*. **Control:** UK-facing
  payment copy is neutral ("we accept BTC/XMR/…"), never incentivizes
  acquiring crypto; copy reviewed by Counsel pre-GA.
- **FCA 2026 cryptoasset authorization regime (in progress):** perimeter is
  again third-party services; tracked by Counsel.

### 2.4 Japan (ja-JP)

- **Payment Services Act:** "crypto-asset exchange service" registration
  covers sale/purchase/exchange/intermediation/custody *for others* — merchant
  acceptance is not registrable. **Posture: no registration.**
- **Privacy coins:** JVCEA self-regulation means no registered Japanese
  exchange handles XMR; banks treat XMR-linked flows as high-risk. Merchant
  acceptance is not per-se illegal, but there is no domestic off-ramp and
  high de-banking risk. **Decision: XMR rail disabled for Japan-resident
  billing at launch** (§4 matrix) via per-region rail gating (the per-tenant
  rail opt-out mechanism, `V1/features.md:5453-5456`, extended with a
  region dimension — a small, real config surface the payments-bridge must
  expose).
- **Consumption tax (JCT):** due on the service sale regardless of rail;
  registered foreign supplier obligations for B2C digital services are a gate
  item.

### 2.5 Brazil (pt-BR)

- **Lei 14.478/2022 + BCB regulations (Res. 519/520/521, effective 2026):**
  VASP authorization covers intermediation/custody/exchange for third
  parties. Merchant self-acceptance out of perimeter. **Posture: no
  authorization**; FX rules engage only when converting via Brazilian
  institutions — sweeps route through non-BR venues by default.

### 2.6 Israel (he)

- **Supervision of Financial Services Law (5776-2016):** "financial asset
  service provider" licensing again targets services for others. Merchant
  acceptance out of perimeter, **but** Israeli AML practice treats privacy
  coins harshly and banks aggressively refuse crypto-derived fiat without a
  documented source-of-funds trail. **Decision: XMR off for Israel-resident
  billing at launch; transparent chains + stablecoins on.** Off-ramp for
  IL-attributable revenue runs through non-IL venues until a banking
  relationship is verified (§7 gate item).

### 2.7 Arabic-locale markets (ar)

- **UAE:** Dubai VARA / federal SCA regimes license VA *activities for
  others*; merchant acceptance is generally permissible for a foreign online
  service. VARA prohibits anonymity-enhanced cryptocurrencies for licensed
  VASPs — same off-ramp logic as EU/JP. **Decision: XMR off for UAE-resident
  billing at launch.**
- **Saudi Arabia:** SAMA maintains a restrictive stance; banks are barred from
  crypto dealings and there is no licensing path that blesses consumer crypto
  payments. **Decision: crypto checkout not offered to KSA-resident billing
  at launch (region NO-GO, §7)** — the ar locale ships, payment for
  KSA-billing-address users is deferred to the V1.x fiat rail or prepaid/gift
  codes (`V1/features.md:5399`).
- Other ar-locale markets (e.g., Egypt — crypto dealings restricted by CBE
  rules) default to NO-GO until individually cleared.

## 3. The Monero / privacy-coin problem

Monero is the catalog's strongest privacy rail and a deliberate design choice
(`V1/features.md:5497-5509`). The constraint is almost never "merchant
acceptance is illegal"; it is **(a)** exchanges in many jurisdictions cannot
list/handle it (JP practice, KR, AU exchange delistings, UAE VARA prohibition,
EU CASPs by 2027-07) so **swept XMR has a shrinking compliant off-ramp**, and
**(b)** address-based sanctions screening is impossible on-chain (§4).

**Strategy:**

1. **Per-region rail matrix at launch** (billing-address/residency context
   drives it, consistent with the residency plumbing in
   `V1/ARCHITECTURE.md:1225-1231`):

   | Region | XMR | Transparent chains + stablecoins | Notes |
   | ------ | --- | -------------------------------- | ----- |
   | US | ON | ON | counsel memo + §4 compensating controls |
   | EU | ON | ON | re-review before AMLR CASP rules bite off-ramps (2027-07) |
   | UK | ON | ON | promo-copy control (§2.3) |
   | Japan | **OFF** | ON | §2.4 |
   | Brazil | ON | ON | |
   | Israel | **OFF** | ON | §2.6 |
   | UAE | **OFF** | ON | §2.7 |
   | Saudi Arabia | OFF | **OFF** | crypto checkout NO-GO at launch |

2. **XMR invoice cap:** $1,000 fiat-equivalent per invoice (planning
   assumption adopted 2026-06-12; keeps unscreenable exposure per transaction
   an order of magnitude below the US 6050I trigger and within retail
   subscription norms).
3. **Treasury policy:** swept XMR is either (a) held, (b) off-ramped only via
   venues that lawfully handle XMR in their jurisdiction, or (c) swapped
   on-platform-treasury-side to BTC before off-ramp — documented per sweep in
   the cold-spend queue audit (`V1/DEPENDENCIES.md:437`).
4. **Standing re-review:** the privacy-coin matrix is re-confirmed by Counsel
   quarterly; a forced change only requires flipping region-rail config (24-h
   SLA, RISK_REGISTER R-05).

## 4. Sanctions screening compatible with the non-custodial design

OFAC (and UK OFSI / EU equivalents) apply to Oshun regardless of payment-layer
KYC. The design has no customer identity, so screening is **address-, flow-,
and geography-based**, at three choke points:

1. **Invoice issuance (pre-payment):** no invoices to embargoed-jurisdiction
   users — geo/IP + billing residency block for Iran, North Korea, Cuba,
   Syria, Crimea/DNR/LNR (list maintained by Counsel). This is the only
   pre-payment control that needs no identity.
2. **Payment confirmation (transparent chains):** before an entitlement grant,
   screen the paying address(es) and one hop of direct exposure against the
   **OFAC SDN digital-asset address list** (machine-readable, free) plus a
   commercial screening provider. Provider options, in preference order:
   **Chainalysis** (free sanctions-screening API + on-chain oracle covers the
   SDN use case at zero cost), **TRM Labs**, **Elliptic** (both add
   risk-category scoring if we later want exposure heuristics). Planning
   choice adopted 2026-06-12: Chainalysis free sanctions API at launch —
   covers the legal requirement; upgrade decision deferred to observed hit
   rates. **Hit handling:** entitlement is *not* granted; funds are **blocked
   property** — they must be frozen (not refunded — returning value to an SDN
   is itself prohibited), reported to OFAC within 10 business days, and held
   in a segregated blocked-asset wallet; customer-facing invoice shows a
   neutral failure with a support path. This procedure is a payments-bridge
   runbook deliverable.
3. **Sweep time:** re-screen all inputs being consolidated before they touch
   an exchange; quarantine any address that became listed between
   confirmation and sweep.

**Monero:** on-chain screening is impossible by design. Compensating controls:
geo-gating (control 1), the §3 invoice cap, velocity monitoring per
subaddress-hash (the spec already stores only hashes,
`V1/features.md:5507-5509`), and a **documented, counsel-signed risk
acceptance** — this is the honest posture; pretending XMR is screened would
be a fabricated control.

**Lightning:** screen the funding/settlement on-chain footprint at channel
level; BOLT11 payments themselves carry no payer address — same compensating
controls as XMR apply to amounts (cap parity).

## 5. Trust-tier disclosure adequacy (consumer-protection view)

The spec already discloses per-rail decentralization tier and issuer freeze
authority on every invoice (`V1/features.md:5458-5481`,
`V1/DEPENDENCIES.md:436`) and records customer acceptance of freeze risk on
the invoice consent record (`V1/features.md:5480-5481`). Assessment against
FTC Act §5 / EU UCPD / UK CPRs: **adequate in direction, three additions
required**:

1. **Rate-lock + slippage disclosure** is spec'd (`V1/features.md:5406-5407`)
   — add the *expiry behavior* (what happens to an underpaid/late payment:
   top-up flow vs refund-minus-fees) in the same surface.
2. **No-recourse clarity for XMR:** refunds require a customer-supplied
   address (`V1/features.md:5401-5403`); the invoice must say this *before*
   payment, not in the receipt.
3. **EU withdrawal right:** 14-day digital-services withdrawal and its
   waiver-on-immediate-delivery consent checkbox in EU checkout copy.

Localized disclosure copy across all 8 launch locales is a §7 gate item
(consistent with locale-parity requirements, `V1/features.md:2679-2683`).

## 6. Re-characterization tripwires (engineering-facing)

Build-time review triggers — any of these goes to Counsel before merge:

- Holding customer value as a balance/credit redeemable later (stored value).
- Any swap/exchange surface exposed to customers (`@aje/payments` contains
  swap/aggregation code — **must stay treasury-internal**).
- Payouts to anyone other than Oshun or the original payer (e.g., creator
  revenue share in crypto — that is a V2+ feature with its own review).
- Tenant-provided payment processors (`V1/DEPENDENCIES.md:450`) settling
  through Oshun-controlled wallets.
- Escrow/milestone flows (`@aje/settlement-escrow`,
  `V1/DEPENDENCIES.md:379`) used for anything beyond Oshun's own refundable
  invoices.

## 7. Per-region go/no-go gate

A region's crypto checkout opens only when **all six** items are signed off;
the gate decision is recorded in the launch-readiness review
(LAUNCH_TIMELINE), decision owner **General Counsel**, with Payments Lead
co-sign:

1. **Counsel memo** confirming the non-MSB/non-CASP/non-VASP characterization
   for that region against the shipped feature set (incl. refunds, Lightning
   hold-invoices, metered streaming).
2. **Sanctions controls live and tested** (§4 controls 1–3, incl. the
   blocked-property runbook drill with a fixture SDN address on testnet —
   the test substrate already exists, `V1/DEPENDENCIES.md:435`).
3. **Region rail-gating config applied** per the §3 matrix and verified by an
   automated test (request with region X residency must not be offered
   disabled rails).
4. **Tax posture implemented**: VAT/GST/JCT registration or documented
   non-obligation; invoice formatting per locale
   (`V1/features.md:5404-5407`).
5. **Off-ramp verified**: at least one exchange/banking path accepts swept
   funds attributable to that region's revenue (test sweep executed).
6. **Disclosure copy localized + reviewed** (§5 items 1–3).

**Gate status at document creation (2026-06-12, all pending counsel memos):**

| Region | Expected outcome | Blocking items |
| ------ | ---------------- | -------------- |
| US | GO | 50-state memo; 6050I watch item |
| EU (DE/FR first) | GO | OSS VAT registration; withdrawal-right copy |
| UK | GO | fin-prom copy review |
| Japan | GO (XMR off) | JCT registration |
| Brazil | GO | BCB-regime memo refresh against 2026 resolutions |
| Israel | CONDITIONAL (XMR off) | off-ramp/banking verification |
| UAE | CONDITIONAL (XMR off) | mainland-vs-Dubai counsel memo |
| Saudi Arabia | NO-GO for crypto checkout | fiat/prepaid alternative only |

## 8. Ownership and cadence

- **General Counsel**: region memos, privacy-coin matrix quarterly re-review,
  sanctions-list governance, §6 tripwire reviews.
- **Payments Lead**: screening integration, blocked-property runbook, sweep
  policy, region-rail config and its tests.
- **Finance Lead**: tax registrations, FMV-at-receipt bookkeeping.
- Register linkage: RISK_REGISTER R-05 (regulatory action), R-10 (issuer
  freeze), R-11 (app-store policy), R-12/R-13 (signing/nodes).