Issuance Process
Purpose
The issuance process mints new stablecoin tokens on-chain in response to a partner request backed by incoming fiat. Mints can be public (standard ERC-20) or private (shielded via ZK proof), as specified by the partner. It enforces fiat confirmation and Supply Multisig co-signing before any tokens are created.
Who Can Request Issuance
Only whitelisted partners with valid KYB on file. A partner must complete the Partner Whitelist process before they can request issuance. It ensures every mint is attributed to a known partner and reduces the risk of minting to a wrong address.
Whitelisting is a backend-only operation — Customer Support proposes the partner, their wallets, and their limits; Compliance Officer confirms every change.
The EMI itself can be onboarded as a whitelisted partner and follow the same process for operational needs (e.g. topping up liquidity venues).
Retail customers are not supported for direct issuance requests at this time. This may change in the future.
Trigger
A whitelisted partner requests issuance and initiates a fiat transfer to the EMI's bank account. The issuance request and the fiat transfer happen outside the backoffice. The process begins once the fiat transfer has arrived and the request details are known.
This process is part of broader operations. What happens before (partner communication, fiat transfer initiation) is outside this process. If the request is rejected or expired, the fiat return, partner follow-up, and any dispute resolution must also be handled outside the backoffice.
Overview
- Customer Support or Treasury Officer creates the issuance request in the backoffice with fiat transfer details
- Treasury Officer confirms the fiat details are correct (fiat transfer confirmed, amount, sender, source account)
- Backoffice prepares the mint transaction → two Supply Signers review and sign
- System monitors for finality and confirms
Constraints
- MiCA Art. 49: tokens can only be issued on receipt of funds. The backoffice enforces this — a mint transaction cannot be prepared until fiat confirmation is complete.
- 2-of-3 multisig: mint is the only supply-changing action that requires multisig. Two different Supply Signers must review and sign — each is independently accountable for the AML verification at signing time.
Steps
The following describes the happy path. Any step can result in rejection → closed_rejected. We prefer fast rejection over handling corner cases in-process — corrections happen outside the backoffice, and a new request is created.
Step 1 — Create Issuance Request
Owner: Customer Support or Treasury Officer · Status: new → awaiting_fiat_confirmation
- Request is created in the backoffice with: partner ID, amount (from the fiat transfer), destination address (whitelisted), mint type (
publicorprivateas specified by partner), and fiat transfer reference. - Validates: amount > 0, destination address is whitelisted, mint type is valid, partner is active (whitelist not suspended/deactivated), and — for every configured period (daily / weekly / monthly) on the partner — the request would not exceed the remaining partner limit.
- If the wallet is not whitelisted → request is not created. Partner must whitelist the address first.
- If the amount would exceed any configured partner limit → request is not created. Partner must request a limit change or split the request across periods.
- The destination address input shows an inline Known Addresses check — partner context, prior issuance/redemption history, and any active enforcement. Details open in a side panel without leaving the request.
Step 2 — Fiat Confirmation
Owner: Treasury Officer · Status: awaiting_fiat_confirmation → awaiting_mint
- Treasury Officer confirms the fiat details on the request are correct: the fiat transfer is received, amount matches, sender matches onboarded partner, source account is previously registered.
- Irregularity: Treasury Officer rejects the request. Material irregularities are escalated to Compliance Officer outside the backoffice.
Step 3 — Mint Transaction
Owner: Supply Signers · Status: awaiting_mint → awaiting_cosign → awaiting_finality
- Backoffice prepares the mint transaction (destination, amount, mint type) and verifies pre-conditions: request is in
awaiting_mint, destination address still whitelisted and not frozen/sanctioned, partner is active, partner limits not exceeded. - Each Supply Signer reviews before signing. The backoffice shows operational context on partner and address, results of automated checks etc.
- First Supply Signer signs → status moves to
awaiting_cosign. Second Supply Signer independently reviews and co-signs. Two signers, individually accountable. - Co-sign timeout: Safe transaction cancelled, status loops back to
awaiting_mintfor a fresh transaction. Partner notified of delay.
Step 4 — Await On-Chain Finality
Owner: System · Status: awaiting_finality
- The system monitors the transaction until the configured finality threshold is reached (see Open Decisions).
- Records: tx hash, block number, confirmation timestamp.
- Partner notified outside of backoffice process.
- On revert: if recoverable → loops back to
awaiting_mint. No fiat impact — funds are already confirmed.
End States
- closed_confirmed — tokens minted and finalized on-chain. Process complete.
- closed_rejected — request rejected at any step. Consequences (fiat return, partner notification) are handled outside the backoffice.
Supply Multisig
Mint transactions execute through the Supply Multisig — a Safe (2-of-3) holding MINTER_ROLE on the token contract. Any two of the three Supply Signers can execute. Signers sign from separate devices (e.g. hardware keys, dedicated laptops). A single breach must not compromise two signers.
SLAs
| Parameter | Value |
|---|---|
| Fiat confirmation window | TBD |
| Co-sign window | TBD |
| End-to-end target | Same business day |
Open Decisions
| Decision | Suggested | Notes |
|---|---|---|
| Global (cross-partner) limit | TBD | Partner-level limits are in the Partner Whitelist. Whether to cap total daily mint volume across all partners is still open. |
| Timelock on large mints | TBD | e.g. >€1M requires 24h delay with Supply Signer veto |
Alternatives Considered
Request before fiat transfer (with parallel gate model): the request could be created before the fiat transfer arrives. This was rejected to keep the backoffice focused on managing issuance, not covering the full EMI operational process. Additionally creating the request after the fiat transfer eliminates the mismatch problem (fiat transfer amount ≠ request amount).
Compliance Officer as a per-mint gate: previously CO ran AML/sanctions screening as a dedicated step before mint preparation. Removed because (a) the deterministic checks (sanctions oracle, whitelist match, partner limits) run automatically; (b) the residual judgement call belongs to the Supply Signers who are signing for the mint anyway, with operational context shown to them at sign time; (c) EBA GL §175(a) discourages compliance staff from performing operational tasks they are meant to monitor. CO retains the partner whitelist and enforcement gates, where their independence is the value-add.