From 2cac4d512acc642a0ac8a3a535e520da5f101dc8 Mon Sep 17 00:00:00 2001 From: walerikus <35748353+walerikus@users.noreply.github.com> Date: Sat, 20 Jun 2026 22:16:01 +0200 Subject: [PATCH] design: fiat on/off-ramp product definition (catalogue + escrow + two counterparty classes) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds Parameters/DEX_P2P/fiat-ramp-product.md — the product layer over the settlement engine in p2p-fiat-crypto-exchange.md: - Non-custodial infrastructure: catalogue + escrow + oracle + reputation; platform holds nothing and converts nothing (light-touch posture). - Two counterparty classes on one backend: individuals (pure P2P, non-KYC, self-proved zkTLS) and specialized operators (licensed/vetted, automated, carry own compliance) — with class + jurisdiction disclosure. - Trade flows for each lane; regulatory posture (operators carry compliance; regulation follows operator AND customer; geo-controls + disclosure). - Positioning: "BestChange's network + reach, but escrow- and oracle-protected"; micro-swap wedge; Telegram + web distribution. - Scope: fiat↔crypto only; crypto↔crypto is the separate multichain DEX. Co-Authored-By: Claude Opus 4.8 --- Parameters/DEX_P2P/fiat-ramp-product.md | 136 ++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 Parameters/DEX_P2P/fiat-ramp-product.md diff --git a/Parameters/DEX_P2P/fiat-ramp-product.md b/Parameters/DEX_P2P/fiat-ramp-product.md new file mode 100644 index 0000000..aa948fa --- /dev/null +++ b/Parameters/DEX_P2P/fiat-ramp-product.md @@ -0,0 +1,136 @@ +# Fiat On/Off-Ramp — Product Definition + +A **non-custodial infrastructure** for moving value between bank-settled fiat and crypto, where the platform **never touches funds and never converts** — it provides a *catalogue, escrow, verification, and reputation* layer, and lets two kinds of counterparty do the actual fiat handling: **individuals (pure P2P)** and **specialized operators (licensed/vetted businesses)**, on one shared backend. + +This is the *product* layer. The settlement mechanics (escrow covenant, payment oracle, dispute resolution) are the engine in `p2p-fiat-crypto-exchange.md`. The crypto↔crypto multichain DEX is a **separate product** (`cross-chain-htlc-ramp.md` + `bch-dex-development.md`) and is out of scope here. + +--- + +## 1. What it is — and what it deliberately is not + +| It **is** | It is **not** | +|---|---| +| a **catalogue** of fiat↔crypto counterparties (discovery) | a money transmitter / converter | +| a **non-custodial escrow** for each trade (covenant holds, not the platform) | a custodian of fiat or crypto | +| a **verification + reputation** layer (oracle proves the fiat leg) | a party to any trade | +| **infrastructure** the counterparties plug into | the entity that "accepts payment and sells crypto" | + +The platform's regulatory posture follows from the right column: **it holds nothing and exchanges nothing**, so it is software/infrastructure (light-touch), not a regulated money-services business. The regulated activity — exchanging fiat for crypto — is done by the *counterparties*, who carry their own compliance (see §5). + +--- + +## 2. The core: two counterparty classes, one infrastructure + +The same escrow + oracle + catalogue backend serves both. The user picks; the platform **discloses the class** (like the asset-risk-category disclosure in `dex-architecture.md`). + +| | **Individual (pure P2P)** | **Specialized operator** | +|---|---|---| +| Who | a peer with a bank account | a licensed/vetted exchanger, PSP, OTC desk | +| Fiat-leg proof | **self-generated zkTLS/zkEmail** (non-KYC) | own-rail attestation or open-banking (automated) | +| Automation | manual proof, click-to-prove | **full** — they have rail access and an incentive to automate | +| Liquidity | thin, occasional | **deep, professional** (solves cold-start) | +| Compliance | gray-zone, per the individual's jurisdiction | the operator's own license, per its jurisdiction | +| End-user KYC | none | per the operator's tier (e.g. Guardarian-style ≤€700 low-KYC) | +| Trust protection | escrow + reputation | escrow + license + reputation | + +**Why both:** the individual lane is the permissionless/non-KYC cypherpunk path (the AgoraDesk/BestChange long tail, but escrow-protected); the operator lane is the compliant, automated, liquid path (the BestChange "470+ operators" supply, the Guardarian low-KYC convenience) that makes the market actually function from day one. The escrow + oracle layer is identical for both — only the *counterparty class* and its *proof method* differ. + +--- + +## 3. Components + +1. **Catalogue / directory** — discovery: lists counterparties (both classes) with rates, limits, payment methods, reputation, and **class + jurisdiction disclosure**. This is `ADR-0036`'s on-ramp aggregator *evolved* from pure link-out into escrow-protected trade. Light-touch (an information service). +2. **Non-custodial escrow** — the trust layer BestChange lacks: a CashScript covenant holds the crypto leg; neither the counterparty nor the platform can run off with it. (`p2p-fiat-crypto-exchange.md` §4.) +3. **Payment oracle** — verifies the fiat leg as a `checkDataSig` attestation: **zkTLS/zkEmail** (individual, non-KYC, self-proved) or **open-banking / operator attestation** (operator, automated). (`p2p` §2–3.) +4. **Dispute / resolution** — sender-proof (decision 2b), finality-window = f(rail), terminating branches. (`p2p` §4 / §4a.) +5. **Reputation + disclosure + geo-controls** — per-counterparty reputation; class/jurisdiction badges; geo-restriction where a market's rules require it. + +The platform operates 1, 2, 3-verification, 4, 5. It never operates the fiat leg itself — that's the counterparty's. + +--- + +## 4. Trade flows + +**Individual P2P (non-KYC):** +``` +1. Buyer finds an individual seller in the catalogue (rate, method, reputation). +2. Seller's crypto locks in the escrow covenant. +3. Buyer sends fiat bank-to-bank; generates a zkTLS/zkEmail proof of the completed payment. +4. Oracle verifies the proof → checkDataSig attestation → covenant releases crypto to buyer. +5. Dispute path (p2p §4a) if proof is contested; finality window for reversible rails. +``` + +**Specialized operator (automated):** +``` +1. User picks an operator (often best rate / instant / their region). +2. Operator's crypto locks in escrow (or operator fronts on confirmation). +3. User pays the operator on the operator's licensed rails. +4. Operator's own systems see the payment (rail access) → attest → covenant releases. + (Independent open-banking oracle can verify in parallel for defense-in-depth.) +5. Faster + smoother (operator automates its side), with escrow still protecting the user. +``` + +Same escrow, same covenant, same dispute machinery — only the **proof source** differs (self-proved vs operator/rail-attested). + +--- + +## 5. Regulatory posture (who carries what) + +- **Platform** = non-custodial infrastructure → light-touch. Holds no funds, converts nothing, is not a party to trades. (Caveat: "facilitation/control" can still draw scrutiny in some regimes — a per-jurisdiction legal read is required before mainnet; this posture *reduces* exposure, it does not auto-zero it.) +- **Operators** carry their **own license** per their jurisdiction × their customers (regulation follows *both* operator location and customer location — extraterritorial). Serving EU/US customers pulls in MiCA/FinCEN regardless of where the operator is based. +- **Individuals** are in the gray zone per their own jurisdiction — light in practice where local, regulated when serving regulated-market customers. +- **Platform controls:** **class + jurisdiction disclosure** and **geo-restriction**, so a counterparty can't quietly serve a market it isn't allowed to. The chokepoint lives **with the counterparties, off the platform.** +- **Trend note:** FATF is pushing all ~200 jurisdictions toward VASP registration + travel rule; gray zones are shrinking. Treat the individual/gray lane as a launch wedge, not a permanent base. + +--- + +## 6. Positioning + +> **"BestChange's operator network and reach, but the trade settles through non-custodial escrow and an oracle — so you don't have to trust the counterparty."** + +- vs **BestChange** (664 operators, Telegram-distributed, **no escrow** — send-and-trust): you add the trustless escrow + verification it lacks. +- vs **Guardarian / MoonPay** (single licensed converter, custodial): you aggregate *many* counterparties, stay non-custodial, and the user keeps custody. +- vs **pure-P2P (AgoraDesk-style)**: you add automation (operators), liquidity (operators), and escrow — and you're durable/bankable rather than legal-gray-only. + +**Distribution:** Telegram Mini App + web over one API — the channel BestChange itself just validated. + +**Underserved wedge:** the **sub-minimum / micro-swap** segment ($1–20) that big operators' $50–100 minimums exclude — viable here because escrow + oracle have near-zero marginal cost and BCH fees are sub-cent. Requires cheap instant fiat rails (SEPA Instant, UPI, PIX, FedNow) on the counterparty side. + +--- + +## 7. Business model + +Platform earns from **listing / referral / a small escrow fee** — never from transmitting or converting. Revenue scales with trade volume; it never requires holding funds. (Fee-funded incentives must follow the anti-wash rule: rewards rebated from realized fees, capped below fee, denominated in the fee's unit — never a separately-valued token.) + +--- + +## 8. Relationship to the other docs & scope + +- **Settlement engine:** `p2p-fiat-crypto-exchange.md` (escrow covenant, oracle families, dispute resolution — the §4/§4a machinery this product runs on). +- **Catalogue seed:** `ADR-0036` on-ramp aggregator (evolve link-out → escrow-protected). +- **Out of scope (separate product):** crypto↔crypto is the **multichain DEX** (`cross-chain-htlc-ramp.md` + `bch-dex-development.md`) — no fiat oracle, no operators, no compliance chokepoint; self-evidencing on-chain. Build it independently. + +--- + +## 9. Open decisions / next steps + +1. **Oracle method per lane** — confirm zkTLS recipe coverage for the individual lane (which rails first), and the operator-attestation format for the operator lane. +2. **Counterparty onboarding & vetting** — how operators register, prove licensing/jurisdiction, and self-certify; how individuals build reputation from zero. +3. **Geo-control policy** — which counterparty×customer-jurisdiction pairs are allowed/blocked at launch (needs the per-market legal read). +4. **Reputation model** — generalize `src/onramp/reputation.ts`; per-device + plural-external signals; bonds for the individual lane (anti-grief). +5. **Per-rail finality-window table** (`p2p` §5 item 3) — instant/irreversible vs held-through-window vs excluded. +6. **Fee model** — listing vs referral vs escrow fee; the anti-wash rebate rule. + +--- + +## Appendix — vocabulary (plain ↔ ecosystem) + +| Plain | Costume | +|---|---| +| A directory of counterparties | aggregator / monitor | +| A counterparty that brings fiat + crypto | operator / liquidity provider / "solver" | +| Escrow with a release condition | covenant / HTLC | +| A witness that proves the fiat arrived | payment oracle (zkTLS / zkEmail / open-banking) | +| A peer trading from their own bank account | pure-P2P counterparty | + +(Full decoder in `dex-architecture.md`.)