design: fiat on/off-ramp product definition (catalogue + escrow + two counterparty classes)
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 <noreply@anthropic.com>
This commit is contained in:
walerikus
parent
9b9c2b9dca
commit
2cac4d512a
1 changed files with 136 additions and 0 deletions
136
Parameters/DEX_P2P/fiat-ramp-product.md
Normal file
136
Parameters/DEX_P2P/fiat-ramp-product.md
Normal file
|
|
@ -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`.)
|
||||
Loading…
Add table
Reference in a new issue