On-Ramp Use Case
Overview
This section maps the full flow for on-ramp to merchant: fiat - stablecoin - on-ramp - user - merchant - fiat.
Actors
| Actor | Role | Regulated? |
|---|---|---|
| User | End user who wants to convert fiat into encrypted stablecoins. Has an account at Merchant's app. | KYC'd by On-Ramp |
| EMI (Electronic Money Institution) | Licensed entity that issues e-money tokens (EMTs). Accepts fiat deposits, mints stablecoins on-chain, and redeems them back to fiat. Holds the reserve. | Yes — MiCA Title IV, PSD2 |
| Merchant | Business that accepts EB stablecoins as payment for goods/services. May also need to off-ramp back to fiat. | Depends on jurisdiction |
| Regulator | Supervisory authority (e.g., national competent authority under MiCA). Oversees the EMI's compliance, reserve adequacy, and transaction monitoring. | N/A — is the authority |
Key Requirements
- On-ramp must pay to user with a public transfer (visible on-chain amount) for compliance with VISA.
- User must transfer to merchant in a self-custodial manner (automated, but keys belong to the user, on their device).
- The link between on-ramp and merchant is severed — no on-chain trail connecting the user's top-up to the merchant's settlement.
Hard Constraints
- Private mints and burns must not change the publicly visible token supply. Minting into encrypted balance (EB) or burning from L3 commitments happens within a fixed public supply — tokens move between public and private representations, but the total public amount on-chain stays constant. If private operations altered the visible supply, it would break proof-of-reserves, explorer compatibility, and make every private mint/burn detectable by supply delta.
Sub-Flow Summary
| Phase | Sub-Flow | Interaction | What Happens | Completness |
|---|---|---|---|---|
| Supply | 1. EMI → On-Ramp | EMI ↔ On-Ramp | On-Ramp sends fiat to EMI; EMI mints public EMT tokens to On-Ramp's custodial address. | 1/5 |
| Delivery | 2. User → Merchant | User ↔ On-Ramp ↔ Merchant | User tops up on merchant site. Redirected to on-ramp for KYC + payment. Self-custody wallet created client-side, redirect to merchant registered on-chain. Tokens auto-forward to merchant's stealth address as encrypted balance. | 2/5 |
| Settlement | 3. Merchant → Fiat | Merchant ↔ EMI | Merchant commits stealth address balances to L3, burns them. EMI verifies burn proof, sends fiat. On-chain trail between customer payments and settlement is severed. | 1/5 |
| Oversight | Compliance — Anonymity Revoking, AML Enforcement | EMI ↔ Regulator | Routine reporting, UKRC threshold decryption for legal orders, enforcement actions (blacklist / freeze). No single party can access amounts unilaterally. | 1/5 |
Overarching Questions
- What can be private? Can EMI mint/redeem be private? Can the On-Ramp's balance be private?
- On-ramp will work as before for the time beeing - swapping only Kraken to EMI
- Do we burn public tokens when moving from public to EB/L3?
- If yes - explorers compatibility, proof of reserves get complicated, and potentialy upgrade paths get complicated.
- If not, how does commitment-based burn function? Will Burn have to be public? Aka someone withdrew 1M$ today in one action.
Questions to Specific Sub-Flows
- [Supply] KYC pass-through — Can the Merchant pass or prove the user's KYC to the On-Ramp to skip a redundant KYC step?
- [Oversight] Wallet-level compliance — What does the EMI need to know about each wallet? Is KYB at mint/redeem and KYC at on-ramp enough? Or do we need some on-chain KYC proof attached to every transaction?
- KYC/KYB Mostly at EMI