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):

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).