PolyTraderSharp/agentspace/prompts/Qualitaetskontrolle.md

🏗 Polkadot C# Copytrader - Qualitäts- und Performance-Audit

Dieses Audit überprüft den aktuellen C# Code auf die geforderten Metriken: Zielvorgabe 2-5 Sekunden Kopier-Latenz, Sicherheit gegen Rate-Limits und dauerhafte Programm-Stabilität.

---

🚨 1. Kritischer Flaschenhals: Latenz in der Polling-Schleife (Verfehlen des 2-5s Ziels)

• Problem: Im TraderMonitorService.cs werden die Master-Trader sequenziell abgefragt (foreach (var trader in activeTraders)). Zwischen jeder Abfrage erzwingt der Code ein await Task.Delay(500). Nach der gesamten Schleife gibt es einen globalen Sleep von 10 Sekunden.
• Auswirkung: Bei z.B. 50 Master-Tradern benötigt ein Durchlauf >35 Sekunden (25 Sekunden durch Sleep, 10 Sekunden Global-Delay). Das bedeutet, Trades werden im Schnitt mit einer Verzögerung von 15-35 Sekunden erkannt. Die Zielvorgabe von 2-5 Sekunden ist mathematisch in der aktuellen Architektur unmöglich.
• Kritikalität: 🔴 Hoch (Goal-Blocker)
• Lösungsvorschlag: Die API-Abfragen müssen parallel (Task.WhenAll) abgesetzt werden. Das starre 10-Sekunden Limit der Background-Schleife muss auf den Bruchteil einer Sekunde (z.B. durch Signal-Events oder kürzere Intervalle) reduziert werden.

⚠️ 2. Limitierung durch API Rate-Limits (Polymarket REST vs. Alchemy)

• Problem: Polymarkets öffentliche API blockiert (meist via Cloudflare) exzessives Polling (oft ab ~100 Requests / 10 Sek.). Wenn wir die Latenz (wie in Punkt 1) wirklich auf kontinuierliche 2 Sekunden bei 50-100 Tradern verkürzen, erzeugen wir 25 bis 50 Requests pro Sekunde.
• Auswirkung: Die IPs werden von Polymarket wegen Spamming gesperrt (HTTP 429 / 403). Der REST-Ansatz skaliert physikalisch nicht auf Sub-Zwei-Sekunden (es sei denn mit hunderten rotierenden Proxys).
• Kritikalität: 🟠 Mittel-Hoch
• Lösungsvorschlag: Wie in eurer Architekturbeschreibung erwähnt, ist für dieses ambitionierte Ziel (Millisekunden, < 2 Sekunden) der Alchemy Polygon WebSocket (Blockchain Listener) zwingend erforderlich. Die REST API sollte nur noch als asynchroner Fallback / Notnagel alle paar Minuten genutzt werden. Bis zur Aktivierung des WebSockets wird das Kopieren 5-10 Sekunden Latenz aufweisen müssen, um das Rate-Limit zu schonen.

⚠️ 3. Sequenzielles Order-Placement (Slippage-Risiko für hintere Accounts)

• Problem: In der CopyTradingEngine.cs werden bei einem Signal die Accounts per foreach-Schleife durchlaufen. Die Order für Account 2 wird erst berechnet, signiert und an Polymarket gesendet (POST /order), nachdem der Request für Account 1 abgeschlossen ist.
• Auswirkung: Bei 5-10 Accounts bedeutet dies, dass der letzte Account 1-2 Sekunden nach dem ersten Account seine Order abfeuert. In hochvolatilen Märkten bedeutet das einen signifikanten Preisunterschied (Slippage für die hinteren Accounts).
• Kritikalität: 🟠 Mittel
• Lösungsvorschlag: Die Orders für alle validierten Accounts parallel berechnen und abschicken. Ein Array von Task erstellen und per Task.WhenAll(orderTasks) gebündelt an die CLOB API senden.

💡 4. Geniales Order-Pricing (Performance Boost!)

• Beobachtung: Die CopyTradingEngine nutzt aktuell nicht die API, um das Orderbook nach aktuellen Preisen abzufragen. Stattdessen nutzt sie direkt den Einstiegskurs des Master-Traders aus dem Datastream + 5% Maximales Slippage Limit (decimal desiredLimit = signal.Price * 1.05m;).
• Auswirkung: Diese Vorgehensweise ist extrem intelligent. Es spart komplett einen API-Roundtrip (mindestens 200-400ms), bevor die Order platziert wird – extrem wichtig für die Latenz!
• Lösungsvorschlag: Beibehalten! Die "gemockte" PolymarketApiService.GetPriceAsync (die ohnehin gerade fest 0.50$ zurückgibt) kann langfristig gelöscht werden.

✅ 5. Ressourcen und Stabilität (Crash-Prävention)

• Beobachtung: Memory-Leaks (RAM) oder Socket Exhaustion (Port-Überläufe) treten in diesem C#-Konstrukt voraussichtlich nicht auf. Der HttpClient ist in der Program.cs als lokaler Singleton sauber registriert und wird effizient über DI weitergegeben. Die Signals-Queue (Channel) in der CopyTradingEngine wird asynchron geleert - auch hier baut sich kein unendlicher Speicher auf.
• Auswirkungen: Die Software sollte ohne Probleme tagelang im Hintergrund laufen können. (Die 5-Stunden Crash Regel aus Python durch verwaiste Threads passiert in C# BackgroundServices nicht).
• Kritikalität: 🟢 Sicher

---

🛠 Zusammenfassung für den Rollout ("Dauerbetrieb")

Die Software ist stabil und logisch gesund. Ein Einsatz im aktuellen Zustand ist risikofrei (sie wird nicht abstürzen und kauft korrekt mit Slippage-Schutz). ABER: Das anvisierte Ziel von "unter 2 Sekunden" wird aktuell aufgrund der künstlichen eingebauten Polling-Delays (um das Rate-Limit der Polymarket REST-API nicht zu verletzen) verfehlt. Solange der direkte Blockchain Listener (Alchemy) nicht in die Channels hooked, operiert die Software mit ca. 15 Sekunden Delay.