3. Merchant ↔ EMI
Actors
| Actor | Role |
|---|---|
| Merchant Backend | Merchant's server-side system. Controls multiple stealth addresses, manages L3 commitments and burns. |
| EMI Backend | Electronic Money Institution. Verifies KYB, validates burn proofs, initiates fiat payouts. |
| On-Chain (Contract) | L3 Merkle tree for commitments, burn mechanism with BPK. |
| Bank / PSP | Executes fiat transfer to merchant's bank account. |
Flow Overview
Detailed Flow
Step 1: Merchant commits stealth address balances to L3
The merchant backend controls multiple stealth addresses that have accumulated encrypted balance from customer payments (see doc 2). To settle, the merchant moves these balances into L3 commitments.
Step 2: Merchant burns L3 commitments
The merchant burns committed stakes using its EMI-assigned userSalt and a random nonce. The burn produces a burnBPK that only the EMI can attribute to the merchant.
Step 3: Merchant requests settlement from EMI
The merchant contacts the EMI with proof of burn. The EMI verifies the merchant's KYB status, validates the burn on-chain, and initiates fiat transfer.
Full End-to-End Flow
Privacy Properties
| Property | Status | How |
|---|---|---|
| Merchant's stealth addresses hidden from EMI | Yes | EMI never sees which stealth addresses the merchant operates |
| Revenue volume per stealth address hidden | Yes | L3 commitments break the link between stealth address and settlement amount |
| Link between customer payments and settlement | Broken | L3 commit + burn severs the on-chain trail |
| EMI knows merchant identity | Yes | KYB establishes the merchant's legal identity |
| EMI knows settlement amount | Yes | Claimed in settlement request, verified against burn |
| EMI knows burn salt | Yes | EMI assigned the userSalt during KYB onboarding |
ZKP/EB Components and Features Used
| Component / Feature | Used? | How |
|---|---|---|
| Stealth Addresses | Yes | Merchant controls multiple stealth addresses that accumulate revenue from customer payments |
| Encrypted Balance (EB) | Yes | Stealth addresses hold encrypted balances — amounts hidden on-chain |
| L3 Commitments | Yes | Merchant stakes EB into L3 Merkle tree before burning |
| Burn with BPK | Yes | burn(stakes, {userSalt, nonce}) — tokens destroyed, burnBPK = hashToCurve(userSalt ‖ nonce) for EMI verification |
| userSalt | Yes | EMI-assigned salt per merchant — links burn to merchant identity without revealing stealth addresses |
| EBEMT Contract | Yes | Tokens are permanently burned on-chain, maintaining 1:1 reserve integrity |
| Blacklist / Freeze | Possible | EMI could freeze specific stealth addresses if flagged during AML review |
| UKRC / Threshold Decryption | No | Not directly involved — EMI verifies burn via BPK, not by decrypting balances |
Settlement Models
| Model | Description | Frequency | Suited For |
|---|---|---|---|
| On-demand | Merchant initiates settlement whenever needed | Ad hoc | Small merchants, low volume |
| Batched | Merchant accumulates burns, requests settlement periodically | Daily / weekly | Medium merchants |
| Scheduled | Merchant and EMI agree on a regular settlement cadence | Fixed intervals | Large merchants, contractual SLA |
| Threshold | Merchant auto-triggers settlement when accumulated balance exceeds a threshold | Event-driven | High-volume merchants |
Requirements
| # | Requirement | Priority | Notes |
|---|---|---|---|
| R1 | Merchant can settle encrypted stablecoin revenue for fiat via EMI | Must | Core off-ramp |
| R2 | Merchant must complete KYB with the EMI before any settlement | Must | Business identity verification — UBO, registration, AML screening |
| R3 | EMI verifies burn proof (BPK match) before initiating fiat transfer | Must | Prevents fraudulent settlement claims |
| R4 | Tokens are permanently burned on-chain before fiat is paid out | Must | 1:1 reserve integrity — MiCA Art. 54 |
| R5 | EMI never learns which stealth addresses the merchant operates | Must | Core privacy property |
| R6 | Merchant backend can commit and burn from multiple stealth addresses in a single settlement | Should | Operational efficiency for multi-address merchants |
| R7 | Settlement SLA: fiat within 1 business day of verified burn | Should | Contractual, depends on banking partner |
| R8 | EMI provides an API for programmatic settlement requests | Should | High-volume merchants need automation |
| R9 | Burn must support consuming multiple L3 commitments in a single private withdrawal | Should (long-term) | Merchant accumulates many small commitments from individual customer payments across stealth addresses. At settlement time, these must be burned together in one operation — not one-by-one. Without batch burn, the number of individual burns leaks transaction volume and creates a gas/cost bottleneck. This is a private withdrawal: the burn collapses N commitments into a single proof without revealing which commitments were consumed. |
Assumptions
| # | Assumption | Impact if Wrong |
|---|---|---|
| A1 | Merchant operates its own backend — not the SDK | If using SDK, the integration model and key management story change |
| A2 | Merchant controls multiple stealth addresses from customer payments | If single address, simplifies the flow but reduces privacy |
| A3 | EMI assigns a userSalt to the merchant during KYB onboarding | If salt assignment works differently, BPK verification logic changes |
| A4 | Merchant can batch multiple L3 commitments into a single burn | If one-burn-per-commitment, gas cost and complexity increase |
| A5 | Gas for L3 stake + burn is paid by the merchant | If EMI-sponsored or relayed, changes trust model |
| A6 | EMI can process settlements within published SLA | Banking partner latency is the bottleneck |
| A7 | KYB is a one-time process; subsequent settlements only require burn verification | If re-verification required per settlement, adds friction |
Open Questions
| # | Question | Context | Answer |
|---|---|---|---|
| Q1 | What does KYB onboarding look like in practice? | Business registration docs, UBO verification, AML screening — is this handled by the EMI directly or via a third-party KYB provider? | |
| Q2 | How is the userSalt delivered to the merchant during KYB? | Secure channel? API response? Does the merchant need to store it securely? | |
| Q3 | Can the merchant aggregate multiple burns into a single settlement request? | Reduces API calls but increases verification complexity on the EMI side | |
| Q4 | What are the AML thresholds for merchant settlements? | Enhanced due diligence for large settlements (e.g., > €15k single, > €100k cumulative) | |
| Q5 | Who pays gas for the L3 stake and burn transactions? | Merchant? EMI-sponsored? Relayer? Gas costs matter at scale. | |
| Q6 | How does multi-currency settlement work? | Merchant earns EUR + USD across stealth addresses — settle each separately or convert? | |
| Q7 | What happens if a merchant is flagged for AML after burns but before settlement? | Tokens are already destroyed on-chain. Fiat transfer is blocked. How is this resolved? | |
| Q8 | Is there a fee structure for settlement? | EMI spread, flat fee, or percentage? | |
| Q9 | Can the EMI batch-verify multiple burn proofs in one operation? | Would improve settlement efficiency for high-volume merchants | |
| Q10 | How does the merchant prove total burned amount when burns span multiple transactions? | EMI needs to sum verified burns. Does the merchant provide a list of txHashes, or does the EMI scan on-chain? |