Phase 2 Baustein 3: Transfer RealUnit↔RealUnit (Wallet-zu-Wallet via QR)

[TaprootFreak]

Kontext

Teil von #666 (RealUnit Phase 2), Baustein 2: Transfer via QR zwischen RealUnit-App-Nutzern (Wallet-zu-Wallet). Dieser Baustein hebt eine Phase-1-Non-Action auf (Transfers waren in Phase 1 explizit ausgeschlossen).

Abgeleitet aus der Schritt-0-Tiefenanalyse in #666 (siehe Analyse-Kommentar). Baustein 1+2 (OCP-Pay) ist umgesetzt in DFXswiss/api#3819 + #674 — die dort gebauten Bausteine (Scanner, Signing-Muster, Broadcast-Helper) werden hier wiederverwendet.

Ist-Stand (aus der Analyse)

Schicht	Stand
App	🔴 nur receive (QR-Anzeige der eigenen Adresse), kein send-Flow
dfxswiss/api	🔴 kein generischer user-initiierter Wallet→Wallet-Transfer-Endpoint (nur Admin-gs/evm-Endpoints)

Empfohlener Ansatz: on-chain REALU-Transfer (kein OCP-Umweg)

Konsistent zum bestehenden Sell-/Swap-Muster (Backend baut unsignierte Tx → App signiert → {r,s,v} → Backend rekonstruiert + broadcastet). Kein neuer Krypto-Pfad in der App nötig.

dfxswiss/api (→ develop, Draft-PR)

• Neuer Endpoint-Satz unter /v1/realunit/transfer analog zu Swap:
  • PUT /v1/realunit/transfer — Quote/Validierung (Empfängeradresse, Betrag in REALU-Shares; REALU hat decimals = 0 → ganze Shares; Gas-/ETH-Check), gegated wie Sell/Swap (Registration + KYC30).
  • PUT /v1/realunit/transfer/:id/unsigned-transaction → unsignierte REALU transfer(address,uint256)-EIP-1559-Tx.
  • PUT /v1/realunit/transfer/:id/broadcast → { txHash } (wiederverwendet den geteilten broadcastSignedTransaction-Helper aus #3819).
• Migration nur falls Entity/Spalte nötig (vermutlich nicht — TransactionRequest wiederverwendbar).

RealUnitCH/app (→ staging, Draft-PR)

• Neuer Send-Screen (Page + Cubit pro Schritt), Empfängeradresse per QR-Scan (Scanner aus feat: OCP pay-flow (RealU→ZCHF→Open CryptoPay) #674 wiederverwenden) oder manuelle Eingabe, Betragswahl, Bestätigung.
• Signing über das bestehende signToSignature→{r,s,v}-Muster (Software + BitBox einheitlich, kein walletType-Branch), Gas-/Faucet-Pfad wie im Pay-/Sell-Flow.
• Dritte/neue Dashboard- bzw. Receive/Send-Navigation; i18n DE/EN; Exception-Surface-Test; Coverage-Floor.

Offene Punkte (vor Implementierung klären)

1. Limit/Compliance: Ist ein reiner on-chain REALU↔REALU-Transfer (Self-Custody, kein Fiat, kein Brokerbot) trading-limit-pflichtig? Analog zur Swap-Entscheidung in #3819 vermutlich limit-frei (Limits an der Fiat-Grenze), aber bestätigen — nicht vorab entscheiden.
2. Adress-Validierung: nur EVM-Adressen derselben Chain (Mainnet) akzeptieren; klare typisierte Fehler bei ungültiger Adresse/Self-Transfer.
3. Gas: User zahlt Gas (ETH) — Faucet-Pfad wie im Pay-/Sell-Flow; Verhalten bei fehlendem ETH.
4. „Pay an andere Wallet" via OCP? — alternativ statt direktem on-chain Transfer; in der Analyse als Option genannt, hier zugunsten des einfacheren on-chain Transfers verworfen. Bei Bedarf erneut prüfen.

Reihenfolge / Abhängigkeiten

• Nach Baustein 1+2 (feat(realunit): add swap-only and OCP pay-flow workflow endpoints DFXswiss/api#3819, feat: OCP pay-flow (RealU→ZCHF→Open CryptoPay) #674).
• Wiederverwendung: Scanner + Signing/Cubit-Muster (feat: OCP pay-flow (RealU→ZCHF→Open CryptoPay) #674), Broadcast-/Sign-Helper (#3819).
• Workflow: Feature-Branch → Draft-PR (api gegen develop, app gegen staging), 3-Subagent-Review, CI grün, kein Self-Merge.

[TaprootFreak]

Update (Gas-Funding-Anforderung, siehe #666-Kommentar): Das ETH-Gas für W2W-Transfers trägt DFX, aber aus einer dedizierten, eigenständigen W2W-Gas-Funding-Wallet (eigener Private-Key, konfigurierbar aus Vault/Config, nie hardcoded), strikt getrennt von der Sell/OTC-Gas-Quelle. Umsetzung: Wiederverwendung des bestehenden EIP-7702-Relayer-Mechanismus (transferTokenWithUserDelegation), aber mit dediziertem W2W-Relayer-Key statt getRelayerPrivateKey. Plus Balance-Monitoring + Low-Balance-Alert für die Funding-Wallet. Provisionierung (Key generieren, Vault, ETH-Funding) = Operator-Task; Code wird parametrisiert dagegen gebaut, nötige Config-Keys werden dokumentiert. Konsequenz für den App-Flow: gasless EIP-7702-Signing (wie Software-Sell); Bitbox/Non-EIP-7702 wird als 'nicht unterstützt' sauber typisiert gated.