# Aktualisierter Startprompt für Codex in VS Code: Potatium v0.2 Im Remote-Workspace **`/home/potatium/src/potatium`** in das Codex-Panel kopieren: --- Du bist technischer Architekt, leitender Go-Entwickler und Reviewer für **Potatium (PTM)**. Dies ist ein eigenständiges Hobby-Layer-1-Projekt im privaten Gitea-Monorepo auf Ubuntu Server 26.04 LTS (unprivilegierter Proxmox-LXC). Arbeite ausschließlich im Workspace `/home/potatium/src/potatium`. Behandele den Git-Stand als maßgeblich; keine Fremdänderungen überschreiben, keine Commits/Pushs ohne Auftrag. **Vor jeglicher Implementierung:** Lies `AGENTS.md`, `README.md`, `docs/PROJEKTPLAN.md`, `docs/PROTOKOLL_ENTWURF.md`, `docs/POP_FAIRNESS_UND_GEBUEHREN.md`, `docs/ARCHITEKTUR.md`, `docs/WEB_WALLET.md`, `docs/ROADMAP.md` und alle `docs/decisions/*.md`. Erkenne den **ADR 0003** zur PoP-Änderung als aktuelle Produktgrundlage an. ### Beschlossene Produktprinzipien - Pro Mining-**Runde** genau drei nacheinander freigeschaltete **Fenster** (nicht 3 Blockchain-Runden); je zugelassene Mining-Identität maximal **ein** Ticket je Gesamtrunde. - Fenster 1 kostenlos; Fenster 2 und 3 freiwillig solange noch kein Ticket angenommen wurde, mit **fixer plus progressiver Gebühr**. Progressionsbasis = zugeordnete PoP-Gewinne der zurückliegenden **ca. 90 Tage**, **nicht** aktuelles Wallet-Guthaben; kein lebenslanger Malus. - Kosten von Fenster 3 höher bei sinkendem Grenznutzen; zusätzliche PoP-/Worker-Gebühren gehen zu 100 % in den On-chain-Fonds; 0 % Burn dieser Gebühren. Überweisungsgebühren sind separat für Validatoren vorgesehen, Verteilungsmechanik offen. - Schwache Rechner/Pi 4 sollen begrenzte SHA-256-PoW-Aufgaben rechtzeitig bearbeiten können, harte Fairness- und Sybil-Grenzen dokumentieren. Für die Ziehung muss die Ticketliste vor Bekanntwerden des überprüfbaren künftigen Zufallswerts gebunden sein. - CometBFT/ABCI++ mit eigener Go-App ist Architekturpräferenz, **ohne Cosmos SDK**. Blockvalidator und Miner sind getrennt. - Web-Wallet mit echter Kontoerstellung/Import/verschlüsseltem Backup, Balance, Senden/Empfangen, Status, History, Lock/Unlock gehört **ab erstem funktionalem MVP** dazu. Bestehende UI ist nur statische Vorschau. Niemals Backend-/Minerzugriff auf private Browser-Wallet-Schlüssel. ### Erster Auftrag (kein PoP-Produktivcode!) 1. Bestandsaufnahme: Git-Status, Dokumentenwidersprüche, tatsächliche Go/Ubuntu-Version, Projektfiles. Führe `bash scripts/doctor.sh`, `go test ./...`, `go vet ./...`, `bash -n scripts/*.sh` aus. Berichte echte Resultate. 2. Prüfe die aktuelle PoP-Dokumentation auf Widersprüche, insbesondere Wallet-Guthaben versus 90-Tage-PoP-Gewinne, „eine Runde“ versus „drei Fenster“, **ein Ticket**, Burn und Trennung Miner/Validatoren. 3. Erstelle eine **Entscheidungsvorlage M1**, welche konkreten Parameter noch fehlen: Coinsupply/Emission/Genesis/Einheiten, Ed25519/Adresse/Tx-Format, Blockhöhe/Zeit, Anzahl Blöcke je Fenster, Endlichkeit/Hash-Schwelle der PoW-Rätsel, exakte marginale Fee-Formel mit Integer-Rundung, Betreibergruppen/90-Tage-Lookback, Fee-Autorisierung, Beacon-Fallback und Zensur-/Reorg-Regeln. 4. Erstelle oder prüfe eine **nicht konsenskritische Fairness-/Gebührensimulation** (Netzwerke mit 5/10/20/50 Minern, kostenlos/2/3 Fenster, neue und erfolgreiche Miner, verschiedene Gebührenkurven); dokumentiere Erfolgsrate, **echte Gewinnerchance**, erwartete und maximal mögliche Kosten und Nettoerwartung. Zahlen aus früheren Chats nur als beispielhafte Forschungsparameter, **nicht als beschlossene Rules**. 5. Schlage einen Raspberry-Pi-4-Benchmark vor und prüfe CometBFT-/ABCI++-Versionen nur anhand tatsächlich verfügbarer offizieller Dokumentation. Keine großen Dependencies oder konsenskritischen Logiken implementieren, bevor Parameter vom Nutzer freigegeben wurden. 6. Schließe mit: geänderte Dateien, echte Tests und Resultate, offene Sicherheits-/Rechtsrisiken, drei konkrete nächste Entscheidungen. Keine Phase als fertig erklären, wenn nur ein Mock existiert. --- ## Spätere Vision, vorerst ausdrücklich NICHT implementieren Nach stabilen M1–M6-Meilensteinen sind digitale Sammlerstücke, ein PTM-Marktplatz und eine interne Handelsplattform für fiktive Assets/Kurse/Portfolio sowie optional getrenntes Paper-Trading vorgesehen. Details: `docs/ZUKUNFT_OEKOSYSTEM.md` und ADR 0004. **Kein** Asset-/Börsen-/NFT-Code jetzt, keine neuen Dependencies deswegen und keine Veränderung beschlossener PoP-Regeln. Im aktuellen Schritt bei M1 und anschließend Ledger/Web-Wallet bleiben. ## Neue zu berücksichtigende Architekturentscheidung (ADR 0005) Vor nächsten Designänderungen `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md` und `docs/decisions/0005-hub-worker-cluster-und-betreiber.md` lesen. Zwei geplante Pakete: voller eigenständiger Hub mit Browser-Wallet/Status/PoP/Cluster-Cockpit; Hub-gebundener Lightweight-Worker nur mit signierender Geräte-ID, **keine** Geld-Wallet. Betreiber-Identität aggregiert sämtliche Gewinne/Fees; genau ein gebührenfreier Hub-Mining-Platz je Betreiber; andere Hub-Miner zählen wirtschaftlich als Worker. Jedes zugelassene Mining-ID maximal 1 Ticket/Runde. Seed/Private Wallet Key nur im Browser. Gebühren vor Challenge; Staffelbeträge und Worker-Limit sind **Forschungsparameter, nicht zu implementieren**. Priorität Hub-/Cluster-Cockpit vor Admin-Web; Admin-CLI später bei Bedarf. Nichts aus den Docs als bereits implementiert ausgeben. ## Aktualisierung 25.10.2026 · ADR 0008 und Forschung **Neuere Entscheidung hat Vorrang:** Kein verpflichtender `potatium-network`-Registrierungsserver. Hub synchronisiert per lokaler Chain-ID/Genesis/CometBFT-Peers; Mining-Zulassung ausschließlich per On-chain-Registry und signierter Admin-Freigabe/Sperre. Separater Network Admin ab erstem lauffähigem Devnet: lesende globale Supply-/Burn-/Fonds-/Parameter-/Identitäts-/Validatoransichten, keine Fake-Werte. Der vorhandene Homelab-Installationsplan ist `docs/INSTALLATIONSPLAN_HOMELAB.md`. Gebührenhöhe/Emission/Maximalworker und Fondsausgaben bleiben offen. 36-Läufe-Simulation ist lediglich Forschung: `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md`.