diff --git a/UMSETZUNGSPLAN-Modularisierung.md b/UMSETZUNGSPLAN-Modularisierung.md
index 645ab73..e1fe24d 100644
--- a/UMSETZUNGSPLAN-Modularisierung.md
+++ b/UMSETZUNGSPLAN-Modularisierung.md
@@ -134,6 +134,32 @@ Eintrag in den Core-Log und einen Detaileintrag in seinen eigenen Log.
   Betriebsschalter).
 - **Modul-Settings-Sektion:** jedes Modul trägt seine eigene Sektion zum Settings-Tab bei
   (analog zu den UI-Tabs), registriert über den `IPolyTraderModule`-Contract.
+- **API-Keys sind Modul-Settings:** Alchemy-/Polymarket-WSS-Keys wandern von der globalen
+  `ServerSettings` in die jeweilige Modul-Settings-Sektion (siehe 2.7).
+
+### 2.7 Streaming / WebSocket-Architektur  *(Entscheidung 2026-07-01)*
+
+**Prinzip:** Der **Core stellt die WSS-Verbindungs-Klasse als wiederverwendbare Fähigkeit**
+bereit — **keinen** geteilten Singleton-Stream. Jedes **Modul erzeugt seine eigene Instanz**
+mit **eigenem API-Key und eigenem Filter**.
+
+**Begründung:** Blockchain-/WSS-Streams werden modulspezifisch **gefiltert** (sonst viel zu
+umfangreich). Ein einzelner, Core-gesteuerter Stream, auf den mehrere Module gleichzeitig
+zugreifen, wäre für jedes einzelne Modul mit nutzlosen Informationen geflutet.
+
+**Aufteilung des heutigen `AlchemyWebsocketService`:**
+- **Core** (`PolyTrader.Core.Streaming`): Verbindungs-Mechanik — `ClientWebSocket`, `eth_subscribe`,
+  Empfangs-Loop, Decode, Reconnect/429-Backoff, Health. Parametrisiert über eine
+  `BlockchainWssSubscription` (Contract, Topics, Adress-Filter) + RPC-URL/Key. Als **Factory**
+  (`IBlockchainWssClientFactory.Create()`), damit jedes Modul eine eigene Instanz bekommt.
+- **Modul** (`CopyTrading`): `CopyTradingBlockchainListener : BackgroundService`, der eine
+  Core-WSS-Instanz mit dem Copytrading-Filter (Wallets der getrackten Master-Trader) + dem
+  Modul-eigenen Alchemy-Key betreibt, den gefilterten Substream konsumiert und selbst reagiert
+  (TraderMonitor-Poll, Re-Subscribe bei Trader-Listen-Änderung).
+
+Analog für den Polymarket-User/Market-WSS (`PolymarketWssClient` → Core-Verbindungsklasse +
+Modul-Listener). `IsAlchemyHealthy` (heute im Core-State) wird zum Health-Signal der jeweiligen
+Modul-Instanz.
 
 ---
 
@@ -234,10 +260,15 @@ Dreh- und Angelpunkt für Phase 5.
       Accounts, MarketCache, GlobalPnl) vs. `CopyTradingState` im Modul (Traders,
       MasterTraderPositions, TraderAnalyticsCache, TotalCopyTrades, PendingOrderTimestamps,
       SixSharesMinimum); 10 Konsumenten umgestellt. Modulgrenze auf State-Ebene gezogen.
+- [x] **5.3a** (`f5e7eaf`): MarketSyncService → Core (nur Core-State).
 - [ ] **5.3:** Modul-Services physisch ins Modul-Projekt verschieben: TraderMonitorService,
-      CopyTradingEngine, beide Analytics-Jobs. Ebenso die jetzt entkoppelbaren Infra-Services
-      neu verorten: MarketSyncService (nur Core-State → Core), Alchemy/WSS/Snapshot
-      (CopyTradingState-gekoppelt → Modul bzw. bleiben vorerst App).
+      CopyTradingEngine, beide Analytics-Jobs (blockiert durch ClosedTrade-Migration, s.u.).
+- [ ] **5.3-WSS (siehe 2.7):** `AlchemyWebsocketService` **aufteilen** — Verbindungs-Klasse
+      (`IBlockchainWssClient` + Factory) → Core; `CopyTradingBlockchainListener` → Modul
+      (eigener Key + Filter). Analog `PolymarketWssClient`. API-Keys → Modul-Settings.
+- [ ] **ClosedTrade-Migration (Voraussetzung für 5.3):** `ClosedTrade` → Modul,
+      `ICopyTradeLogRepository`, `closed_trades`-Zugriffe in TraderMonitor/CopyTradingEngine/WSS
+      umstellen (~20-25 Stellen; frm_main/Persistence-Nutzungen laufen via Modul-Referenz weiter).
 - [ ] Copytrading-UI-Tabs aus `frm_main` in das Modul auslagern (Master/Slave-Verwaltung,
       Modul-Analyse, Closed Trades). `frm_main` wird zur reinen Shell (Terminal, Jobs,
       Core-Gesamt-Dashboard, Settings-Rahmen).