Redemption Process

Purpose

The redemption process burns stablecoin tokens at par value (1 token = 1 EUR) and sends equivalent fiat to the holder's verified IBAN. The Supply Signer reviews KYC and sanctions/freeze-list checks before signing the burn; the token contract enforces sanctions and freeze at transfer time regardless.

The EMI may also sell and buy tokens from users, but that is neither issuance nor redemption and is not part of this process.

Who Can Request Redemption

Any token holder with completed KYC. The request references an existing KYC record.

Trigger

A holder emails Customer Support requesting redemption of their tokens. The process begins once Customer Support creates the redemption record with the holder's details and a reference to their completed KYC.

What happens before (holder outreach, KYC verification, initial communication) and what happens after an end state is reached (dispute resolution, follow-up on rejected requests) is outside the backoffice.

Overview

1. Customer Support creates the redemption request. System validates inputs and runs sanctions/freeze checks on the source wallet (display)
2. Customer Support communicates the redemption address to the holder. System detects incoming tokens and runs sanctions/freeze on the actual sender.
3. Supply Signer reviews and signs the burn at cut-off
4. Treasury Officer sends fiat to the holder's verified IBAN

If the signer rejects at burn time and tokens can be returned, they are returned to the sender (Step 3a). If the wallet is sanctioned or subject to a legal hold, the request goes to Compliance Hold (Step 3b) — the only step where CO is the owner. Holder notification at any stage is outside this process.

---

Constraints

• MiCA Art. 49 — par value: 1 token = 1 EUR, always. No variable rate, no commissions, no minimum redemption amount. The EMI does not charge fees and cannot pass through fiat transfer costs.
• MiCA Art. 49 — payout: bank transfer to IBAN or e-money. Not in crypto.
• MiCA Art. 49 — at any time: holders can submit whenever they want. Processing follows the cut-off schedule.
• Cut-off schedule (whitepaper): tokens received before cut-off are burned and paid out the same working day; after cut-off, next working day. Weekends and holidays queue until the next working day. Processing is batched: at cut-off, system burns all approved tokens, then Treasury Officer sends all corresponding fiat.
• No self-custodial burn (source: Bartek Kapuściński): self-custodial burn cannot be possible — all supply-changing actions must go through the EMI. Burn is gated by BURNER_ROLE on the Supply Multisig (see Infrastructure); holders cannot destroy tokens themselves.

---

Steps

The following describes the happy path. Any step can result in rejection — the applicable closed status depends on where the rejection occurs (see End States).

Step 1 — Create Redemption Request

Owner: Customer Support · Status: new → awaiting_token_transfer or closed_kyc_rejected

• Create redemption record with: holder identity, IBAN, KYC reference, and confirmed source wallet address. No amount — the amount is determined by what the holder transfers.
• The source wallet address must be confirmed as belonging to the holder — the address-to-identity link is established before the process starts (how this is confirmed is outside this process).
• The source wallet and IBAN inputs each show an inline Known Addresses / IBAN check. A visible warning — the same address paired with more than one IBAN or KYC reference, or the same IBAN paired with more than one address or KYC reference — surfaces here. Details open in a side panel without leaving the request.
• Status advances to awaiting_token_transfer. A hard fail (sanctions hit, missing KYC) closes the request as closed_kyc_rejected.

Step 2 — Provide Redemption Address & Await Tokens

Owner: Customer Support / System · Status: awaiting_token_transfer

• Customer Support communicates the shared custodial redemption address to the holder. The same address is used for all redemption requests — attribution is by sender address and amount, matched against the confirmed source wallet on the request.
• System detects incoming tokens and records: tx hash, amount, sender address. The transferred amount becomes the redemption amount — whatever the holder sends is the amount that will be burned and paid out.
• If the sender address does not match the confirmed source wallet on any open request → tokens are returned to the sender manually via the Incoming Transfers dashboard. The system flags the transfer as unattributed and surfaces it for return.
• After 60 calendar days with no transfer → request closes as closed_expired.

Step 3 — Burn Tokens

Owner: Supply Signer · Status: awaiting_burn → awaiting_fiat_transfer

• Burn is pre-scheduled — eligible requests queue for the next cut-off.
• At cut-off, a Supply Signer reviews each request before signing. The backoffice shows the sanctions / freeze-list check, KYC summary, and Known Addresses lookup. Signer enters a free-text rationale.
• Sign → burn submitted via the Supply Multisig (see Infrastructure). System waits for L1 batch finality and records the burn tx hash.
• Reject — request branches to Step 3a (returnable) or Step 3b (sanctioned / legal hold).

