1. EMI ↔ On-Ramp
How the On-Ramp acquires stablecoin tokens from the EMI.
Actors
| Actor | Role |
|---|---|
| On-Ramp | Licensed on-ramp service. Holds a custodial EVM address. Distributes tokens to end users. |
| EMI Backend | Electronic Money Institution. Mints/burns EMT tokens against fiat reserves. |
Flow
ZKP/EB Components and Features Used
| Component / Feature | Used? | How |
|---|---|---|
| EBEMT Contract | Yes | EMI mints public EMT tokens via mint(address, amount) |
| Encrypted Balance (EB) | Not in current flow, but Possible | Depends how On-Ramp handles privacy |
| L3 Commitments | Not in current flow, but Possible | Depends how On-Ramp handles privacy |
| Stealth Addresses | Not in current flow, but Possible | Depends how On-Ramp handles privacy |
| Custodial private wallet | Not in current flow, but Possible | Depends how On-Ramp handles privacy |
Requirements
Adding here only confirmed requirements.
Assumptions
| # | Assumption | Impact if Wrong |
|---|---|---|
| A1 | On-Ramp holds tokens as public ERC-20 (no EB) | Redesign to account for privacy-enabled On-Ramp Backend |
| A2 | EMI operates backend allowing for automated minting | Alternative flow with human controls necessary |
Open Questions
Privacy
The current flow is fully transparent — public ERC-20 minting to a known custodial address. This means:
- On-chain observers can see the On-Ramp's total minted volume
- On-chain observers can track distribution from custodial address to end users
- On-Ramp's business metrics (volume, timing, customer count) are inferrable
| # | Question | Context | Answer |
|---|---|---|---|
| Q1 | Can the EMI mint tokens directly to an EB address (encrypted balance)? | Would hide minting amounts from on-chain observers. EMI still knows amounts (they mint). On-Ramp holds encrypted balance instead of public. | Yes |
| Q2 | From a Visa/card-network compliance perspective: can the On-Ramp hold encrypted balance and send a private→public transfer to the customer? | On-Ramp's EB → unshield to customer address. Customer gets public tokens. On-Ramp's balance is hidden. | Not really |
| Q3 | With EB-only approach: would the On-Ramp use multiple stealth addresses as escrow to obscure business metrics? | Each customer order uses a fresh stealth address. Prevents volume/timing analysis. L3 would be simpler for this. | They can use private mint, but token inventory needs to be public for visa |
| Q4 | Can the EMI mint via L3 commitment directly? Does MiCA allow minting tokens privately? | 1:1 reserve is provable on-chain via total supply. But individual mint events would be hidden. Regulator comfort needed. | Yes |
| Q5 | Does each requested mint have to be executed immediately, or can mints be batched? | Batching would allow EMI to mint, encrypt, and only then send to receivers. | Mints be private |
Proposed Approaches
- Simple (recommended) — EMI always mints to public, receiver is responsible for shielding into L3/EB
- Simpler, consistent EMI design
- Receiver can use stealth address and go straight to L3
- Could be hidden from customer with an automated transfer step
- EMI mints in batches, encrypts to EB address before sending
- Still needs to mint N tokens publicly (assuming total supply is recorded on-chain)
- Transaction graph still visible
- Requires batching - delay and additional steps in minting, not sure if possible based on EMI requiremants
- EMI mints into L3
- Puts responsibility on EMI to know where user wants to receive funds
- More complex design
- Mint value still visible (assuming total supply is recorded on-chain)
Operational
| # | Question | Context | Answer |
|---|---|---|---|
| Q6 | Does the On-Ramp pre-fund a fiat balance with the EMI, or pay per allocation? | Pre-funding enables instant minting; per-request depends on bank transfer speed | Pre-fund avaliable via integrated bank account |
| Q7 | Does the EMI provide an API, or is minting request manual (dashboard)? | High-volume On-Ramps need API; small On-Ramps might start manual | EMI can operate custodial accounts |
| Q8 | What is the minting SLA? (fiat confirmed → tokens on-chain) | Target: minutes for pre-funded, hours for bank-transfer-funded | Semi-instant |
| Q9 | If EMI must verify fiat receipt before minting, does standard SEPA/wire transfer mean minting takes several days? | Impacts user experience and On-Ramp liquidity management | Pre-funding is an option |
| Q10 | How does KYB/address registration work with EMI? Does each address have to be registered/whitelisted separately? | On-Ramp may want to use stealth addresses for privacy | |
| Q11 | What ways need to be provided for On-Ramp/other customers to request mint — is fiat transfer via standard SEPA/wire enough? | Fiat transfers can take several days | |
| Q12 | How does the On-Ramp custodial infrastructure work? | Do they use Fireblocks? If private account, do we need custodial infra/TEE for storing secrets? (TODO: link document describing design for TEE custody/Fireblocks) | |
| Q13 | What other compliance/AML requirements are imposed on EMI when minting? | MiCA/AML probably complicate details of the flow on EMI side |
Low Priority
| # | Question | Context | Answer |
|---|---|---|---|
| Q14 | What are the minting limits per On-Ramp? | Daily/monthly caps, per-transaction max | |
| Q15 | Does EMI charge gas for minting from the fiat amount or cover it as a business expense? | Affects pricing model and fee transparency |