Step 4 — Send Fiat to Holder

Owner: Treasury Officer · Status: awaiting_fiat_transfer → closed_redeemed

• Treasury Officer sends the equivalent EUR amount to the holder's verified IBAN. 1 token = 1 EUR, no deductions.
• Records the fiat transfer reference. IBAN must match the verified IBAN on the request.

Step 3a — Return Tokens (rejection path)

Owner: Supply Signer · Status: awaiting_token_return → closed_rejected_tokens_returned

• On signer rejection at Step 3 where tokens can be safely returned, a Supply Signer manually transfers tokens from the custodial redemption address back to the sender address via the Incoming Transfers dashboard.
• System waits for L1 batch finality and records the return tx hash against the request.

Step 3b — Compliance Hold (sanctions / legal hold)

Owner: Compliance Officer · Status: compliance_hold

• On signer rejection at Step 3 where the wallet is sanctioned or subject to a legal hold, tokens cannot be returned (returning value to a sanctioned address may itself be a violation) and cannot be burned (the holder has not been paid out).
• Tokens remain at the redemption address indefinitely. The request stays in compliance_hold until resolved by Compliance Officer in coordination with legal counsel or law enforcement. This is the only redemption step where CO is the owner.
• Resolution is outside this process.

---

End States

Status	Description
closed_redeemed	Tokens burned, fiat sent. Process complete.
closed_kyc_rejected	Identity or sanctions check failed. No tokens involved.
closed_rejected_tokens_returned	Wallet screening failed after tokens arrived. Tokens returned to sender.
closed_withdrawn	Holder withdrew the request before tokens were transferred.
closed_expired	Tokens not received within 60 calendar days.
compliance_hold	Tokens held at redemption address — sanctioned or legally frozen. Cannot be returned or burned until resolved.

---

Infrastructure

Mint transactions execute through the Supply Multisig — a Safe (2-of-3) holding BURNER_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
End-to-end target (token receipt to fiat sent)	TBD (suggestion: T+1 business day)
Token transfer timeout	TBD (suggestion: 60 calendar days)

---

Open Decisions

Decision	Suggested	Notes
Attribution checks	TBD	Is attribution by sender address only, or address + amount? If address + amount, the holder must declare the amount at request time and the transfer must match exactly — mismatches are returned. Address-only is simpler for holders but weaker attribution if a single sender has multiple open requests or sends in multiple transactions.
Tokens from unknown senders	TBD	With a single shared address, any transfer from an address not matching an open request is returned. Needs a policy for addresses that are sanctioned / cannot be safely returned.

---

Alternatives Considered

Holder burns tokens themselves (no custody): instead of transferring tokens to a redemption address, the holder would burn tokens directly. This is not possible: the contract's burn function requires BURNER_ROLE, which is held only by the Supply Multisig. Burn is not self-custodial. Even if it were, burning before compliance approval would destroy tokens that might need to be returned on rejection.

Fresh address per request (instead of single shared custodial address): each request gets its own monitored address, generated on KYC approval and discarded when the request closes. This gives clean attribution by design — any tokens arriving at an address belong to exactly one request. However, it requires per-request address generation and monitoring infrastructure. For v1, the single custodial address was chosen as simpler to operate; attribution is by sender address matched against open requests. Per-request addresses may be reconsidered if attribution proves too fragile.

Amount declared upfront on request: the holder could declare the redemption amount when creating the request, and the process would validate the incoming transfer against it. This was rejected because the compliance check (wallet screening) happens after the transfer, not before — so the process already accepts whatever arrives. Declaring an amount upfront only creates a mismatch problem (over/underpayment) that requires return logic or in-process amendments. Letting the transfer determine the amount eliminates this entirely.

Fiat first, burn after confirmation (Steps 5–6 swapped): under a looser interpretation of MiCA, fiat could be sent before tokens are burned. Once the fiat transfer is confirmed, tokens are officially burned. This reduces fiat transfer issues — if the transfer fails, tokens are still under the EMI's control and can be returned instead of dealing with a post-burn failure. The tokens are already out of circulation (held at the redemption address), and fiat is still on the account or in transit. The current model (burn first, then send fiat) was chosen as the stricter MiCA interpretation — tokens are destroyed before fiat moves.