docs: update Potatium v0.6 architecture and PoP research

2026-10-25 11:45:32 +00:00
1 parent 75df8a5c0d
commit 862ccf1d03
@@ -10,7 +10,7 @@ Web-Wallet (clientseitige Schlüssel)           Raspberry Pi / alter PC
                      potatiumd RPC/API (lokal)
                                   |
           deterministic Go State Machine: Konten, Nonces,
-           PoP-Runden/Fenster, Gebühren, Burn, Tickets, Ziehung
+           PoP-Runden/Fenster, Fonds-Gebühren, Tickets, Ziehung
                                   |
                     eigene CometBFT ABCI++ App
                                   |
@@ -24,13 +24,13 @@ Web-Wallet (clientseitige Schlüssel)           Raspberry Pi / alter PC
 - **Validatoren:** CometBFT legt Blöcke und Reihenfolge fest; die Go-State-Machine lehnt ungültige Transfers, Burn, Proofs und Mint ab. Kein Coin-/Mining-Bezug zur Validator-Blockerzeugung.
 - **Miner:** separates Go-Programm für Linux amd64/arm64, ressourcenschonende Arbeit, Node-ID-Signatur, bis drei Fenster pro **einer** Runde, höchstens ein gültiges Ticket. Kann rein kostenlos betrieben werden.
 - **Wallet:** browserlokale Schlüssel-/Backupverwaltung und Signatur, kein Key-Export an Backend. Bezahlte Zusatzfenster nur nach enger runden-/fenster-/betrags-/noncegebundener Autorisierung, niemals pauschale Miner-Keyfreigabe.
- **State:** jeder Validator hält eigenen deterministischen Ledger inklusive Fensterzustand, signierter Proofs, Mining-Gewinnhistorie der letzten ca. 90 Tage, Betreiberzuordnung, Gebühren/Burn und Ticketlisten-Commit. Der 90-Tage-Begriff benötigt deterministische finale Fensterdefinition (Blockzeit versus Blockhöhe).
+- **State:** jeder Validator hält eigenen deterministischen Ledger inklusive Fensterzustand, signierter Proofs, Mining-Gewinnhistorie der letzten ca. 90 Tage, Betreiberzuordnung, Gebühren/Fonds und Ticketlisten-Commit. Der 90-Tage-Begriff benötigt deterministische finale Fensterdefinition (Blockzeit versus Blockhöhe).
 - **Transport:** localhost-only für Entwicklungs-RPC, SSH-Forwarding, sichere später explizit freigeschaltete P2P-Verbindungen.

 ## Verifikationskette

 1. Runde/Fenster mit finalisiertem Startzustand und identitätsgebundener Challenge.
-2. Fenster 1 ohne Zahlung; Fenster 2/3 nur nach bestätigter, integergenau berechneter fixer plus progressiver Burn-Gebühr.
+2. Fenster 1 ohne Zahlung; Fenster 2/3 nur nach bestätigter, integergenau berechneter fixer plus progressiver Gebühr an den On-chain-Fonds (ADR 0007).
 3. Fristgerechter Proof mit Hash und erlaubter Nonce; max. ein Ticket pro Mining-ID pro Gesamtrunde.
 4. Tickets endgültig festschreiben, anschließend fremden unbekannten verifizierbaren Beacon-Wert erhalten und Winner/Mint deterministisch berechnen.
 5. Gegen Identitätswechsel, Replay, Zensur, RNG-Manipulation, fehlende Tickets, Down-/Restart und Differenzen zwischen Validatoren testen.
@@ -38,3 +38,21 @@ Web-Wallet (clientseitige Schlüssel)           Raspberry Pi / alter PC
 ## Kritische Unbekannte

 Coin-Einheit, Adress-/Tx-/Signaturformat, Fee-Formel und Rundung, Fenstertiming, Staking/Validator-Gebührenanteile, PI-Benchmark, RNG-Quelle/Fallback, Registry-Gruppierung und persistente Datenbank bleiben offen. Dafür ADRs; keine willkürlichen Defaults.
+
+## Erweiterung: Hub, Worker und Betreibergruppe (ADR 0005)
+
+Die bisherige Darstellung „Node und Miner“ wird als **Rollen und Prozessgrenzen** präzisiert. Ein eigenständiger **Hub** ist eine vollwertige Node mit Web-Cockpit, Browser-Wallet und optionalem lokalen Miner. Ein **Worker** ist ein an den Hub gekoppelte Lightweight-Miner ohne Ledger und ohne Geld-Wallet. Jeder registrierte Mining-Prozess erhält eigene `mining_id` und signiert Nachweise. Ein physischer Rechner kann mehrere isolierte Prozesse, Ports und Datapaths ausführen, aber zusätzliche Mining-IDs müssen in der Registry erlaubt sein.
+
+Ein `operator_id` gruppiert Hub/Worker, zugelassene Mining-IDs, jüngste Mining-Belohnungen und Kosten unabhängig von Wallet-Transfers. **Ein** kostenloser Hub-Mining-Platz pro Betreiber; sonstige Mining-IDs (auch extra Hubs) sind wirtschaftlich zusätzliche Worker. Wallet-Seed nur im Browser; UI/Cluster-Verwaltung ersetzt keine Besitzer-/Wallet-Signatur. Hub-Worker-Verbindung authentifizieren, kein reines Fingerprint-Trust. Selbstständige Validatoren bleiben von Worker/PoP getrennt.
+
+Details und Bedrohungsmodell: `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md`, `docs/decisions/0005-hub-worker-cluster-und-betreiber.md`. Keine bestätigte Datenbank-/CometBFT-Version oder Implementierung.
+
+## Präzisierung v0.5: Validatoren, Admin und Datenbanken
+
+Die obige Grafik ist nur eine reduzierte Zielskizze. Die vollständige Deployment-Architektur steht in `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md` und ADR 0006. Jede CometBFT-Full-Node hält lokal ihren CometBFT- und Go-App-State; **ein Hub ist nicht zwangsläufig Validator**. Ohne aktive Validator-Stimmmacht keine Finalisierung. Potatium-Worker halten keine Blockchain-/Wallet-Spend-Keys. Es gibt keinen globalen Master-Ledger in einer zentralen Datenbank.
+
+Ein dedizierter **read-only Network Admin** gehört schon zum ersten lauffähigen Devnet, als reiner Beobachtungsdienst ohne Konsens-, Wallet- oder Registry-Schreibrechte. Monitoring-DB optional und nicht konsenskritisch. Das lokale Hub-Web-Cockpit zeigt ebenfalls schon früh echten Chainstatus. Die vollständigen Verwaltungsrechte bleiben getrennt und folgen signierten Konsensaktionen. Siehe `docs/COCKPITS_UND_MONITORING.md`. Gebührenverwendung wird separat evaluiert, nicht durch diesen Architekturhinweis geändert.
+
+## Aktuelle Vereinfachung durch ADR 0008: Keine Pflicht-Control-Plane
+
+Der separate Dienst `potatium-network` als obligatorisches Registrierungs-/Bootstrap-Portal ist **aufgehoben**. Ein Hub synchronisiert anhand verifizierter lokaler Genesis-/Chain-ID-/Peer-Konfiguration selbst per CometBFT P2P. Mining-Rechte werden ausschließlich über die signierte On-chain-Betreiber-/Mining-Registry vergeben. Nur der Projektbetreiber erhält das separate, ab Devnet lesende Network Admin mit Supply-/Burn-/Fonds-/Validator-/Identitätsstatus; Freigabe und Sperre sind später gezielt signierte Schreibaktionen. Optionales Telemetrie-Backend darf keinen Konsens-/Mining-Pfad blockieren. 100 % PoP-/Worker-Gebühren gehen weiterhin in den On-chain-Fonds, 0 % Burn. Siehe ADR 0008, `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und `docs/INSTALLATIONSPLAN_HOMELAB.md`.
@@ -0,0 +1,74 @@
+# Potatium: Benutzer-Cockpit, Clusterübersicht und Network Admin
+
+**Produktentscheidung, noch nicht implementiert, 25.10.2026.** Überall echte Quellen und klar erkennbare Fehlerzustände. Beide Anzeigeoberflächen **ab der ersten lauffähigen Devnet-Phase**, nicht erst ab M5/M6. Die jeweilige Funktionstiefe wächst mit der Architektur; UI ohne Node darf ausschließlich „nicht verbunden“ anzeigen.
+
+## Drei getrennte Blickwinkel, zwei Produktlinien
+
+1. **Potatium Hub (Teilnehmer):** Lokale Full Node mit **eigenem** Web-Cockpit und integrierter browserseitiger Wallet, optionalem eigenem PoP-Mining und Verwaltung der **eigenen** Worker. Man kann mehrere berechtigte Hubs desselben Betreibers im Hub-Cockpit zu einer Clusteransicht aggregieren. Ein Hub bleibt ohne zentralen Cluster-Master bedienbar. Wallet-Schlüssel verbleiben clientseitig.
+2. **Potatium Worker (Teilnehmer):** Keine vollständige Blockchain-/Wallet-GUI nötig; einfacher Pairing-/Health-/Diagnosemodus optional. Konfiguration und Status primär über den zugeordneten Hub. Worker meldet signiert, Hub und Chain validieren Ergebnisse unabhängig. Private Wallet-Schlüssel nie auf Worker.
+3. **Potatium Network Admin (Netzwerkbetreiber):** **Von Beginn an read-only** und vollständig getrennt vom Benutzer-Hub. Beobachtet bestätigten Chain-State, bekannte Validatoren, registrierte Operator-/Mining-Identitäten und freiwillig angebundene Host-Metriken. Keine Freigabe-/Sperr-/Validator-Änderungs-Buttons in erster Version. Für spätere Änderungen existiert eine getrennte geschützte Admin-CLI, später möglicherweise Web-Workflow mit expliziter Signatur. Ein öffentliches „Super-Admin-Token“ ist nicht vorgesehen.
+
+## Abgrenzung der Rechte
+
+| Ansicht/Aktion | Hub (Teilnehmer) | Cluster eigener Hubs | Network Admin read-only | Späterer registrierter Admin |
+|---|---|---|---|---|
+| Blockchainhöhe, Blöcke, Transaktionen, Netzwerk | Lesen | Lesen | Lesen | Lesen |
+| Eigene Wallet-Balance und signierte Transfers | Browser-Wallet | Nur explizit gekoppelt, keine Keys verteilen | **Nein** als Admin-Privileg | **Nein** |
+| Eigene Worker starten/pausieren, Limits und Gebührenbudget | Ja, lokale Berechtigung | Ja, je Hub freigegeben | Nein | Nein |
+| Eigene Node-Version, Sync, Logs, Ressourcen | Ja | Ja, nur gekoppelte Nodes | Nur publizierte/ausdrücklich freigegebene Daten | ggf. gesonderter Infrastrukturzugang |
+| Andere Betreiber-Identitäten anzeigen | Nur zulässige öffentliche Daten | Nur zulässige öffentliche Daten | Registry-/Aggregatdaten soweit freigegeben | auditierbar |
+| Miner/Validatoren genehmigen/sperren | Nein | Nein | **Nein** | erst signierte, regelkonforme Aktion |
+| Guthaben verändern, Lose festlegen, Konsens umgehen | Niemals | Niemals | Niemals | Niemals |
+
+## Früheste Anzeige: Datenquellen und Widgets
+
+| Kennwert | Quelle | Hub | Network Admin | Umgang bei fehlender Quelle |
+|---|---|---|---|---|
+| Chain-ID/Netzwerk (devnet/testnet/dauerhaft) | lokale geprüfte Nodekonfiguration/Genesis | Ja | Ja | nicht verbunden |
+| aktuelle Blockhöhe, letzte Finalisierung | CometBFT-RPC + bestätigter App-State | Ja | Ja | Höhe unbekannt, letzte Messung mit Alter |
+| Node-/Validator-Peers, Voting-Power, Sync | CometBFT-RPC/Metriken | eigene Node | alle beobachtbaren | keine Erfindungen, „nicht erreichbar“ |
+| App-Hash und Abweichungen | verifizierte Status-/Block-Daten | optional | besonders wichtig | Alarm ohne falsche Ursache |
+| TPS/Blockrate, Transaktionsfehler | beobachtete bestätigte Blöcke/Node-Metriken | Netzwerk | Netzwerk | Datenlücke markieren |
+| Supply/minted/burned/fee allocation | bestätigter Potatium-App-State | Netzwerk | Netzwerk | „nicht verfügbar“ bis implementiert |
+| Registrierte Operator/Mining-IDs, aktive Tickets, Runden | bestätigter Potatium-App-State | zulässige Übersicht | Aggregate/Registry | fehlende Chain-Funktion markieren |
+| Wallet Balance/Transfers | signierte Wallet-Adresse + echte Chainabfrage | nur freigeschaltete Wallet | kein privater Wallet-Zugriff | nicht verbunden statt Fake-Balance |
+| Hub/Worker CPU/RAM/Temperatur/Status | jeweiliger freigegebener Agent/OS | eigene Geräte | nur opt-in Metriken | nicht beobachtbar |
+| Fehler/Logs/Alerts | Node-API, dedizierter Telemetriedienst | eigene Node | freigegebene Ereignisse | Zeitstempel und Quelle anzeigen |
+
+Erste UI-Runde: **Lese-Dashboard vor vollständigem Mining**, per minimaler `/status`-Schnittstelle mit gesundem Fehlerverhalten, kein Warten bis zur Multi-Host-Phase. „Online“ bedeutet nur eine erfolgreich geprüfte Quelle, niemals implizit, dass die ganze Chain gesund ist. Chain-Daten und hostbezogene Monitoringdaten getrennt beschriften.
+
+## Architektur des Network Admin read-only
+
+- Eigenständiger kleiner Go-Prozess/Service und statisches Browserfrontend, zunächst auf `potatium-dev`, später optional auf separater Management-VM. **Kein Validator, keine Full Node und keine Konsensdatenbank erforderlich**; verbindet sich als Client mit bereits vorhandenen geschützten Node-Statusdiensten.
+- Inventar enthält Beobachtungsendpunkte und optional rollenbezogene Labels. Speicherung anfänglich kleine lokale Konfiguration, optional SQLite/Zeitreihen-DB für Graphen/Historie. Niemals zentrale Source of Truth für den Ledger.
+- Status-Zugriff gegen lokale `127.0.0.1`-Endpoints oder über VPN/SSH-Tunnel/geschützte Monitoring-Agenten. Keine generisch ungesicherten Public-RPC/Prometheus-Endpunkte; kein Remote-Exec/SSH-Root durch das Dashboard.
+- Trennung zwischen **Chain-beobachtbaren** Nodes/Mining-IDs und **maschinenbezogenen** Kennwerten, die nur Betreiber mit Opt-in teilen. Der Admin kann nicht alle VMs einer fremden Node automatisch erkennen oder steuern.
+- Kein Blockieren des Netzwerks durch Monitoring-Anfragen; Cache/Rate-Limits/Timeouts, Lese-only Konfig, keine privaten Walletdaten im Log. Statuszeitpunkte und Staleness transparent.
+
+## Sicherheits- und UX-Anforderungen
+
+- Hub-/Wallet-Endpunkte auf `127.0.0.1`, Zugriff im Entwicklungs-LXC via SSH-Forward; andere Hosts erst per explizit autorisiertem privatem Tunnel, HTTPS und Authentifizierung.
+- Browser-Wallet: verschlüsselte lokale Speicherung, signierte Ausgaben ohne Seed-Exfiltration, Backup/Recovery, nicht automatisch auf andere Hub-Browser kopieren.
+- Node-/Worker-Kopplung mit zeitlich begrenzter Einladung und gegenseitigem kryptografischem Besitznachweis, nicht nur Fingerprint. Getrennte Operator-/Wallet-/Mining-/Validator-Schlüssel.
+- Gebührenreserve und Nutzerlimit für unbeaufsichtigte Worker-Mining-Gebühren erst nach expliziter Autorisierung; read-only Admin kann nie Gebühren abbuchen.
+- Ein Hub darf mehrere Workerdatenansichten und mehrere **eigene** Hubs in seiner Clusteransicht zeigen, aber nicht die privaten Daten fremder Betreiber.
+
+## Akzeptanztests je Ausbaustufe
+
+- **UI vor Chain:** Beide Dashboards starten/anzeigen klar „nicht verbunden“, keine Fake-Daten.
+- **M2 erster Devnet-Kern:** echte Chain-ID, Höhe, Header/Blockstatus; Hub und Admin melden konsistente Werte; Wallet integriert echte Daten, sobald Signaturformat verfügbar.
+- **M3 Validatoren:** 1- und 4-Validator-Szenario; Down/Restart, Peer-Status, >2/3 Quorum, AppHash, Stale-Alerts; Admin aus => Chain läuft weiter.
+- **M4 Worker:** mehrere Mining-IDs, Worker-Pairing, Hub-/Worker-Mining, Freigaben/Budgets, Gebühren und Gewinne mit echten Chain-Daten.
+- **M5/M6:** Multi-Hub-Cluster UX und Mehrhost-Überwachung, Monitoring-Lücken, Recovery, Sicherheitsgrenzen.
+
+**Keine Produktivitätsbehauptung:** vorhandene `web/wallet` bleibt reine Vorschau. Noch keine Backend-Schnittstellen, GUI/DB/Chain/Minerdienste für die oben beschriebenen Funktionen implementiert.
+
+## Betreiberansichten und Identitätsverwaltung (ADR 0008)
+
+**Ab erstem funktionsfähigem Devnet:** Nur für den Projektbetreiber read-only Network Admin mit tatsächlichen Chain-/Validator-/Peerwerten. Anzeige für bestätigte Coin-Emission, aktuelles Supply, kumulierten Burn (0 für PoP-/Workergebühren), Fondsbestand/-Ein-/-Ausgänge, Gebührenparameter, Betreiber-/Mining-Registrierungsstatus, Freigaben/Widerrufe, beobachtbare Peers und PoP-Runden soweit schon implementiert. Jede Kennzahl enthält Chain-ID, Blockhöhe/Messzeit, Datenquelle und Stale-/Fehlerstatus. Für fehlenden Ledger/Registry-State **„nicht verfügbar“ statt Mockzahlen**.
+
+**Identitätsaktionen:** Anzeige und Filter von `operator_id`, `node_id`, `mining_id`, zugehöriger Reward-Adresse sowie Genehmigungs-, Sperr- und Auditstatus. **Einzige frühen Schreibaktionen:** Neue Betreiber-/Mining-IDs signiert freigeben, sperren/widerrufen (Key-Rotation später nach separater Spezifikation). Bis sichere Signatur-/Protokollfunktionen existieren: read-only, keine Scheinfreigaben. Der Admin-Webserver enthält keinen privaten Admin-Signaturschlüssel; getrennte CLI/Signaturkomponente mit 2-Stufen-Bestätigung, Replay-Schutz und On-chain-Finalisierung.
+
+**Aktive Nodes:** Die globale Gerätezahl ist nicht allein aus einem lokalen Peer-Set beweisbar. `registriert`, `kürzlich beobachtet`, `signiert meldend` und `PoP-aktiv` getrennt mit Datum/Abdeckung anzeigen. Optional signierte Heartbeats über *freiwilligen*, geschützten Monitoring-Empfänger; SQLite-Historie optional, keine zentrale Registrierungsdatenbank-Pflicht.
+
+**Vertraulichkeit:** Nur die Admin-GUI und eigene Off-chain-Telemetrie sind zugriffsbeschränkt. On-chain-Fonds, Gebühren und ggf. Registry-Informationen sind über Full Nodes prinzipiell abfragbar. Private Betreiber-Kontakte/Geräte-IP nicht auf replizierten Chain-State schreiben. [ADR 0008](decisions/0008-schlanker-netzzugang-admin-und-identitaeten.md), [Netzzugang](NETWORK_ZUGANG_UND_IDENTITAETEN.md).
@@ -51,7 +51,7 @@ Die abgelehnte Idee „Gebühr pro aktuellem Wallet-Guthaben“ lässt sich durc

 `Fenster 2 = Basisbetrag2 + Progressive(90-Tage-Ertrag)`; `Fenster 3 = Basisbetrag3 + stärkerer progressiver Anteil`. **Alle exakten Prozentsätze, Stufen, Beträge und Rundungsregeln sind offen**. Bei Erfolg in Fenster 1 oder 2 fallen spätere Gebühren nicht an; Zusatzgebühren im Misserfolgsfall werden nicht erstattet.

-**Zusatzgebühren werden verbrannt**, normale Überweisungsgebühren sollen die Validatoren finanzieren (Aufteilungsregeln noch offen). Mining funktioniert kostenlos mit 0 PTM über Fenster 1. Die Wallet gibt kostenpflichtige Fenster einzeln oder per eng begrenzter, widerrufbarer Autorisierung frei. Der Miner erhält niemals Browser-Wallet-Secrets.
+**PoP-Fenster-/Workergebühren gehen laut ADR 0007/0008 zu 100 % an den On-chain-Fonds, 0 % Burn dieser Kategorien**; normale Überweisungsgebühren und deren mögliche Validatorfinanzierung sind noch offen. Mining funktioniert kostenlos mit 0 PTM über Fenster 1. Die Wallet gibt kostenpflichtige Fenster einzeln oder per eng begrenzter, widerrufbarer Autorisierung frei. Der Miner erhält niemals Browser-Wallet-Secrets.

 ### Wichtige Grenzen

@@ -93,3 +93,19 @@ Ein sauberes Go-Gerüst und eine HTML-Oberfläche sind **noch keine nutzbare Blo
 Die im Oktober 2026 ergänzte Vision sieht **nach stabiler Kern-Chain und Web-Wallet** digitale Sammelobjekte (F1), einen in PTM abgewickelten internen Marktplatz (F2), eine Handelsoberfläche für fiktive interne Assets mit Orderbuch, Kursen, Charts und Portfolios (F3) und optional einen strikt getrennten Paper-Trading-Modus (F4) vor. Diese Szenarien sollen PTM einen internen Nutzwert geben. Sie begründen **keinen externen Euro-Kurs**, keine Börsenlistung und keine Anlage- oder Renditeaussage.

 Asset-Kauf, Sammelgegenstände oder Bestandshöhen dürfen die PoP-Lotterie nicht zusätzlich bevorteilen. Die technischen Details (Assetmodell, Emission, Marktdaten, atomare Trades, Ordermatching, Gebühren und Schutz gegen Wash Trading) sind absichtlich offen. Keine Funktionen sind implementiert. Maßgeblich: `docs/ZUKUNFT_OEKOSYSTEM.md`, `docs/ROADMAP.md` und ADR 0004. Die Arbeiten an M1–M6 behalten Vorrang.
+
+## Architekturergänzung v0.4: Hub, Worker, Cluster
+
+Potatium Hub ist die autonome Full-Node mit Client-Wallet, eigenem Mining und lokalem Cockpit. Ein Worker ist ein schlanker an den Hub gebundener Miner ohne eigenständiges Coin-Wallet. Eine Betreiber-Identität gruppiert diese Instanzen und deren Kosten/PoP-Gewinne, auch bei mehreren Hubs/Wallets. Es gibt einen kostenfreien Hub-Mining-Platz je Betreiber; zusätzliche genehmigte Mining-IDs zählen wirtschaftlich als Worker. Jeder zugelassene Miner max. ein Ticket je Runde. Worker-Gebühren zusätzlich zu PoP-Fenster-2/3 sind noch Forschungsmodell. Priorität Node-/Cluster-Cockpit, später separate Admin-WebGUI. Für Details sind `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md` und ADR 0005 maßgeblich.
+
+## Infrastruktur und Cockpits (Ergänzung v0.5)
+
+Die Betriebsrollen, Datenspeicherung und Deployment-Stufen werden in `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md` vollständig erklärt. Ab dem ersten funktionalen Devnet werden **beide lesenden Ansichten** umgesetzt: lokaler Potatium-Hub mit Wallet- und Node-Status sowie separater **Network Admin read-only** für Blockchain-/Validatorüberblick. Die administrative Schreibverwaltung kommt später. Begründung und Grenzen dokumentiert ADR 0006; UI-/Metrikkriterien stehen in `docs/COCKPITS_UND_MONITORING.md`. Kein zentraler Chain-Datenbankserver und keine Abhängigkeit der Blockchain vom Monitoring.
+
+## Netzwerkzugang und Betreiberverwaltung (aktueller ADR 0008)
+
+**Keine zentrale Benutzerplattform oder Pflichtregistrierung für den P2P-Sync.** Authentische Chain-ID, Genesis und CometBFT-Seed-/Persistent-Peers werden pro Node konfiguriert. Nur PoP-Mining erfordert autorisierte On-chain-Registry und operatorbezogene Gebühren-/Gewinnhistorie; Freigabe/Sperre im geschützten Network Admin über gesonderte signierte Aktionen. Der Network Admin ist ab erstem lauffähigem Devnet zunächst lesend mit echter Supply-/Burn-/Fonds-/Gebühren-/Registry-/Validatorübersicht, inaktiv markierten Freigabeaktionen bis zum vollständigen Signatur-Workflow. Optionales Monitoring-Inventar ist nicht konsenskritisch. Hub und Worker sind die beiden Teilnehmerpakete; Auszahlungs-Wallet-Schlüssel bleiben lokal im Browser. **100 % PoP-/Worker-Gebühren fließen in den On-chain-Fonds**, keine Burns dieser Gebühren. `docs/INSTALLATIONSPLAN_HOMELAB.md`, `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und ADR 0008 sind aktueller Stand.
+
+## Erkenntnisse der Dynamik-/Fonds-Simulation vom 25.10.2026
+
+36 Forschungsdurchläufe zeigen, dass dynamische Worker-Steuerung mit höheren Gebühren aktive große Cluster bremst, zugleich aber die Fondsbindung stark ansteigen kann: 3× dynamisch 40,59 % des erzeugten Supply, 5× fix 70,20 % bei gehaltenem Fonds. Die hypothetische Rückverteilung ist ohne Sybil-Schutz nicht als Governance-Beschluss geeignet. **Keine Workergebühr, Rundenlänge, Rewardhöhe oder Fonds-Auszahlung beschlossen.** Siehe `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md`.
@@ -0,0 +1,90 @@
+# Potatium Hub, Worker und Cluster: Architekturentwurf v0.4
+
+**Stand: 25.10.2026 | Produktentscheidung zum Paketmodell, Gebührenparameter weiterhin offen.**
+
+## Begriffe und zugesagte Eigenschaften
+
+| Objekt | Was es ist | Wallet / Schlüssel | Funktion |
+|---|---|---|---|
+| Betreiber / Operator (`operator_id`) | manuell genehmigte Berechtigungs- und Wirtschaftsgruppe | besitzt eine oder mehrere Wallet-Adressen, aber keine serverseitige Master-Seed-Verwahrung | gemeinsame 90-Tage-PoP-Gewinnhistorie und Gebührenbasis |
+| Hub (`hub_id`) | vollwertige Potatium-Node mit eigener kryptografischer Node-ID und eigenem lokalen Web-Cockpit | Wallet wird im Browser eingerichtet, signiert clientseitig; Hub-Backend hat **keinen** Seed/Private Key | Chain-/P2P-Teilnahme je Rolle, lokale UI/API, eigener optionaler PoP-Miner, Worker-Anbindung |
+| Worker (`worker_id`) | schlanke, an Hub gekoppelte Mining-Instanz, z.B. Raspberry Pi/VM/PC | eigener **Geräteschlüssel**, keine Geld-Wallet, keine Wallet-Seeds | Challenge prüfen, begrenzte PoW-Arbeit, Proof signieren und via Hub fristgerecht einreichen |
+| Validator (`validator_id`) | CometBFT-Konsensrolle | separater Validator-Schlüssel, kein Wallet-Key | Blockchain-Blöcke finalisieren, PoP-Lose nicht auswählen/produzieren |
+| Auszahlungsadresse | explizit am Operator registrierte Wallet-Adresse | Private Key im Wallet-Client | empfangene PoP-Belohnungen aus Hub und Workern |
+
+Ein physischer Host kann mehrere Prozesse/Instanzen mit isolierter Konfiguration, Ports, Datenverzeichnissen und eigenen Schlüsseln betreiben. Das bedeutet **nicht** mehrere automatisch zugelassene Mining-Lose: nur ausdrücklich registrierte Mining-IDs zählen. Eine Node-ID beweist keine eigene Hardware und ein Operator-ID-Eintrag keine einzigartige natürliche Person.
+
+## Zwei Distributionspakete, drei Oberflächen
+
+1. **Potatium Hub**: autonome, vollständige Node mit Web-Wallet-Bedienung, Explorer, eigener Mining-Funktion, lokaler Status- und Worker-/Cluster-Ansicht. Ist ohne Worker funktionsfähig. Ein Hub ist nicht zwingend Validator.
+2. **Potatium Worker**: separater ressourcensparsamer Mining-Agent ohne vollständigen Chain-State und ohne eigenständige Geld-Wallet. Über einen Hub kontrollierbar. Ohne erreichbaren Hub kann er keine rechtzeitige Proof-Übermittlung garantieren. Lokale Setup-/Diagnoseoberfläche optional, aber kein vollständiger Node-Hub.
+3. **Potatium Admin**: spätere Betreiberverwaltung (vorerst CLI), streng getrennt von normaler Hub-/Clusterverwaltung. Admin-Tool ist **kein** drittes Mining-Paket und nicht zum willkürlichen Ändern von Guthaben befugt.
+
+```text
+                  Betreiber / operator_id [Registry]
+                      |       Wallet im Browser
+                      |       Auszahlung an registrierte Adresse
+                Potatium Hub (autonom)
+               Node/Explorer/Wallet/Mining
+                  /       |         \
+            Worker A  Worker B  Worker C
+             Gerät-ID  Gerät-ID  Gerät-ID
+
+    P2P/ABCI++ der Full-/Validator-Nodes bleibt getrennt
+       vom Hub-Worker-Mining-Kontrollkanal.
+```
+
+### Kopplung und lokale GUI
+
+- Hub-GUI zunächst ausschließlich `127.0.0.1:<port>` und SSH-Portforwarding; mehrere lokale Hub-Instanzen nutzen getrennte Ports und Datapaths. Später private HTTPS/VPN-Zugänge mit Login; **keine** öffentliche Admin-/RPC-Bind-Adresse per Default.
+- Worker-Kopplung mit **kurzlebigem, einmaligem Enrollment-Token oder signierter Einladung**, QR-Code für Komfort und anschließend gegenseitiger kryptografischer Authentifizierung. **Ein Fingerprint allein ist keine Autorisierung**.
+- Hub prüft Registrierungsstatus, Worker-Identität, Challenge/Runde/Fenster, Signatur, Zeitfenster, Nonce-Space und Duplikate vor Weiterleitung; die ABCI++-Anwendung muss dieselben Regeln unabhängig im Konsens durchsetzen.
+- Worker kann unter Freigabe widerrufen oder zwischen Hubs desselben Betreibers umgezogen werden; identischer `worker_id` darf in derselben Runde nicht mehrfach abrechnen/teilnehmen.
+- Hub-Ausfall: Worker-Status klar als nicht erreichbar/offline kennzeichnen, keine erfundenen Proofs/Gewinne. Backup-Hub und Failover sind spätere Funktionen und dürfen Tickets nicht duplizieren.
+- Hub-Cluster-Dashboard verwaltet **eigene** authentifizierte Hubs und Worker; es hat keine Berechtigung, fremde Betreiber zu administrieren. Kein automatisches Wallet-Key-Sharing oder API-Server mit Seed-Phrase.
+
+## Mining-Teilnahme und gemeinsame Ökonomie
+
+- **Jede genehmigte Mining-Instanz**, auch ein Hub mit aktivierter PoP-Rolle, kann **maximal ein Ticket pro PoP-Gesamtrunde** erhalten; die bestehende 3-Fenster-Logik gilt für jede Instanz.
+- Beim Betreiber werden **alle** PoP-Gewinne seiner Mining-IDs während des später exakt spezifizierten ~90-Tage-Zeitraums zusammengeführt. Wallet-Transfers, Wechsel der Auszahlungsadresse und Worker-Umzug setzen den Fortschritt nicht zurück.
+- **Ein kostenloser Hub-Mining-Platz pro Operator** ist die Arbeitsregel des Konzepts. Dieser Hub wird nicht in die Worker-Gebühr eingerechnet; er unterliegt trotzdem den normalen Fenster-2-/Fenster-3-Gebühren.
+- Weitere physische Hubs dürfen technisch betrieben werden (z.B. Ausfallsicherheit). Sie erzeugen **keinen zweiten kostenlosen Hub-Mining-Platz**. Zusätzliche Mining-Identitäten gelten bei Kosten/Quoten wie Worker-Instanzen; eine bloße GUI-/Full-Node-Instanz ohne Mining zählt nicht.
+- Sämtliche vom Operator zugelassenen Worker müssen in der verbindlichen Chain-Registry diesem Betreiber zugerechnet werden. **Mehrere Hubs/Walletts dürfen keine getrennten kostenlosen Betreiberidentitäten simulieren.** Beim kleinen privaten Netzwerk zunächst manuelle Betreiberzulassung und Audit; kryptografische Verhinderung von Sybil-Angriffen ist damit nicht erreicht.
+- Die registrierte Auszahlungsadresse erhält sämtliche Hub-/Worker-Mining-Belohnungen des Betreibers. Eine spätere Änderung braucht signierte, replay-geschützte Autorisierung und eindeutige Wirksamkeitsgrenze. Zusätzliche Wallets für normale Transfers sind möglich, verändern aber Mining-Fee- und Betreiber-Identität nicht.
+
+### Zahlungsautorisierung ohne Wallet-Seeds auf Nodes
+
+Mininggebühren (zusätzliche Fenster und eventuell Worker-Aktivierung) sind aus demselben **Betreiber-Budget** zu bezahlen. Eine dauerhaft online erforderliche Freigabe ist nicht praktikabel, wenn die Seed/Private Keys ausschließlich im Browser liegen. **Vorgeschlagene** Lösung: zweckgebundene, on-chain verbuchte Mining-Gebührenreserve je Operator. Befüllung/Rückzahlung signiert die Browser-Wallet; die deterministische App darf daraus ausschließlich die ausdrücklich begrenzten, berechenbaren Mining- und Worker-Gebühren belasten. Zusätzlich: Zeit-/Betragsobergrenzen, Sperrung/Widerruf, Audit und sichere Restguthaben-Rückgabe. Noch keine Implementierungsentscheidung; ein alternatives begrenztes signiertes Mandat ist möglich. Niemals Miner-/Node-/Worker-Schlüssel zu Wallet-Spend-Keys machen.
+
+## Operatives Cockpit vor Admin-Web
+
+**Hub lokal:** Blockhöhe, Sync, Peers, Versions- und Ressourcenstatus, Wallet-Verbindung, PoP-Runde/Fenster/Tickets/Gewinne, Gebührenhistorie/Budget, Worker-Anmeldung/Freigabe/Pause, pro Worker CPU-/Fensterlimit, Fehler, einzelne Daten des eigenen Clusters.
+
+**Cluster-Sicht:** mehrere zugeordnete Hubs/Worker in einer Übersicht mit Host-Status, Versionen, Mining-Modus, zentraler (aber begrenzter) Einstellungs-/Update-Orchestrierung; keine zentralen Wallet-Seeds und keine direkte Chain-State-Manipulation. Der eigenständige Hub bleibt immer einzeln bedienbar; Cluster-Sicht ist optional.
+
+**Admin (später):** separate authentifizierte Betreiber-/Validator-/Miner-Registry, Revocation, Audit, koordinierte Upgrades, Netzwerkdiagnose. Zunächst sichere CLI ab dem Zeitpunkt, an dem diese Funktionen benötigt werden.
+
+## Kostenmodell und Sicherheitslücken
+
+Siehe [`WORKER_GEBUEHREN_FORSCHUNG.md`](WORKER_GEBUEHREN_FORSCHUNG.md). **Keine finalen Beträge**. Für Worker-Aktivierungen ist Zahlung/Reservierung vor der unbekannten Challenge notwendig; sonst können schnelle Geräte nur erfolgreiche Versuche bezahlen. Keine Kosten für Worker, die gar nicht zur Runde angemeldet wurden. Festlegen, wie verpasste Runden, Downtime, Replay und Wiederanmeldung bilanziert werden.
+
+## Akzeptanzkriterien vor Implementierung
+
+- Eigenständiger Hub funktioniert ohne Worker, Worker funktioniert nur gekoppelt; getrennte Keys/Rollen, keine Seeds auf Server.
+- Zwei Worker mit eigenen ID-Schlüsseln lassen sich koppeln, sperren und eindeutig demselben Betreiber zuordnen.
+- Pro ID/Runde höchstens ein gültiges Ticket, unabhängig von parallelen Prozessen/Hubs; Hub selbst als Mining-ID zählt.
+- Gebühren/Rewards aggregieren **operator_id**, nicht Wallet-Adresse oder `hub_id`; Identitäts-/Wallet-Wechsel resetten keine Progression.
+- Zusätzlicher Hub verschafft keinen zweiten kostenlosen Slot; Registry ist manuell und auditierbar.
+- Zahlungssnapshot vor dem jeweiligen Challenge-Seed; verspätete und doppelte Aktivierungen abweisen.
+- Funktionsfähige UI erst bei realer API; weder Mock-Balance noch Fake-Tickets als echt anzeigen.
+- Deployment native `linux/amd64` / `linux/arm64` zuerst, Docker **später optional**, kein Docker im Entwicklungs-LXC.
+
+**Status:** Dieses Dokument spezifiziert eine angestrebte Produktarchitektur. Kein Teil davon ist als bereits funktionierend zu betrachten.
+
+## Ergänzung v0.5: Abgrenzung zum Netzwerk-Admin
+
+Der **Teilnehmer-Cluster** in einem Hub verwaltet ausschließlich die eigenen authentifizierten Hubs/Worker und verbindet niemals fremde Wallet-Private-Keys. **Potatium Network Admin** ist dagegen eine separate, von Projektbeginn geplante **read-only** Beobachtung des gesamten erreichbaren Chain-/Validatornetzes mit optional freigegebenen Node-Metriken. Er hat keine Workersteuerung fremder Betreiber, keine zentralen Blockchain-Schreibrechte und ist **keine** zusätzliche Chain-Infrastruktur, deren Ausfall Blöcke stoppt. Validatorbetrieb wird anfangs vom Projektbetreiber bereitgestellt. Technische Einzelheiten: `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`, ADR 0006.
+
+## Netzwerkzugang und Betreiberrechte (aktueller ADR 0008)
+
+Hubs benötigen zum P2P-Sync kein Benutzerkonto und keinen Pflichtdienst `potatium-network`; die lokale Konfiguration enthält überprüfte Chain-ID/Genesis und Seed-/Peer-Adressen. Eine **separat autorisierte On-chain-Registry** bestimmt, welche Betreiber-/Hub-/Worker-Mining-IDs Tickets einreichen dürfen. Betreiber können mehrere Hubs/Worker und eine gemeinsame Reward-Adresse besitzen. Weitere miningfähige Hubs zählen wirtschaftlich als zusätzliche Worker, nicht als neue kostenlose Betreiberplätze; Sybil-Limit nur durch nachvollziehbare manuelle Freigabe. Im Hub werden eigene Cluster- und Wallet-Daten gezeigt, im Network Admin globale Registry-/Supply-/Fonds-/Validatorübersicht. Identitätsfreigabe/-sperre: geschützte Admin-Signatur, on-chain finalisiert; keine zentralen DB-Flags. Gebühren: 100 % On-chain-Fonds, keine PoP-Burns. Siehe ADR 0008 und `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md`.
@@ -0,0 +1,127 @@
+# Potatium: Gesamtinfrastruktur, Datenhaltung und Deployment
+
+**Status: akzeptierte Ziel- und Betriebsarchitektur, nicht implementiert. Stand: 25.10.2026.** Siehe ADR 0006. Der tatsächliche Git-Stand hat Vorrang. Die konkreten CometBFT-Versionen, Datenbank, Ports, Service-Prozesse und API-Schemata sind erst bei der Implementierung verbindlich festzulegen. Alle hier genannten Namen für Deployments und Adressen sind Beispiele, keine bereits laufenden Dienste.
+
+## Grundsatz: Kein zentraler Blockchain-Master
+
+Eine funktionierende Chain erfordert aktive CometBFT-Validatoren und die eigene deterministische Potatium-ABCI++-Anwendung. Jeder Full-/Validator-Node verwaltet lokal eine eigene konsistente Kopie der Chain beziehungsweise des Anwendungszustands. **Keine gemeinsame SQL-Datenbank, kein zentraler Coin-Server, kein Admin-Cockpit als Konsensabhängigkeit.**
+
+```text
+                 Devnet / privates Testnet / dauerhaftes Netz (getrennte Chain-IDs)
+        +--------------------------------------------------------------+
+        | VAL-1       VAL-2        VAL-3        VAL-4                   |
+        | CometBFT + Potatium-App + je eigener lokaler State            |
+        | signieren und finalisieren Blöcke per Konsens                 |
+        +-----------------------------+--------------------------------+
+                                      | authentisches P2P/Chain-Protokoll
+                  +-------------------+-------------------+
+                  |                                       |
+          HUB Betreiber A                          HUB Betreiber B
+          Full Node + API + lokale WebGUI         Full Node + API + WebGUI
+          optional PoP-Miner                      optional PoP-Miner
+          Wallet-Signatur NUR im Browser          Wallet-Signatur NUR im Browser
+             |      |                                   |
+          Worker A1 Worker A2                      Worker B1
+          eigener Mining-Key, keine Full-Chain, keine Wallet-Keys
+                  \\                                      //
+             Read-only Network Admin (geschuetztes Monitoring)
+             liest gesicherte Messwerte / Chainabfragen; keine Coins
+             optional eigene Messdatenbank, NICHT Konsens-State
+```
+
+Die logische Hub-Worker-Kopplung ist **nicht** das CometBFT-P2P-Netz. Ein Hub ist eine Full Node und kann optional die Validatorrolle besitzen, aber ein normaler Worker ist weder Validator noch Full Node. Ein Betreiber kann mehrere Hubs kontrollieren; ein Hub kann ohne Worker laufen. Dasselbe physische Gerät kann technisch mehrere sauber getrennte Prozesse ausführen, ohne neue Hardwareidentitäten zu beweisen.
+
+## Rollen, Prozesse und Eigentum
+
+| Rolle | Betreibt wer? | Binär-/Dienstkonzept | Lokale Daten | Muss online sein? |
+|---|---|---|---|---|
+| Dev-Host | Projektbetreiber | Git, Go, Tests, Devnet-Prozesse | Quellcode und *separate* Test-Chains | Nur zur Entwicklung |
+| Validator | Anfangs Projektbetreiber, später mögliche genehmigte Mitbetreiber | CometBFT + `potatiumd`-ABCI++-App | eigene Chain- und App-Daten, sensibler Konsensschlüssel | Für Blockproduktion benötigt: >2/3 Stimmmacht aktiv |
+| Hub | jeweiliger Potatium-Betreiber | CometBFT als Nichtvalidator + Potatium-Go-App/API + WebGUI + optional lokaler Miner | eigene kopierte Chain, App-State, Node-Key und lokale Hub-Config | Für eigene Wallet-Abfragen/Worker-Mining erreichbar |
+| Worker | jeweiliger Betreiber | schlanker `potatium-miner`-Agent, dem Hub zugeordnet | Mining-Geräteschlüssel und sichere lokale Einstellungen, **keine Chain-DB/Spend-Keys** | Nur bei Teilnahme |
+| Wallet | Benutzer im Browser, unabhängig von Node-Persistenz | Web-Wallet | verschlüsselte clientseitige Schlüssel, Backups in Verantwortung des Benutzers | Nein |
+| Network Admin (read-only) | zunächst allein Projektbetreiber | kleines Go-Observability-Backend + Browser-Ansicht; genaue Verpackung offen | Monitoring-Inventar, optionale Historie/Cache | **Nein, ohne Admin läuft Chain weiter** |
+| Registry-Admin (später) | berechtigter Betreiber | geschützte CLI / später getrennte Web-Admin-Aktionen | Admin-Autorisierungsnachweise, Audit | Nur für Verwaltungsänderungen |
+
+**Sicherheitsgrenzen:** `node_id`/P2P-Key, Validator-Consensus-Key, `operator_id` + Operator-Verwaltungsschlüssel, `mining_id`/Worker-Key sowie Wallet-Spend-Key sind unterschiedliche Rollen. Ein Fingerprint identifiziert einen öffentlichen Schlüssel, erteilt allein keine Berechtigung. Validatoren und Monitoring erhalten keine Wallet-Seeds. Mehrere Wallet-Adressen sind möglich, aber verändern die `operator_id`-Mining-Historie nicht. Reward-Auszahlungsadresse ist an die registrierte Betreiberidentität gebunden; Schlüssel für Wallet-Transaktionen bleiben im Browser.
+
+## Was läuft wo?
+
+### Stufe 0: Entwicklung und erster Devnet-Start
+
+- Bestehender Host: Proxmox, unprivilegierter Ubuntu-26.04-LXC `potatium-dev`, 4 vCPU / 4 GB RAM / 40 GB als **Startgröße**. IDE bleibt lokal via Remote-SSH. Kein Docker-in-LXC, keine Server-GUI installieren.
+- Repository: `/home/potatium/src/potatium`. Daten gehören **außerhalb von Git**, z. B. `/home/potatium/.local/share/potatium/devnet/` für zukünftige Devnet-States. Pfad ist ein *Vorschlag*, noch nicht implementiert.
+- Erst ein Validatorprozess + zugehörige Potatium-ABCI-App für den ersten echten Konsens-Test. Separat ein Hub/API/Wallet und **vom Beginn des Devnets an** Network Admin read-only; auf demselben LXC nur soweit Ressourcen reichen, Prozesse und Ports klar getrennt.
+- Beim allerersten UI-Gerüst ohne laufende Chain: ehrliche „nicht verbunden / keine echten Daten“-Anzeige, keine Mock-Balance oder erfundenen Blöcke.
+- Devnet darf nach explizitem Backup/Bestätigung zurückgesetzt werden. Ausschließlich wertlose Test-PTM, eigene Chain-ID und Genesis.
+
+### Stufe 1: Realistisches lokales Testnetz
+
+- Vier logisch getrennte Validatoren mit eigenen Datenverzeichnissen und Konsensschlüsseln. Initial dürfen sie zu Testzwecken auf einem Host/mehreren VMs laufen, **nicht als echte physische Redundanz ausgeben**.
+- Hub als eigener Full-Node-Prozess (kein Validator erforderlich), Worker auf separatem Pi/Alt-PC; echtes Peer- und API-Verhalten testen.
+- Network Admin zeigt alle vier Validatoren, Höhen-Abweichung, letzte Finalisierung, Peer-Verbindungen, Versionen, Block-/Tx-Rate, App-Hash-Abgleich und Ausfälle. Unbekanntes/Offline getrennt anzeigen.
+- Test-Coins über Devnet-Genesis, später begrenztes Faucet, niemals als „echte PTM“ ausgeben.
+
+### Stufe 2: Mehrhost-Privat-Testnet
+
+- Vier Validatoren auf **verschiedenen Ausfall-Domänen**, idealerweise getrennten Hosts (VMs können praktikable Betriebsform sein; nicht alle auf demselben Proxmox-Host). Zunächst betreibst du sie, später optional andere vertrauenswürdige Teilnehmer. Operator-Hubs laufen auf eigenen VMs/PCs; Worker nativ auf Pi/Alt-PC.
+- Read-only Network Admin kann auf separater kleiner Management-VM laufen. Für ein kleines Netz optional mit lokaler persistenter SQLite-Kennwert-Historie oder nur In-Memory; Datenbanktyp noch offen. **Kein** zusätzliches zentrales Chain-Backend.
+- Netzwerkzugriff über private, authentifizierte Verbindungen; keine öffentlichen Admin-, CometBFT-RPC-, ABCI- oder Metrics-Ports. P2P-Peers nur gezielt freischalten. Monitoring remote vorzugsweise über kontrollierte Read-only APIs/privates VPN oder Push-Metriken, nie mit pauschalen Betriebssystem-Root-Zugängen.
+
+### Stufe 3: Dauerhaftes privates Potatium-Netz
+
+- Neue eigene Chain-ID/Genesis, dauerhafte State-Daten, dokumentierte Validator- und Backup-Strategie. Devnet und Testnet bleiben getrennt. **Keine automatische Migration/Einlösung der Test-PTM**.
+- Der Network Admin bleibt nur Beobachter. Registry-/Validator-Änderungen erfordern gesondert definierte, signierte Autorisierung und Konsensverarbeitung; nie freie SQL-Updates gegen den Ledger.
+- Native `linux/amd64` und `linux/arm64` zuerst. Docker/Compose als **optionale spätere Deployment-Form** für Hub/Worker/Admin, nicht als Pflicht und nicht innerhalb des Entwicklungs-LXC.
+
+## Datenspeicherung: Wo ist die Datenbank?
+
+1. **CometBFT-Speicher jeder Full Node:** Blöcke, Konsens-/Peer- und Indexdaten je nach Konfiguration. Unabhängig pro Instanz.
+2. **Potatium-App-State jeder Full Node:** Konten/Nonces, Genesis, `operator_id`-/`mining_id`-Registry, Runden, Gebühren-Snapshots, Tickets, Mint/Burn-/spätere Gebührenverteilung, signaturgeschützte Status-Änderungen; deterministischer State-Hash. Eingebetteter KV-Speicher wird erst nach Vergleich (z. B. bbolt vs. Pebble) und ADR gewählt.
+3. **Wallet im Browser:** verschlüsseltes lokales Key-Material, lokal signierte Transaktionen; keine Spend-Keys in 1, 2 oder Network Admin. Ein Wallet kann mehrere Hubs beobachten, aber privater Schlüssel ist nicht automatisch über Geräte/Browsersessions synchronisiert.
+4. **Monitoring-Speicher:** optionaler Index/Cache/Time-Series für Metriken, Events, Node-Inventar, Alarmhistorie. Autorität ist immer die Blockchain und die echte Node-API, niemals der Monitoring-Cache.
+5. **Worker-Speicher:** Geräteidentität, Hub-Kopplung, sichere Retry-/Diagnosezustände; keine vollständige Blockchain, keine Finanz-Wallet.
+
+`bbolt`, `Pebble`, `SQLite`, `Prometheus` sind **Kandidaten**, nicht ausgewählte produktive Implementierungen. Die Anwendungs-DB muss crash-/restart-sicher, atomar und zur ABCI++-Commit-Semantik passend sein. Keine Float-Mengen in Konsenszustand.
+
+## Netzwerkkonnektivität und Beispiele
+
+| Kommunikationsweg | Zweck | Sicherheitsregel |
+|---|---|---|
+| Validator ↔ Validator | P2P, Block-/Konsensnachrichten | gezielte authentifizierte Peers; keine offen zugänglichen RPCs |
+| Hub ↔ Validator/Peer | P2P, State-Sync, Transaktionsverbreitung | Full Node verarbeitet eigene Chainkopie |
+| Wallet-Browser ↔ Hub-API | Status, Wallet-Lesen, signierte Transaktionen | Browser signiert; API erhält niemals Private Key/Seed |
+| Worker ↔ Hub | Challenges, Proofs, Status, Workersteuerung | signierter Worker-Key + kurzlebige Kopplung, privater Transport |
+| Network Admin ↔ autorisierte Nodes | Beobachtung von Status und Metriken | read-only, explizit freigegebene Daten; Ausfall darf Konsens nicht stoppen |
+| Betreiber Admin-CLI → Chain | später Registry-/Validator-Änderungen | getrennte autorisierte signierte On-chain-Aktionen |
+
+**Ports sind Konfigurationsdetails, nicht Identitäten.** Auf einem Host werden Prozessports und Datenverzeichnisse getrennt; Initialbetrieb bindet Management-RPCs und Cockpit an `127.0.0.1`, Zugriff per SSH-Forwarding. Echte verteilte Hosts benötigen private, authentifizierte Verbindungen und einen gezielten Firewall-Plan. Portwerte bei Implementierung mit konkreten CometBFT-Versionen dokumentieren.
+
+## Was passiert bei Ausfällen?
+
+- **Network Admin offline:** nur Monitoring weg, Chain arbeitet unverändert weiter.
+- **Hub offline:** zugeordnete Worker können nicht zuverlässig melden; Wallet kann zu einem anderen vertrauenswürdigen Full-Node-Endpunkt wechseln, sofern verfügbar; keine automatischen Schlüsseltransfers. Multi-Hub-Failover für Worker bleibt offen.
+- **Worker offline:** nur dessen Mining-Beitrag entfällt, keine Auswirkung auf Blockkonsens.
+- **Validator offline:** bei 4 gleich gewichteten Validatoren toleriert die Chain einen Ausfall, bei zwei ist der notwendige >2/3-Konsens nicht erreichbar.
+- **App-State beschädigt/abgehängt:** lokale Nodes neu synchronisieren oder verifizierte Backups/Snapshots wiederherstellen. Dafür vor echtem Einsatz Restore-Test und keine gemeinsame DB als „Single Point of Failure“.
+
+## Testbare Mindestkriterien
+
+- Devnet mit einer echten Validator-Instanz, bestätigtem AppHash und realem Blockfortschritt; Hub zeigt dieselbe Höhe, Network Admin bestätigt sie lesend.
+- Leere/ungültige Chain-Verbindung in beiden Cockpits klar gekennzeichnet, niemals Mockwerte als Echtgeld/Testcoin-Bestände.
+- Vier Validatoren: einer offline => weitere Finalisierung (mit genügend Stimmgewicht); zwei offline => keine Finalisierung; Neustart / App-Hash-Vergleich.
+- Wallet/Hub/Worker/Admin sind getrennte Sicherheitsdomänen; Schlüssel- und Datentrennung mit Negativtests belegen.
+- Admin-Dienst kann abgestellt werden, ohne Konsens oder Wallet-Signaturpfad zu verändern.
+- Keine persistente zentrale Datenbankabhängigkeit für Blockchain-Fortschritt; Snapshot-/Backup-Restore reproduzierbar.
+
+## Offene Entscheidungen
+
+CometBFT-/Go-Version und Prozessintegration, konkrete Embedded-DB, Genesis/Chain-ID-Regeln, DB-Transaktions-/ABCI-Commit-Grenze, Validator-Anzahl und Stimmmacht im Dauernetz, Konsensschlüsselverwahrung, Monitoring-Stack, Datenaufbewahrung, API-Scope/Transport, öffentliche Knoten-Erreichbarkeit, Statusmetriken, Alert-Regeln, Gebührenempfänger und Coin-Emission. **Gebührenempfänger für PoP-/Worker-Gebühren ist durch ADR 0007 auf 100 % On-chain-Fonds festgelegt. Normale Transaktionsgebühren und Fonds-Auszahlungen sind noch offen.**
+
+## Korrigierte Betriebsentscheidung (ADR 0008): Zentral nur die Beobachtung, wenn gewünscht
+
+**Kein verpflichtender zentraler Registrierungs-/Bootstrap-Service `potatium-network`.** Der Projektbetreiber deployt zunächst ausschließlich den bestehenden `potatium-dev`-LXC, darauf getrennte Devnet-Prozesse (CometBFT+App, synchronisierender Hub, read-only Network Admin), sobald die Implementierung existiert. Hubs nutzen lokale Chain-ID-/Genesis-/Peer-Vertrauensanker; P2P-Discovery und unabhängige Validatoren bilden die Chain. Eine signierte On-chain-Registry steuert Mining-Rechte. Optionaler Telemetrie-/Admin-History-Store ist kein Ledger/Registrierungs-Master und braucht keinen separaten SQL-Server. Sobald tatsächliche Multi-Host-Tests starten, vier Validatoren auf getrennten Hosts/VMs (physische Ausfalldomänen beachten); ein optionaler eigener `ptm-admin`-LXC ist später reine Betreiberbequemlichkeit.
+
+**Freigabe/Sperre** als einzige frühe schreibende Admin-Aktionen sind gegen validierte Registry-Regeln zu signieren und on-chain zu finalisieren, nicht per SQL/GUI direkt. **100 % der PoP-Fenster-/Worker-Gebühren gehen an den On-chain-Fonds**, 0 % Burn; Fonds-Ausgabeordnung weiterhin offen.
+
+Ausführlicher Plan: `docs/INSTALLATIONSPLAN_HOMELAB.md`; Netzwerkzugang: `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md`; Entscheidung: ADR 0008.
@@ -0,0 +1,150 @@
+# Potatium | Infrastrukturplan für das Homelab
+
+**Stand:** 25.10.2026  
+**Status:** Architektur- und Installationsplanung, keine Deployments nachgewiesen.  
+**Repository:** Ab Dokumentationsstand v0.6: aktueller Infrastrukturentwurf nach ADR 0008. Keine Deployments außerhalb des Entwicklungsgerüsts nachgewiesen; Ressourcen und Namen sind Planwerte.
+
+## 1. Zielbild
+
+Potatium besteht aus unabhängigen Validatoren und Full Nodes mit lokaler Blockchain-/Anwendungsdatenhaltung sowie optionalen Mining-Workern. Teilnehmer benötigen keine zentralen Konten, um die Blockchain zu synchronisieren. Für **Proof of Potato** ist jedoch eine **on-chain verwaltete Betreiber-/Mining-Registry** mit autorisierter Freigabe und Sperrung vorgesehen.
+
+```text
+                        POTATIUM-NETZWERK (privates Testnet)
+                +---------------------------------------------+
+                |  Validator 1   Validator 2                   |
+                |  Validator 3   Validator 4                   |
+                |  CometBFT + potatiumd/ABCI++ je Validator    |
+                |  Jeweils eigene Chain-DB, App-State und Keys |
+                +---------------------+-----------------------+
+                                      | P2P
+                 +--------------------+--------------------+
+                 |                                         |
+      Betreiber A: Hub A                       Betreiber B: Hub B
+      Full Node + WebGUI                       Full Node + WebGUI
+      lokale Wallet-Signatur im Browser        lokale Wallet-Signatur im Browser
+      eigener Miner optional                  eigener Miner optional
+           |         |                                 |
+       Worker 1   Worker 2                          Worker 3
+       PoP-Agent   PoP-Agent                        PoP-Agent
+
+      Netzwerk-Admin des Projektbetreibers:
+      liest Chain/Registry/Fonds/Protokollparameter, beobachtet Netz-Metriken;
+      genehmigt/sperrt Mining-Identitäten über gesondert autorisierte,
+      finalisierte On-chain-Aktionen (erst wenn Registry/Signatur existieren).
+      Admin-Ausfall stoppt nicht die Chain.
+```
+
+**Festgelegt:** Der Hub besitzt eine technische Node-Identität und bietet eine Wallet-Anbindung. Der private Wallet-Schlüssel verbleibt browserseitig und wird nicht an den Hub-/Admin-Server oder Worker übertragen. Ein Betreiber kann mehrere Hubs und Worker haben, mit einer gemeinsamen registrierten Reward-Adresse. Jeder zugelassene Hub-Miner/Worker kann ein eigenes PoP-Los pro Runde qualifizieren; Gebühren und 90-Tage-Mining-Historie werden pro Betreiber aggregiert. Ein Betreiber erhält höchstens einen kostenlos gezählten Hub-Mining-Platz, sofern das spätere Gebührenprotokoll diese Forschungsentscheidung formal übernimmt. Konkrete Gebühren und Obergrenzen sind **noch offen**.
+
+**Gebührenentscheidung:** 100 % der PoP-Fenster-/Worker-Gebühren werden auf einen On-chain-Community-Fonds gebucht, 0 % Burn dieser Gebührenarten. Normale Transaktionsgebühren und Fonds-Ausgaberegeln sind offen. `fund_balance` wird nicht zusätzlich zum Umlauf addiert.
+
+## 2. Maschinen und Ressourcen
+
+| Name/Rolle | Deploymentort | Initiales Ressourcenbudget (Schätz-/Planwert) | Software/Dienst | Daten |
+|---|---|---|---|---|
+| `potatium-dev` | Bestehender Proxmox-LXC Ubuntu 26.04, unprivilegiert | **Bereits geplante Basis:** 4 vCPU / 4 GB RAM / 40 GB | Git, Go, VS Code Remote-SSH, Test-/Simulationsskripte | Quellcode unter `/home/potatium/src/potatium`; Simulationen/Testdaten getrennt |
+| `ptm-devnet` | Anfangs weitere Prozesse im `potatium-dev`-LXC | Bestehende Ressourcen, bei Druck erweitern | 1× CometBFT + 1× Potatium-ABCI-App | eigene Test-Genesis, Chain-State, Konsensschlüssel |
+| `ptm-hub-test` | Anfangs separater Prozess im `potatium-dev`-LXC | Kein zusätzlicher LXC erforderlich, Ressourcen messen | Full Node (Nichtvalidator), Potatium-API, Hub-WebGUI, Wallet-Frontend | eigene Chain-/App-Daten; Wallet-Key nur clientseitig |
+| `ptm-admin` | Anfangs eigener Prozess im Dev-LXC; später **separater Management-LXC** | Später als Startbudget etwa 1–2 vCPU / 1–2 GB RAM / 10–20 GB, zu messen | Network-Admin-Web + lesende Datenerfassung; später autorisierte Registry-Freigaben | optional SQLite nur für Monitoring-/Audit-Historie, **kein** Ledger |
+| `ptm-val01` bis `ptm-val04` | Für frühe Tests getrennte Prozesse/VMs; später verschiedene physische Ausfallbereiche | **Pro Validator als Planwert:** ca. 2 vCPU / 2–4 GB RAM / 30–60 GB, erst Benchmarks entscheiden | CometBFT + `potatiumd`-ABCI-App | jeweils eigene Chain-DB, State, Node-/Konsensschlüssel |
+| `ptm-hub-*` | Teilnehmer-VM, Pi oder alter PC | Pi 4 als Mindestziel; konkrete Messwerte offen | Full Node + WebGUI + optional lokaler Miner | eigene Chainkopie, Node-ID, Konfiguration |
+| `ptm-worker-*` | RPi/Alt-PC/VM | leichtgewichtig; Budget erst durch echte PoP-Benchmarks | `potatium-miner` und Hub-Verbindungsconfig | nur Geräte-ID, Mining-/Pairing-Konfiguration, **keine** Chain-DB oder Wallet-Spend-Keys |
+
+**Ressourcen sind nicht als gemessene Mindestanforderungen auszugeben.** Für vier Validatoren auf einem einzelnen physischen Proxmox-Host gibt es **keine physische Redundanz**. Für einen realistischen Ausfalltest Validatoren auf getrennte physische Hosts/Standorte verteilen. CometBFT kann mit vier gleichgewichteten Validatoren einen ausgefallenen Validator tolerieren; bei zwei Ausfällen ist kein >2/3-Quorum mehr vorhanden.
+
+## 3. Komponenten je Installationspaket
+
+| Paket/Rolle | Enthält | Ohne das Paket möglich? |
+|---|---|---|
+| Hub | CometBFT-Full-Node + Potatium-App-/API, Hub-WebGUI, Browser-Wallet, optional lokaler PoP-Miner | Worker braucht seinen Hub; Hub benötigt keinen Worker |
+| Worker | PoP-Rechenagent, eigener Mining-Key, Pairing/Status | Kein vollständiger Chain-Speicher, keine Auszahlung-Wallet |
+| Validator | CometBFT mit Konsensschlüssel + Potatium-ABCI-App | Netzwerk benötigt ausreichend aktive Validatoren für neue Blöcke |
+| Network Admin | Chain-/Fonds-/Parameterübersicht, Registry-Detailansicht, Netzdiagnose; später signierte Freigaben/Sperren | Blockchain läuft ohne Admin weiter |
+
+Hub-/Worker-Pakete sind **Zielpakete**, noch keine fertig gebauten Releases. Native amd64/arm64 zuerst, optionale Docker-/Compose-Pakete später; Entwicklungs-LXC bleibt ohne Docker. Eine Validator-Node ist auch ein Node, aber nicht jede Full Node ist Validator.
+
+## 4. Phase für Phase installieren
+
+### Jetzt: Bestehenden Entwicklungs-LXC nutzen
+
+- [ ] Proxmox-LXC `potatium-dev` und SSH-Zugang prüfen (kein neuer Server nötig).
+- [ ] Ubuntu 26.04, Go-Toolchain, Git, VS Code Remote-SSH / Codex und privates Git-Remote nach aktuellem Projektstand prüfen/einrichten.
+- [ ] `/home/potatium/src/potatium` als Git-Arbeitsverzeichnis; keine Chain-Daten oder Schlüssel committen.
+- [ ] Simulationspakete außerhalb des produktiven Chain-States testen. Keine echten PTM erzeugt.
+- [ ] Netzplan, zugelassene Ports und Backupstrategie definieren.
+
+### M2: Erstes lauffähiges isoliertes Devnet
+
+- [ ] Eine Potatium-ABCI-App und CometBFT als einzelner Validator mit **eigenem Devnet-Genesis** starten.
+- [ ] Eine getrennte Hub-Full-Node mit eigener Datenhaltung und tatsächlicher Netzwerkverbindung starten.
+- [ ] Hub-WebGUI und Wallet-Basisfunktionen mit tatsächlichen Testdaten anbinden; Wallet-Key bleibt browserseitig.
+- [ ] **Read-only Network Admin von Anfang an** mit echten Statusdaten von Devnet/Hub anbinden: Chain-ID, Blockhöhe, finale Blöcke, Validatorstatus, Synchronisierung, Angebot an registrierten IDs soweit verfügbar.
+- [ ] Nicht implementierte Metriken ausdrücklich als `nicht verfügbar` kennzeichnen; keine Fake-Bestände oder Fake-Transaktionen.
+- [ ] Von Beginn an eigene Chain-ID/Genesis, Datenverzeichnisse und Secrets; Test-PTM können zurückgesetzt werden.
+
+### M3: Lokales Vier-Validatoren-Netz
+
+- [ ] Vier CometBFT+App-Instanzen mit **vier verschiedenen Validator-Schlüsseln**, eindeutigen Ports und getrennten Datenverzeichnissen.
+- [ ] Netz/State-Synchronisierung, App-Hash, 3-von-4-Quorum, Ausfälle/Neustarts testen.
+- [ ] Eine Nichtvalidator-Hub-Full-Node als echter Peer.
+- [ ] Network Admin überwacht vier Validatoren und zeigt verlässlich Quorum-/Synchronisationsdaten.
+
+### M4: Proof of Potato und Identitäten
+
+- [ ] Operator-/Mining-Registry als protokollvalidierter Chain-State.
+- [ ] Hub/Worker-Schlüssel und sichere Kopplung; eine qualifizierte Ticketberechtigung je Mining-ID und Runde.
+- [ ] **Admin-Identitätsübersicht ab Start**, autorisierte Freigabe/Sperre/Key-Rotation erst mit implementierter Registry-Signatur/Verifikation.
+- [ ] Wallet-autorisierte, begrenzte On-chain-Gebührenbudgets statt Wallet-Spend-Key auf Hub/Worker.
+- [ ] 100 % Gebührenziel On-chain-Fonds, nachvollziehbare Mint-/Supply-/Burn-/Fund-Bilanz.
+- [ ] Ein echter Worker auf Pi/Alt-PC und mindestens ein Hub-Miner.
+
+### M5/M6: Mehrhost-Privat-Testnet und später permanentes Netz
+
+- [ ] Vier Validatoren auf physisch getrennte Ausfall-Domänen, idealerweise verschiedene Hosts.
+- [ ] `ptm-admin` in eigenem geschützten Management-LXC, optional Monitoring-Historie in SQLite; keine zentrale Pflicht-DB.
+- [ ] Hub-Pakete und Worker-Pakete als native Release-Binaries; Docker nur optional später.
+- [ ] P2P-Bootstrap über signiertes/verifiziertes Netzwerkmanifest bzw. verwaltete Seed-/Persistent-Peer-Liste, **ohne** zentralen Web-Registrierungsdienst.
+- [ ] Sicherheits-/Crash-/Restore-/Langzeittests, danach getrennte Genesis/Chain-ID für dauerhaftes Netz.
+
+## 5. Network Admin: Was du sehen und ändern darfst
+
+| Daten | Quelle | Cockpit-Recht |
+|---|---|---|
+| Erzeugte PTM, Burn, Umlaufmenge, Fondsbestand | Potatium-App-State/Chain, verifizierte API | Lesen |
+| Aktive Protokollparameter, Gebühren und Runden | On-chain-Konfiguration/aktuelle Chain-Daten | Lesen |
+| Letzte Blöcke, Finalität, Validatorquorum, Peers | CometBFT RPC/Metriken, Potatium-API | Lesen |
+| Registrierte Betreiber- und Mining-IDs, Zuordnungen, Freigabe-/Widerrufstatus | On-chain-Registry | Lesen, Detailansicht |
+| Antrag/Signierte Freigabe, Sperre, Schlüsselwechsel | Validierte on-chain Verwaltungsaktion | **Gezielt erlaubte Schreibaktion** nach gesonderter Authentisierung |
+| Bekannte und „kürzlich aktive“ Hubs/Worker | On-chain-Registry + optional signierte Heartbeats | Lesen, **Verfügbarkeitsstatus mit Zeitstempel** |
+| Guthaben fremder Wallets verändern / Coins frei erzeugen / Gebühren beliebig umstellen | Keine autorisierte Funktion | **Nie** |
+
+**Globale Online-Zahl ist ohne Telemetrie nicht exakt messbar.** Eine Validator-Peer-Liste zählt nur direkt sichtbare Peers. Der Admin darf unterscheiden zwischen `registriert`, `zuletzt gesehen`, `online laut Heartbeat`, `nicht gemeldet`. Freiwillige signierte Heartbeats können an einen optionalen Monitoring-Sammler gesendet werden; dessen Ausfall darf weder Mining noch Blockchain-Betrieb stoppen.
+
+Wichtig: Emission/Fondsstatus als On-chain-Daten sind technisch von anderen Full Nodes rekonstruierbar. Nur die Admin-Oberfläche ist exklusiv; auf Chain gespeicherte Daten sind nicht allein durch UI-Rechte vertraulich.
+
+## 6. Daten und Backup
+
+**Keine zentrale Ledger-Datenbank.** Jeder Validator und jeder Full-Node-Hub hat sein eigenes CometBFT-Datenverzeichnis und seine eigene persistente Potatium-App-State-Datenbank. Auswahl der Embedded-DB (bbolt/Pebble o. ä.) steht noch aus. Das Admin-Cockpit darf optional SQLite als Monitoring-Cache nutzen, aber keine Quelle für Kontostände oder Mining-Rechte sein.
+
+Strikte Trennung für `devnet`, `testnet` und permanentes Netz inklusive Keys, Chain-IDs, Genesis, Verzeichnissen und Backups. Validator-Consensus-Key und Signierzustand besonders sichern; nicht denselben Schlüssel auf zwei aktiven Validatoren gleichzeitig einsetzen. Wallet-Seeds niemals im Server, Logs, Datenbankcache oder Git speichern. Recovery und Restarts testen, bevor echte dauerhafte Netzwerke in Betrieb genommen werden.
+
+## 7. Netzwerk-/Portkonzept
+
+CometBFT-Beispieldefaults laut Upstream-Konfiguration: P2P `26656/TCP`, RPC `127.0.0.1:26657`, ABCI-App-Verbindung `127.0.0.1:26658`, Prometheus-Metriken häufig `26660`, aber standardmäßig nicht zwingend aktiviert. **Dies sind keine verbindlichen Potatium-Ports.** Mehrere Instanzen auf einem Host brauchen pro Dienst separate Listen-Adressen/Ports.
+
+- P2P zwischen ausdrücklich erlaubten Peers im privaten Netzwerk oder über VPN und Firewall.
+- RPC, ABCI, Metrics sowie Admin-Web standardmäßig nur Loopback beziehungsweise über kontrollierte lokale Proxys/VPN-Verbindungen; niemals unnötig öffentlich.
+- Hub-GUI beispielhaft `127.0.0.1:8080`, Admin-GUI `127.0.0.1:8090` (beides **Vorschläge**, nicht implementiert).
+- Vom Arbeitsplatz aus SSH-Portforwarding, keine GUI-Desktop-Installation im LXC.
+- Kein eigenständiger Bootstrap-Dienst nötig, solange erreichbare Seed-/Persistent-Peers und eine authentische Netzwerk-Konfiguration verfügbar sind.
+
+## 8. Was noch nicht feststeht
+
+- CometBFT-/Go-Version und konkrete ABCI++-Prozesskopplung, Embedded-KV-DB, echte Hardware-Minimums.
+- Chain-IDs, feste Ports/Hostnamen, Adress-/Schlüssel-/Signaturformate, Restore-Mechanik.
+- Betreiber-ID-/Mining-ID-Freigabeprotokoll inklusive Offline-/Admin-Signatur und Auditdetails.
+- Gebührenhöhe für 1–10 Worker sowie Fenster 2/3; Ergebnisse der laufenden dynamischen PoP-Simulation stehen aus.
+- Fonds-Auszahlungsregeln und Transaktionsgebühren.
+- Telemetrie/Heartbeat-Protokoll, Datenschutz/Retention und ob SQLite benötigt wird.
+
+**Nächster Schritt:** Laufende Dynamik-/Fondssimulation auswerten, anschließend die Repo-Dokumentation (insbesondere `docs/NETWORK_SERVICES_UND_ONBOARDING.md`, ADR 0007, ROADMAP, INFRASTRUKTUR) konsistent auf die vereinfachte Architektur ohne verpflichtenden `potatium-network`-Registrierungsdienst bringen. Keine tatsächlichen Installationen oder Code-Funktionen als abgeschlossen markieren.
@@ -0,0 +1,9 @@
+# Historischer Entwurf: zentrale Network Services (v0.5)
+
+**Nicht mehr gültig für die Architekturplanung.** Die in v0.5 vorgeschlagene Pflicht zu `potatium-network` mit zentralem Onboarding, Registrierungsportal und Off-chain-Benutzerverzeichnis wurde vom Projektbetreiber **verworfen**. Sie darf nicht implementiert oder in der Roadmap als Pflicht vorgesehen werden.
+
+**Aktueller Stand:** [`NETWORK_ZUGANG_UND_IDENTITAETEN.md`](NETWORK_ZUGANG_UND_IDENTITAETEN.md) und [ADR 0008](decisions/0008-schlanker-netzzugang-admin-und-identitaeten.md).
+
+Weiterhin entschieden: **100 % der PoP-Fenster-2-/3- und Workergebühren an den On-chain-Community-Fonds; kein Burn dieser Gebühren**. Ursprünglich in ADR 0007 festgehalten und durch ADR 0008 bestätigt.
+
+Zur historischen Nachvollziehbarkeit wird ADR 0007 behalten, aber die dort beschriebene verpflichtende zentrale Control Plane ist durch ADR 0008 überholt.
@@ -0,0 +1,27 @@
+# Netzzugang, lokale Node-Konfiguration und Mining-Identitäten
+
+**Aktueller Architekturentscheid:** ADR 0008 (25.10.2026). **Noch keine funktionierende Implementierung.** Das ältere `NETWORK_SERVICES_UND_ONBOARDING.md` beschreibt eine *verworfene* verpflichtende zentrale Registrierung und ist nur noch als historischer Entwurf enthalten.
+
+## 1. Netzwerk beitreten: Ohne zentralen Benutzeraccount
+
+Hub-Installation / lokale Konfiguration enthält: Chain-ID, authentischen Genesis-Hash bzw. vertrauenswürdige Genesis-Datei, Seed-/Persistent-Peer-Adressen, eigene P2P-/Node-Schlüssel, lokale Daten- und Portpfade, optional separaten Operator-Fingerprint/Mining-ID. Alle Peers/Ports und Genesis werden gegen die Vertrauensanker geprüft. Die Node verbindet sich P2P und synchronisiert selbst, unabhängig vom Network Admin.
+
+**Technische Rollen:** Validator (CometBFT-Konsens, eigener State), Hub (Full Node mit WebGUI und browserseitiger Wallet, optional Miner), Worker (Hub-gebundener Miner ohne Chain-State/Spend-Key), Betreiber (`operator_id`, mehrere Hub-/Worker-IDs). Eine Wallet ist keine Node-Identität; der Hub/Worker darf keinen Wallet-Spend-Key empfangen. Ein Fingerprint allein beweist keine Kontrolle über den Schlüssel.
+
+## 2. Mining-Zulassung: Getrennt von P2P
+
+Für die erste private Version legt die betreibende Person eine überprüfte Betreiber-/Mining-Identität mit zugehörigen öffentlichen Schlüsseln fest. Anträge können anfänglich manuell als signierte Datensätze/CLI-Datei übermittelt werden, keine verpflichtende Registrierungs-Website. Geschütztes Admin-Werkzeug erstellt erst nach Prüfung die autorisierte **On-chain-Freigabe**; Validatoren prüfen sie deterministisch, danach gilt sie als bestätigt. Die Admin-GUI zeigt Registrierung/Freigabe/Sperre und Audit. Ein Statusfeld in lokaler Konfiguration oder optionaler Monitoring-DB verleiht keinerlei Mining-Recht.
+
+**Freigaben und Sperren sind schreibende Ausnahmen:** Sie dürfen erst aktiviert werden, wenn Admin-Schlüsselformat, Rechte und Audit mit Negativtests vorliegen. Bis dahin read-only Cockpit und inaktive Schaltflächen mit verständlicher Begründung. Keine Server-Wallet-Keys.
+
+## 3. Netzwerküberblick und Zählbarkeit
+
+Die Registry kennt zugelassene Identitäten, nicht automatisch laufende Rechner. Peers einer Node sind eine Teilmenge der Netzverbindungen. Ein optionaler, geschützter Monitoring-Receiver kann nur mit Zustimmung signierte Heartbeats erfassen und Zeitreihen speichern, beispielsweise in SQLite. Anzeigen daher getrennt: **registriert / P2P gesehen / signiert zuletzt online / PoP aktiv** mit Zeitpunkt und Datenabdeckung. Keine vollständige Live-Hostzahl ohne flächendeckend verifizierte Meldungen behaupten.
+
+## 4. Ausfallverhalten / Sicherheit
+
+Validatoren und bereits synchronisierte Hubs bleiben bei Admin-Ausfall funktionsfähig. Seed-Fallback über mindestens zwei unabhängige Einträge im späteren Testnet. Keine ungeschützten externen RPC-/Admin-/ABCI-Ports; Entwicklung auf localhost plus SSH-Forward. API-/Pairing-Authentifizierung unabhängig von fremden Wallet-Spend-Keys. Keine zentrale Benutzerpasswortdatenbank.
+
+## 5. Entwicklungsreihenfolge
+
+M1: Chain-ID/Genesis-Verifikation, Betreiber-/Mining-/Admin-Keys und Registry-Aktionen spezifizieren. M2: erster Validator, Hub+Wallet und getrenntes Network-Admin-Read-only auf echter Datenquelle. M3: Multi-Peer-/Validator-Betrieb. M4: signierte Freigabe/Sperre, Worker-Pairing, PoP und Fonds; M5/M6 optional Monitoring-Historie und geschützter separater Admin-LXC.
@@ -0,0 +1,127 @@
+# Potatium | Hub-Worker-Ökonomie: Offline-Forschung v0.1
+
+**Kein Konsenscode, keine realen PTM, keine Netzwerkzugriffe.** Reproduzierbare Monte-Carlo-Tests mit der Python-Standardbibliothek. Diese Ergänzung ersetzt keine bestehenden Simulationsskripte.
+
+## Ziel
+
+Verschiedene Clustergrößen (1 eigenständiger Hub plus 0–10 zusätzliche Mining-Worker) auf eine **gemeinsame Betreiberidentität und Wallet** buchen und Kosten vs. Gewinnchance vergleichen. Jede aktive Mining-ID, inklusive Hub, kann **maximal ein Los je PoP-Runde** erarbeiten. Nur ein registrierter Hub-Platz je Betreiber ist von der Worker-Gebühr befreit. Zusätzliche Hub-Mining-IDs wären wirtschaftlich wie Worker zu zählen, ihre physische Hardware kann das Modell nicht erkennen.
+
+## Modellierte Regeln und Forschungsparameter
+
+- **Fenster 1:** Bei jeder aktivierten Mining-ID kostenlos, Bernoulli-p je Node; p = 0,55 im Profil `balanced`.
+- **Fenster 2/3:** Nur nach bisherigem Qualifikationsfehlschlag derselben ID; jeweils kostenpflichtig und erfolgreich mit p=0,30 bzw. p=0,20. Bei Erfolg keine dritte Aufgabe. Die Fensterwahrscheinlichkeiten bleiben **Forschung**, keine PoP-Konsensparameter.
+- **Gewinnauslosung:** Eine Bruttobelohnung je Runde, sofern mindestens ein Los akzeptiert wurde. Jedes Los einer ID ist gleichwertig. Bei mehreren Losen desselben Betreibers kann dieser mehrfach vertreten sein, aber pro Runde höchstens die *eine* Bruttobelohnung erhalten.
+- **Betreiber-Wallet:** Alle Worker und der Hub teilen Guthaben, Gebührenbudget und die rollierende **90-Tage-PoP-Gewinnhistorie**. Fensterprogression und Gebührenzahlung werden pro Betreiber zusammengefasst. Wallet-Transfers sind nicht simuliert.
+- **Worker-Aktivierung:** Vor der Challenge bezahlt, auch bei Misserfolg. Ist das Guthaben unzureichend, werden weniger Worker aktiviert. Ein Offline-Worker wird im Modell nicht simuliert.
+- **Worker-Tarif:** `marginal` (pro Worker: 1–3 je 0,001 PTM, 4–7 je 0,003 PTM, 8–10 je 0,005 PTM) vs. `tier` (pauschal 0,001/0,003/0,005 PTM je Betreiber und Runde). Die Skala kann mit `--worker-fee-scale` geändert werden. **Kein endgültiger Tarif.**
+- **Fenster-Tarif:** Fixe F2/F3-Grundgebühr (0,001 / 0,003 PTM) + progressive Abgabe nach PoP-Gewinnen der letzten 90 Tage. `original` = 100 % der v0.2-Progression, `mild` = 10 %, `low` = 1 %. Ausschließlich die Progression wird skaliert, fixe Grundkosten bleiben.
+- **Zahlungsstrategie:** `free` stoppt nach F1, `always` kauft erlaubte weitere Fenster soweit finanzierbar, `rational` verwendet eine *vereinfachte* Grenzertragsschätzung mit eigener bereits erreichter Ticketzahl und einer F1-Schätzung fremder Tickets. Es ist **keine optimal spieltheoretische Strategie**.
+- **Wettbewerb:** Jedes weitere registrierte Betreiberkonto ist ein eigenständiger Konkurrent; optional besitzen auch die Konkurrenten Worker. Optional kommen neue Betreiber ab einem festgelegten Simulationstag hinzu.
+- **Emission:** Beispielhaft 1 PTM pro Runde mit Sieger; Gebühren werden verbrannt. Kein Sieger bedeutet keine Emission. `--rounds-per-day 720` entspricht dem früheren **unverbindlichen** Vorschlag von ca. 2 Minuten je PoP-Runde.
+
+## Installation im bestehenden Git-Repository
+
+Das ZIP enthält ausschließlich drei **neue** Pfade, die noch nicht vorhanden sein sollten:
+
+```
+scripts/simulate_pop_cluster.py
+tests/test_pop_cluster.py
+docs/POP_CLUSTER_SIMULATION.md
+```
+
+Vor dem Entpacken mit `unzip -l` prüfen. Mit `unzip -n` werden bestehende Dateien niemals überschrieben. Der Befehl führt selbst noch keine Blockchain-Funktionen aus.
+
+```bash
+cd ~/src/potatium
+unzip -n ~/Potatium_PoP_Cluster_Simulation_v0.1.zip -d .
+python3 -m unittest discover -s tests -p 'test_pop_cluster.py' -v
+```
+
+## Schritt 1: Kurzer Funktionstest
+
+```bash
+python3 scripts/simulate_pop_cluster.py \
+  --operators 20 --days 7 --rounds-per-day 720 \
+  --workers 0 1 3 5 10 --replicates 1
+```
+
+## Schritt 2: 180 Tage, Worker-Sweep
+
+Vergleich von 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Workern mit gemeinsamem Betreiber-Wallet, `balanced`-Fenstern und `low`-Progression:
+
+```bash
+python3 scripts/simulate_pop_cluster.py \
+  --operators 20 --days 180 --rounds-per-day 720 \
+  --workers 0 1 2 3 4 5 6 7 8 9 10 \
+  --profile balanced --window-fee-model low \
+  --worker-fee-model marginal --worker-fee-scale 1 \
+  --target-policy rational --others-policy free \
+  --replicates 3
+```
+
+**Hinweis:** Ein Modell mit 19 anderen Betreibern, die nur ihren eigenen kostenlosen Hub nutzen, begünstigt den Ausbau des einen getesteten Clusters. Das ist ausdrücklich ein Extrem-Szenario, kein realistisches Marktgleichgewicht.
+
+## Schritt 3: Höhere Worker-Gebühren untersuchen
+
+Gleiche Randbedingungen wie oben, aber beispielsweise fünffache Worker-Gebühren:
+
+```bash
+python3 scripts/simulate_pop_cluster.py \
+  --operators 20 --days 180 --rounds-per-day 720 \
+  --workers 0 1 2 3 4 5 6 7 8 9 10 \
+  --profile balanced --window-fee-model low \
+  --worker-fee-model marginal --worker-fee-scale 5 \
+  --target-policy rational --others-policy free \
+  --replicates 3
+```
+
+## Schritt 4: Alle Betreiber besitzen Worker, Neulinge kommen hinzu
+
+```bash
+python3 scripts/simulate_pop_cluster.py \
+  --operators 20 --days 180 --rounds-per-day 720 \
+  --workers 0 1 3 5 8 10 \
+  --others-workers 2 --others-policy rational \
+  --newcomers 5 --join-day 90 \
+  --worker-fee-model marginal --worker-fee-scale 1 \
+  --target-policy rational --replicates 3
+```
+
+## Schritt 5: Immer alle Fenster vs. kostenbewusst
+
+Den gleichen Aufruf jeweils mit `--target-policy always` bzw. `rational` durchlaufen lassen. Bei `always` wird eine Fenstergebühr nur gezahlt, wenn die jeweilige Node zuvor noch kein Ticket erhalten hat und das Wallet genug Guthaben besitzt.
+
+## Interpretation der Kennzahlen
+
+- `Gewinn%`: **Betreiberchance auf den Rundengewinn**, nicht nur Qualifikation.
+- `Brutto PTM`: Summe seiner erhaltenen PoP-Belohnungen.
+- `Netto PTM`: Brutto minus Worker- und Fenstergebühren. Bei `initial_balance=0` identisch mit Endguthaben.
+- `Ø aktive`: tatsächlich finanzierte Worker je Runde, ggf. kleiner als beantragt.
+- `ΔNetto/Worker`: Unterschied des durchschnittlichen Nettoertrags zwischen zwei *getesteten* Worker-Zahlen, geteilt durch deren Abstand; bei fehlenden Zwischenwerten **nicht** der exakte marginale Wert eines einzelnen Workers. Bei wenigen Seeds statistisch verrauscht. Negativ bedeutet nur: In den simulierten Szenarien hat mehr Worker-Zahl einen geringeren Nettoertrag geliefert.
+- `Gini`: Ungleichheit der Wallet-Guthaben **je registrierter Betreiberidentität**, kein Beweis für menschliche Fairness.
+- `Burn`: Summe tatsächlich gezahlter Gebühren, keine Token-Pauschale oder einmaliger Gebührenabzug.
+
+## Ergebnisdateien
+
+Standardziel: `~/potatium-simulation/`. Das Skript erzeugt:
+
+| Datei | Inhalt | Senden? |
+|---|---|---|
+| `pop_cluster_....txt` | Kurzer Szenarienvergleich | **Ja** |
+| `pop_cluster_..._comparison.csv` | Alle Kennzahlen je Workerzahl | **Ja** |
+| `pop_cluster_..._daily.csv` | Tagesverlauf, Einnahmen und Burn | Bei Rückfragen |
+| `pop_cluster_..._operators.csv` | Endzustand je Betreiber | Bei Rückfragen |
+| `pop_cluster_....json` | Vollständige reproduzierbare Simulation | Für tiefe Analyse |
+
+Ein Hash über alle CLI-Parameter im Dateinamen vermeidet das Überschreiben verschiedener Vergleichsläufe mit ähnlichen Namen. Identischer Aufruf überschreibt seine alten Ausgabedateien.
+
+## Bekannte Grenzen und offene Konsensfragen
+
+- **Keine Sybil-Sicherheit:** Ein Betreiber mit mehreren künstlichen Betreiberkonten könnte mehrere freie Hubs und separate Gebührentöpfe bekommen. Diese Angriffsstrategie wird **nicht modelliert**. Eine manuelle Betreiber-Registry schließt Doppelanmeldungen nicht kryptografisch aus.
+- Keine überwachbaren *fehlgeschlagenen* PoW-Aufwände. Jede Fensteraufgabe wird als unabhängiger Zufall mit angenommener Wahrscheinlichkeit modelliert; echte Pi-4-Zeiten fehlen.
+- Keine realistische Übertragung von Gebührenmandaten aus dem Browser, keine verlorenen Schlüssel oder Netzwerkausfälle, keine Validator-Zensur, kein Peer-Latenzmodell.
+- Die Bedingung, dass Zahlungsmandate/Worker-Freischaltungen vor der jeweiligen Challenge bindend feststehen, wird **logisch modelliert**, nicht kryptografisch implementiert.
+- Keine Preisbindung an EUR/andere Kryptowährungen; PTM hat hier keinen externen Marktpreis und damit keinen externen Ertragswert.
+- Gleichzeitige Entscheidungen der Miner, Fee-Scaling nach Anzahl Teilnehmern und strategisch variable Anzahl aktivierter Worker sind nicht optimiert. Der Zielbetreiber versucht stets, so viele der angefragten Worker zu aktivieren, wie sein Wallet finanzieren kann.
+- Die Beispiele 1 PTM je Runde, 720 Runden pro Tag und bis zu zehn Worker sind **Forschungswerte, keine beschlossenen Protokollparameter**.
+- Für eine echte On-chain-Implementierung ausschließlich ganzzahlige PTM-Basiseinheiten, konsenskritische Negativtests, feste Rundengrenzen, reproduzierbare Zufallsquelle und überprüfbare Signaturen verwenden.
@@ -0,0 +1,57 @@
+# Potatium: Dynamische Worker und Fonds-Rückflüsse (Forschungsstand v0.1)
+
+**Status:** Simulationsentwurf, noch keine Protokoll- oder Coinparameter freigegeben.
+**Basis:** PoP-Cluster v0.1, Worker-Gebührenforschung v0.4, Gebührenflussanalyse v0.1.
+
+## Ziel und Fragestellung
+
+1. Lohnt ein weiterer Worker bei einer Worker-Gebühr von 1x, 3x oder 5x?
+2. Unterschied `fixed` (alle bezahlbaren Worker) vs. `dynamic` (je Runde auf Schätzwert basierte Wirtschaftlichkeitsentscheidung).
+3. Was passiert mit Fondsbestand, Betreiber-Guthaben und Mining-Chancen bei 100 % Fondszufluss und 0 % Burn?
+4. Wie wirkt **hypothetische** Rückgabe von Fondsvermögen auf Aktivierung und Vermögensverteilung?
+5. Haben Betreiber mit 0 oder 1 Worker eine reale Chance gegenüber Clustern mit 3, 5, 8, 10 Workern und Neueinsteigern?
+
+## Abgebildete Regeln
+
+- Je registriertem Betreiber **ein Hub-Mining-Platz ohne Worker-Gebühr** und bis zu zehn zusätzliche bezahlte Worker-Mining-Identitäten im *Forschungsmodell*. Zweite Hubs sind nicht gratis zusätzliche Mining-Identitäten.
+- Eine Mining-ID darf pro Runde höchstens ein gültiges Ticket qualifizieren. Pro Runde höchstens ein Gewinner; Preis beispielhaft 1 PTM.
+- Alle drei Fenster werden je Mining-ID sequenziell versucht. F1 kostenlos, F2/F3 nur wenn vorheriger Versuch erfolglos und das gewählte Modell die Gebühr deckt.
+- Vor Versuch in jedem Fenster wird die Gebühr bezahlt, *vor* dessen Bernoulli-Entscheid. Worker-Aktivierung ebenfalls vor F1. Keine bezahlte Aktivierung bei Guthabenmangel.
+- Alle Mining-Belohnungen und 90-Tage-Erträge je Betreiber zusammengefasst. **Die Gebührenprogression nutzt nur Mining-Belohnungen der letzten 90 Tage, nicht Wallet-Kontostände und nicht Fondsauszahlungen.**
+- Auszahlungen gehen ins gemeinsame Betreiber-Wallet. Guthaben im Code nur abstrakter Float-Forschungswert, kein privater Schlüssel.
+- Worker-Gebühr pro Runde marginal: W1–3 je 0,001, W4–7 je 0,003, W8–10 je 0,005 PTM, skaliert mit `--scales` 1/3/5. Beispielwerte, keine finale Gebühr.
+- `balanced`-Profil: PoP-Fenstererfolge 55 % / 30 % / 20 %. `low`-Fenstergebühren nutzen 1 % der vorher modellierten Progressionskomponente plus jeweilige Grundgebühr.
+- Zeitachse 180 bzw. 360 Tage, 72 oder 720 Runden pro Tag (Forschungswerte, keine CometBFT-Blockhäufigkeit).
+- Betreiberkapazität wiederholt die Liste 0,1,3,5,8,10. 20 bestehende Betreiber, 5 kommen an Tag 90 hinzu. Zugewiesene Startguthaben gelten bereits als Genesis-Bestand aller Operatoren.
+- `hold`: Gebühren verbleiben im Fonds. `redistribute`: alle `--payout-interval` Tage wird `--payout-share` des **aktuellen** Fondsbestands *gleichmäßig an alle aktuell aktiven Betreiber* ausgeschüttet. Verteilung = REINES WHAT-IF, kein Governance-Beschluss. Fonds-Rückflüsse werden nicht erneut als Mining-Ertrag klassifiziert.
+- Rechnerische Identität **Genesis + minted = Fonds + alle Wallets** muss an jedem Tag gelten; `burned=0`.
+
+## Grenzen der Simulation
+
+**Kein** echter Hash-/Mining-Prozess, keine Ressourcenunterschiede bei Pi/Alt-PC, kein Netzwerk oder Konsens, keine Ausfälle, keine rechts- oder ökonomisch belastbare Bewertung. Wallet-/Betreiber-Identitäten werden nicht als physische Geräte verifiziert. Kein Sybil-Schutz, keine anonymen Mehrfachbetreiber, keine Simulation unterschiedlicher 90-Tage-Historien bei externen Wallet-Transfers. Keine Kursbewertung oder Fiat-Preise.
+
+`dynamic` ist ausdrücklich *kein mathematisch optimaler Miner*: Die Strategie verwendet für die Workerwahl ein vereinfachtes erwartetes Anteilsschema mit F1-Ticketwahrscheinlichkeit und dem exponentiell geglätteten Rivalen-Ticketstand vergangener Runden. Die Entscheidung für Fenster 2/3 ist ebenfalls eine grobe Heuristik. Ein perfektes oder spieltheoretisches Gleichgewicht wird **nicht** behauptet.
+
+Das hypothetische gleichmäßige Ausschütten des Fonds würde einen starken **Sybil-Anreiz** schaffen: Mehr Betreiberidentitäten könnten mehr Auszahlungen beanspruchen. Diese Variante ist ausdrücklich kein Vorschlag für die reale Fonds-Governance. Bei `redistribute` fließt der Fonds auch zu Betreibern zurück, die selbst Worker-Gebühren gezahlt haben; Brutto-Zahlungen und Nettoeinnahmen bitte getrennt bewerten.
+
+Gini berücksichtigt Wallet-Guthaben registrierter Betreiber **ohne** das Gemeinschafts-Fondskonto. Gemessene Gini-Werte sind weder universelle Fairnessmaße noch direkt mit früheren 20-Miner-Szenarien vergleichbar.
+
+**Vorsicht bei `72` statt `720`:** 72 Runden/Tag macht Tests schneller, verändert aber die Zahl der in 90 Tagen verdienten Coins und damit die Gebührenprogression. Die Ergebnisse sind daher ein eigenständiges Szenario, kein skaliertes Äquivalent zu den früheren 720-Runden-Modellen.
+
+## Ausgabedateien
+
+- `_summary.txt`: Vergleich der Szenarien in Textform.
+- `_comparison.csv`: Parameter und Durchschnittswerte pro Gebühren- und Fondsvariante; zusätzlich gruppierte Ergebnisse je Clusterkapazität (`capacity_X_net`, `capacity_X_activated`, `capacity_X_wallet` usw.).
+- `_operators.csv`: Ergebnis pro Betreiber/Seed, brutto, Gebühren, Fondsrückfluss, Netto, aktive Worker, Gewinne.
+- `_daily.csv`: täglicher Fonds-, Emissions-, Wallet-, Gini- und Aktivierungsverlauf.
+- `_results.json`: vollständige Szenarios mit Parametern, Tageswerten, Betreiberwerten und Modellgrenzen.
+- `*_ERGEBNISSE.zip`: automatisch erzeugtes Uploadarchiv mit den fünf Ergebnisdateien.
+
+## Verifikation
+
+```bash
+python3 -m unittest discover -s tests -p 'test_pop_dynamic.py' -v
+python3 scripts/simulate_pop_dynamic.py --operators 6 --newcomers 2 --join-day 3 --days 5 --rounds-per-day 20 --replicates 1
+```
+
+Echte Chain-/Wallet-/Netzwerk-Tests sind dadurch **nicht** ersetzt. Nach den Forschungsruns erst gemeinsames Review, dann gezielte Dokumentations-/ADR-Anpassung im Repository. Unentschiedene Gebühren oder Fondsausgaben nicht als verbindlich markieren.
@@ -0,0 +1,55 @@
+# Proof of Potato: Dynamische Worker und Fonds · Auswertung vom 25.10.2026
+
+**Status: abgeschlossene Forschungsrunde, KEINE Tarife, Emissionen oder Fonds-Ausgaben beschlossen.**
+
+## Datengrundlage und Reproduzierbarkeit
+
+- Benutzerarchiv: `potatium_dynamic_20o_180d_720r_ac029505ee_ERGEBNISSE.zip` (SHA-256 `a83786c7d55394f8c1777b147ce50972c8ab59090e31895c9b9f1f8a6d014be3`).
+- Enthält 36 vollständige Läufe aus **12 Konfigurationen × 3 Seeds** (20261025, 20261026, 20261027), fünf Dateien (TXT, CSV, JSON); ZIP-Integrität überprüft.
+- 20 bestehende Betreiber, fünf ab Tag 90, Kapazitäten 0/1/3/5/8/10 zusätzliche Worker; jeder Betreiber ein kostenloser Hub-Mining-Platz.
+- 180 Tage, 720 **hypothetische** PoP-Runden je Tag, 1 hypothetischer PTM-Gewinn je Runde, Balanced-Fensterchancen 0,55/0,30/0,20, Low-Fensterkosten, rationalisierte Fensterwahl.
+- Kein Genesis-Guthaben; 129.600 PTM erzeugt, 0 PTM verbrannt, kein realer Proof-of-Work/Chain-/Wallet-Test.
+- Querschnitt der zwölf Mittelwerte als [`research/po_p_dynamic_20261025_comparison.csv`](research/po_p_dynamic_20261025_comparison.csv); reproduzierbar mit `python3 scripts/simulate_pop_dynamic.py --operators 20 --newcomers 5 --join-day 90 --capacities 0 1 3 5 8 10 --days 180 --rounds-per-day 720 --scales 1 3 5 --worker-modes fixed dynamic --fund-modes hold redistribute --replicates 3`.
+
+## Kernzahlen: Fondsanteil des modellierten Supply nach 180 Tagen
+
+| Workergebühr | Dynamisch, Fonds hält | Fix, Fonds hält | Dynamisch, hypothetische Ausschüttung | Fix, hypothetische Ausschüttung |
+|---|---:|---:|---:|---:|
+| 1× | 23,92 % (31.001 PTM) | 23,92 % | 10,13 % (13.131 PTM) | 10,13 % |
+| 3× | 40,59 % (52.604 PTM) | 65,87 % (85.363 PTM) | 16,55 % (21.443 PTM) | 29,07 % |
+| 5× | 26,81 % (34.750 PTM) | 70,20 % (90.985 PTM) | 11,07 % (14.348 PTM) | 35,77 % |
+
+Die feste 5×-Variante bindet ungefähr 70 % der 129.600 neu erzeugten PTM, obwohl die Coins nicht verbrannt werden. Das ist ein ernstes Liquiditätsproblem, **kein Supply-Verlust**. Der Fonds gehört zur Gesamtmenge und wird nicht doppelt gezählt.
+
+## Worker-Aktivierung und Nettoerträge
+
+| Worker-Skala, Modus | Alle Betreiber: aktive Zusatzworker je Runde, Ø | Großer Betreiber (Kapazität 10): tatsächlich aktiviert, Ø | Netto-Miningertrag Kapazität 0, Ø | Netto-Miningertrag Kapazität 10, Ø |
+|---|---:|---:|---:|---:|
+| 1× dynamisch | 94,93 | 10,00 | 1.184 PTM | 8.121 PTM |
+| 3× dynamisch | 73,09 | 5,99 | 1.402 PTM | 4.628 PTM |
+| 3× fix | 92,41 | 9,99 | 1.193 PTM | 557 PTM |
+| 5× dynamisch | 46,21 | 3,03 | 1.956 PTM | 5.348 PTM |
+| 5× fix (Fonds hält) | 66,06 | 2,63 | 1.530 PTM | 1 PTM |
+
+Bei 1× unterscheiden sich feste und dynamische Strategie praktisch nicht; die Kosten sind zu niedrig, um Worker abzuschalten. Bei 3× begrenzt die dynamische Heuristik große Cluster auf etwa sechs, bei 5× auf etwa drei aktive Worker. **5× erzeugt trotz höherem Stückpreis weniger Fondseinnahmen als 3×**, weil deutlich weniger Worker bezahlen. Diese Rückkopplung ist für die Ökonomie zentral.
+
+**Netto-Miningertrag** (`mining_net = earned - worker_paid - window_paid`) enthält keine hypothetischen Fondsausschüttungen; `wallet` enthält sie. Daher können in der 5×-Fix-/Ausschüttungsvariante einzelne Betreiber **negative Mining-Nettoerträge** haben, obwohl ihr finales Wallet-Guthaben nicht negativ ist. Netto und Wallet nie verwechseln.
+
+## Fonds-Auszahlungen: reiner Belastungstest
+
+Das Szenario `redistribute` zahlt **alle 30 Tage 25 % des zu diesem Zeitpunkt verbleibenden Fonds** gleichmäßig an aktive Betreiber. Dies ist **keine vereinbarte oder empfohlene Governance-Regel**. Es verschiebt Bestände (z. B. 3× dynamisch: Fonds 40,59 % → 16,55 %, kumulierte Ausgaben 31.161 PTM), schafft aber keine Coins. Gleiche Zahlung je Betreiber bietet ohne robuste Betreiberprüfung einen zusätzlichen Sybil-Anreiz. Eine tatsächliche Fondsverwendung muss als separate Produktentscheidung mit Zwecken, Berechtigungen, Belegen und Missbrauchstests spezifiziert werden.
+
+## Neueinsteiger, Ungleichheit und Grenzen
+
+- Bei 3× dynamisch beträgt der modellierte tägliche Netto-Miningertrag der Neueinsteiger im Mittel 19,44 PTM, bei Altbetreibern 18,96 PTM; bei 5× dynamisch 23,50 zu 23,41 PTM. **Kein Beweis fairer Einstiegsbedingungen**, da unterschiedliche Teilnahmedauer/Kapazitäten und nur drei Seeds.
+- Der Gini aus den **Operator-Wallets** sinkt bei Fonds-Rückverteilung, berücksichtigt aber nicht den gesperrten Fondsbestand oder die tatsächliche Nutzbarkeit von PTM. Ein niedrigerer Wallet-Gini ist allein kein Fairnessbeweis.
+- Ein Miner kann keine physische Maschine beweisen; mehrere Betreiberidentitäten, Gerätefälschung, Validator-Vorteile, P2P-Ausfälle, Hashleistung, Stromkosten, Marktpreise und reale Wallet-Autorisierung sind nicht modelliert.
+- Die `dynamic`-Strategie optimiert eine **myopische F1-only-Ertragsprognose**, die Kosten der Fenster 2/3 und zukünftige Fonds-Rückflüsse nicht vollständig in die Worker-Wahl einpreist. Kein spieltheoretisches Gleichgewicht.
+- Die 90-Tage-Basis, 720 Runden/Tag, 1 PTM/Runde, Tarife, Maximalkapazität zehn und periodische Auszahlungen sind Forschungsannahmen. Keine davon als PoP-Implementierungsparameter übernehmen.
+- Der Simulator verwendet Fließkommazahlen und eine einfache Monte-Carlo-Ziehung, niemals für deterministische Konsensberechnung verwenden.
+
+## Entscheidung und nächster Schritt
+
+**Bestehende Produktentscheidung bestätigt:** 100 % der PoP-Fenster- und Workergebühren gehen zunächst an den On-chain-Community-Fonds, **0 % Burn dieser Gebühren**. Die Studie entscheidet **nicht**: Workerfaktor 3×/5×, maximale Workerzahl, Fonds-Ausschüttung, Gebühr je Fenster, Coin-Emission.
+
+Nächster Schritt vor Festlegung der Tarife: echte Hash-/Latenzmessung auf Pi 4 und altem PC, mehr Seeds / heterogene Netzwerkgrößen, Freigabe- und Sybil-Szenarien, Fondsverwendungs-/Missbrauchsmodell. Danach eigenes ADR mit Integer-Basiseinheiten, Rundungs- und Timingregeln.
@@ -0,0 +1,68 @@
+# PoP-Gebührenverteilung: Forschungsanalyse
+
+**Kein Konsens-Code. Keine neuen beschlossenen Coinparameter.** Das Skript benutzt `float` nur für die Offline-Modellrechnung. In der Blockchain sind ausschließlich deterministische ganzzahlige Basiseinheiten vorgesehen.
+
+## Motivation
+
+Die bisherige PoP-Cluster-Simulation zieht Worker- und Fenster-Gebühren vom Betreiber-Wallet ab und **verbrennt** sie. Die Gebühren begrenzen die wirtschaftliche Attraktivität zusätzlicher Mining-IDs, aber ein hoher Burn entzieht der späteren geschlossenen Sammler-/Marktplatz-Ökonomie Coins.
+
+Gebührenhöhe und Gebührenziel sind daher **getrennte Designentscheidungen**:
+
+- Gebühr: wie stark kostet zusätzlicher Worker bzw. Fenster 2/3?
+- Ziel: Verbrennung, Validatoren, gesonderter Ökosystem-Fonds oder Mischung?
+- Empfängeridentität: Validator und Betreiber können in der Praxis dieselbe Person sein. Dadurch verändern sich ökonomische Anreize und möglicherweise die Mining-Strategie.
+
+## Off-chain-Forschungsprofile
+
+| Name | Burn | Validatoren | Fonds |
+|---|---:|---:|---:|
+| `burn_100` | 100 % | 0 | 0 |
+| `validators_100` | 0 | 100 % | 0 |
+| `treasury_100` | 0 | 0 | 100 % |
+| `validators_80_treasury_20` | 0 | 80 % | 20 % |
+| `validators_70_treasury_25_burn_5` | 5 % | 70 % | 25 % |
+| `worker_treasury_window_validators` | 0 | Fenster-Gebühren | Worker-Gebühren |
+
+Die vier Validatoren sind in diesem Skript **separate, gleichberechtigte Empfängerkonten**, keine Mining-Betreiber. Es gibt keine privaten Schlüssel und keine automatischen Auszahlungen. Das Community-Fonds-Guthaben gilt im Modell als vorerst reserviert. Der Gini-Koeffizient umfasst nur Mining-Betreiber und darf **nicht** zur Gesamtverteilung inklusive Validatoren/Fonds umgedeutet werden.
+
+## Installation und Ausführung
+
+Dieses Paket fügt `scripts/analyze_pop_fee_flows.py` und `tests/test_pop_fee_flows.py` neu hinzu und **ändert die bestehende Cluster-Simulation nicht**.
+
+```bash
+cd ~/src/potatium
+python3 -m unittest discover -s tests -p 'test_pop_fee_flows.py' -v
+python3 scripts/analyze_pop_fee_flows.py \
+  --input ~/potatium-simulation.zip \
+  --out ~/potatium-fee-analysis
+```
+
+Die bisherige ZIP kann alternativ auch als Dateiverzeichnis eingelesen werden: `--input ~/potatium-simulation`.
+
+Eigene prozentuale Verteilung für Worker- und Fenster-Gebühren (Reihenfolge **Burn, Validatoren, Fonds**, Summe 100):
+
+```bash
+python3 scripts/analyze_pop_fee_flows.py \
+  --input ~/potatium-simulation.zip \
+  --custom-worker 0,50,50 --custom-window 0,90,10
+```
+
+Die Ausgabe liegt in `~/potatium-fee-analysis/potatium-fee-analysis.zip` und kann in den Chat hochgeladen werden.
+
+## Rechnung und Invariante
+
+`gesamt_vorher = Genesis + Minting`, `gesamt_nachher = gesamt_vorher - Burn`.
+
+`gesamt_nachher = Miner-Wallets + Validator-Konten + Treasury-Konto`.
+
+Alle vorgegebenen Gebühren bleiben **vollständig vom Miner bezahlt**. Deshalb bleiben bei gleicher Ausgangssimulation die Mining-Ergebnisse und das Netto-Guthaben des Miners gleich, ob eine Gebühr verbrannt oder an externe Empfänger gezahlt wird.
+
+**Diese Analyse rechnet Einnahmen nur buchhalterisch um**. Sie ist keine neue Simulation, wie sich Empfänger später verhalten und die erhaltenen PTM ausgeben. Bei Rückflüssen an Miner, gleichzeitig validatorenden Minern, gedeckelten Guthaben, Fonds-Ausschüttungen und Ein-/Ausstieg von Betreibern muss die eigentliche Mining-Simulation erweitert und erneut ausgeführt werden.
+
+## Nächste Prüfung
+
+- Original-Gebühren ×1 / ×3 / ×5 mit echten konkurrierenden Betreiber-Clustergrößen und mindestens zehn Seeds vergleichen.
+- Auszahlung an Validatoren mit **Überlappung von Validator- und Miner-Rollen** modellieren, inklusive Rückflüssen ins Miningbudget.
+- Fonds mit transparentem Mandat und Auszahlungsregeln simulieren; Nichtnutzung parkt Coins faktisch.
+- Regeln zu Gebührenbelastung, progressiven 90-Tage-Erfolgen und maximal erlaubter Mining-Kapazität getrennt festlegen.
+- Protokoll-ADR erst nach ökonomischer sowie Sicherheitsprüfung erstellen; derzeit nur Forschung.
@@ -30,7 +30,7 @@ Potatium (PTM, vor öffentlicher Nutzung Name/Ticker prüfen) ist eine **eigene,

 Eine PoP-Runde enthält **drei hintereinander liegende Aufgabenfenster** mit einer neuen, pro Identität/Chain/Runde/Fenster gebundenen, begrenzten PoW-Aufgabe. Fenster 1 ist kostenlos, Fenster 2 und 3 freiwillig und **solange kein gültiges Ticket vorliegt** gegen vorherige bestätigte Gebühren nutzbar. Die Gebühren enthalten jeweils fixe Kosten und eine progressive Komponente. Als Maßstab dienen finalisierte PoP-Gewinne der letzten ungefähr 90 Tage pro registrierter Identität/Betreibergruppe, **nicht die aktuelle Wallet-Balance**; alter Erfolg fällt aus der Bemessung heraus, kein permanent fortschreitender Langzeitvorteil.

-Nach dem ersten erfolgreichen Nachweis erhält diese Identität **maximal ein Ticket** und stoppt bis zur nächsten Runde. Lose müssen vor Bekanntwerden eines später verifizierbaren Zufallswerts unwiderruflich feststehen. Die Gebühren für Zusatzfenster werden **verbrannt**; normale Transfergebühren sind zur Validator-Finanzierung vorgesehen, genaue Verteilung offen.
+Nach dem ersten erfolgreichen Nachweis erhält diese Identität **maximal ein Ticket** und stoppt bis zur nächsten Runde. Lose müssen vor Bekanntwerden eines später verifizierbaren Zufallswerts unwiderruflich feststehen. Die Gebühren für Zusatzfenster und Worker werden laut ADR 0007/0008 **zu 100 % in den On-chain-Fonds gebucht und nicht verbrannt**; normale Transfergebühren und Validator-Finanzierung sind noch offen.

 Die **Schwelle, Nonce-Raum, Rundendauer, Fensterlängen, Gebührenhöhe, PTM-Emission, Coin-Maximum, Zufallsbeacon und Validatoranzahl** sind weiter unentschieden. Alle genannten Zahlen aus früheren Beispielen bleiben hypothetisch. Pi-4-Benchmark, Simulation und ein neues ADR sind Pflicht vor Implementierung konsenskritischer PoP-Regeln.

@@ -47,7 +47,7 @@ Die **Schwelle, Nonce-Raum, Rundendauer, Fensterlängen, Gebührenhöhe, PTM-Emi
 1. **M1:** Architektur-/Coin-/PoP-Parameter dokumentieren, Gebühren-/Fairness-Simulation, Pi-4-Benchmark, ADRs akzeptieren.
 2. **M2:** Ledger, Accounts, deterministischer State, Signaturen, Genesis, Nonce, Tests; **parallel funktionale Web-Wallet** nach festgelegter Schnittstelle.
 3. **M3:** CometBFT anbinden (1, danach 4 Validatoren), Synchronisation/Ausfalltests.
-4. **M4:** PoP-Registry, Fenster, signierte Proofs/Gebühren, Ticketcommit, nachweisbare Ziehung, Mint/Burn und Negativtests.
+4. **M4:** PoP-Registry, Fenster, signierte Proofs/Fondsgebühren, Ticketcommit, nachweisbare Ziehung, Mint-/Fonds-Buchungen und Negativtests.
 5. **M5–M6:** Pi-/Office-PC-Builds, Web-Wallet vervollständigen, private Mehrhost-Tests, Doku/Release.

 Jeder Schritt: erst Akzeptanzkriterien, dann kleinste sinnvolle Implementierung, Tests inkl. `gofmt`, `go test ./...`, `go vet ./...`, kurze Dokumentation und Git-Review. Keinen Fortschritt erfinden.
@@ -57,3 +57,23 @@ Jeder Schritt: erst Akzeptanzkriterien, dann kleinste sinnvolle Implementierung,
 Erst **nach M6** dürfen wir getrennte Erweiterungsphasen erwägen: **F1 digitale Sammlerstücke**, **F2 interner PTM-Marktplatz**, **F3 Handelsplattform für fiktive interne Assets mit PTM-Orderbuch, Kursen und Portfolio**, optional **F4 separat gekennzeichnetes Paper-Trading/Börsenlabor**. Diese Phasen sollen PTM als geschlossene interne Währung einen zusätzlichen spielerischen Nutzwert geben, nicht einen angeblichen Fiat-Kurs oder einen Mining-Vorteil erzeugen. Keine implizite Echtgeld-Einlösung, Börsennotierung oder Renditeversprechen.

 **Verbindliche Projektgrenze:** Kein F1–F4-Code vor funktionierender Chain, sicherer Wallet und bestandenem Mehrhost-Testnet. Eigentum/Transaktionen müssen kryptografisch überprüfbar sein, Sammlerbesitz beeinflusst die PoP-Lotterie nicht. Für Asset-Minting, sichere Marktorders, Matching, Gebühren und Rechtliches sind vor Implementierung gesonderte Entscheidungen und ADRs nötig. Details in `docs/ZUKUNFT_OEKOSYSTEM.md` und `docs/decisions/0004-zukunftsvision-internes-oekosystem.md`.
+
+## v0.4-Ergänzung: Installationspakete, Cluster und Betreiberidentität
+
+Vereinbartes Produktmodell: **Hub** = eigenständige Full-Node mit eigener GUI, Browser-Wallet und optionalem PoP-Miner. **Worker** = schlanke Mining-Instanz, Hub-abhängig und ohne separate Geld-Wallet. Multi-Hub-/Worker-Cockpit wird priorisiert; Admin-Web erst später, Admin-CLI ab Bedarf. Wallet-/Node-/Miner-/Betreiber-Identitäten bleiben getrennt. Jeder genehmigte Hub-Miner/Worker bis zu ein Ticket/Runde; alle Gewinne/Fees werden pro `operator_id` zusammengefasst und an registrierte Browser-Wallet-Adresse ausgezahlt. Ein gebührenfreier Hub-Mining-Platz pro Betreiber; weitere miningfähige Hubs dürfen nicht als kostenloser Ausweg dienen.
+
+**Noch zu testen:** Worker-Gebühren je Mining-Runde, Tarife, progressive Stufen vs. Pauschalstufen, maximale Worker pro Betreiber (10 nur Simulationskandidat), Fee-Reserve und Failover. Keine bestehenden PoP-Parameter oder Validatorwahl werden dadurch stillschweigend entschieden. Details: `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md`, ADR 0005.
+
+## Betriebsarchitektur und frühe Beobachtbarkeit (ADR 0006, 25.10.2026)
+
+**Wer betreibt was?** `potatium-dev` bleibt reiner Entwicklungs-/Devnet-LXC. Potatium benötigt zusätzlich aktive CometBFT-Validatoren (1 in erster lokaler Devnet-Phase, später vier für Ausfall-/Mehrhosttests), jeweils mit eigener App-DB und eigener Chain-Datenbank, nicht aber einen zentralen Blockchain-SQL-Server. Validatoren zunächst vom Projektbetreiber, später optional von anderen genehmigten Betreibern. Teilnehmer installieren eigenständig Hub-Full-Nodes und Worker; das Wallet-Keymaterial bleibt clientseitig.
+
+**Neue verbindliche UX-Priorität:** Web-Hub-Cockpit und gesondertes **read-only Network-Admin-Cockpit** parallel zum ersten funktionalen Devnet, mit echten Messwerten und transparentem Nichtverbunden-Zustand. Node-/Validator-Aufsicht darf keine on-chain Schreib-, Coin-, Validator- oder Wallet-Schlüssel besitzen; administrative Änderungen erst per geschützten signierten Aktionen in späterer Phase. Ohne Network Admin läuft der Konsens weiter. Monitoring-Historie/Cache kann eine kleine separate Datenbank verwenden, ist aber nicht autoritativ.
+
+Siehe `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`, `docs/decisions/0006-validator-infrastruktur-und-cockpits-ab-devnet.md`. **Gebührenverwendung nach ADR 0007:** 100 % der PoP-/Worker-Gebühren gehen an den On-chain-Fonds; Höhe/Tx-Gebühren/Fonds-Ausgaben sind weiterhin offen. ADR 0003 bleibt historisch dokumentiert und wurde durch ADR 0007 gezielt präzisiert.
+
+## Netzwerkzugang, Identity Admin und Homelab (ADR 0008)
+
+Vereinbarte Vereinfachung: **kein** verpflichtender `potatium-network`-Service, kein Nutzer-Registrierungsportal und keine zentrale Coin-DB. Ein Hub verbindet sich mit überprüfter Chain-ID/Genesis und direkt konfigurierten CometBFT-Peers. Mining-Rechte werden über On-chain-Registry mit protokollautorisierter Freigabe/Sperre verwaltet. Ab erstem lauffähigem Devnet: eigenständiges echtes Hub-Cockpit und separates Network Admin mit bestätigten Supply-/Burn-/Fonds-/Fees-/Identitäts-/Validatorwerten. **Frühe schreibende Admin-Funktionen ausschließlich signierte Freigabe/Sperre**, erst sobald die Register- und Signaturprüfungen implementiert sind. Monitoring-SQL optional, keine Pflicht-Control-Plane. Fonds: 100 % PoP-/Workergebühren, kein Burn. Tarife und Fonds-Ausgaben offen.
+
+Auswertung: `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md`, die Modelle sind keine Konsensparameter. Infrastrukturplan: `docs/INSTALLATIONSPLAN_HOMELAB.md`, ADR 0008.
@@ -11,7 +11,7 @@
 5. Die Gebührenbasis ist die **nachweisbare, einer registrierten Mining-Identität/Betreiberzuordnung zugerechnete PoP-Gewinnsumme der zurückliegenden ca. 90 Tage**, **nicht** das gerade sichtbare Wallet-Guthaben. Genaues Zeit-/Höhenfenster und Verbundidentitäten noch spezifizieren. Langjährige Aktivität an sich darf keinen permanenten Bonus/Malus auslösen.
 6. Progression: Fenster 3 soll teurer sein und zugleich **deutlich geringeren zusätzlichen Nutzen** als Fenster 2 bieten. **Keine unlimitierten Zusatzchancen, kein Kauf einer weiteren Identität.** Konkrete Tarife und Erfolgswahrscheinlichkeiten erst nach Simulation entscheiden.
 7. Ein qualifizierter Miner erhält **maximal ein Ticket** je Runde. Nur vollständig gültige Proofs aus zulässigen Fenstern zählen. Nach dem ersten gültigen Proof endet die Teilnahme dieser Identität für diese Runde.
-8. Zusatzfenster-Gebühren werden **verbrannt** (aus dem spendierbaren Umlauf entfernt). Normale Transaktionsgebühren sollen die Validatoren finanzieren; Zuteilungsmechanik ist noch offen.
+8. **ADR 0007 gilt:** 100 % der Zusatzfenster- und Worker-Gebühren werden dem On-chain-Community-Fonds gutgeschrieben, 0 % Burn dieser Gebühren. Normale Transaktionsgebühren und Fondsauszahlungen bleiben offen.
 9. Ohne PTM kann jede zugelassene Identität an Fenster 1 teilnehmen. Gebühren und Mining-Erfolg dürfen keine Gewinnergarantie erzeugen.
 10. Registrierte Identität ≠ nachweislich einzigartige physische Maschine oder Person. Für das kleine private Netzwerk zunächst manuelle Freigabe, Audit und Sperrmöglichkeit. Mehrere Geräte/Identitäten und gemeinsamer Betreiber müssen gesondert geregelt werden.

@@ -22,10 +22,10 @@ Runde R beginnt; Identitäten / Regeln / Gebührenbasis werden eingefroren
  Fenster 1: kostenlose, identitätsgebundene PoW-Challenge
       | gültiger Proof? -> 1 Ticket; fertig
       | andernfalls
-  Fenster 2: vorher autorisierte, bestätigte Gebühr verbrennen
+  Fenster 2: vorher autorisierte, bestätigte Gebühr in den On-chain-Community-Fonds buchen (ADR 0007)
       | neue, zuvor unbekannte PoW-Challenge; Proof? -> 1 Ticket; fertig
       | andernfalls
-  Fenster 3: höhere Gebühr vorab verbrennen (Fenster 2 muss zuvor freigeschaltet sein)
+  Fenster 3: höhere Gebühr vorab in den On-chain-Community-Fonds buchen (Fenster 2 muss zuvor freigeschaltet sein)
       | neue PoW-Challenge; Proof? -> 1 Ticket; fertig
       | andernfalls kein Ticket
  Fristende: akzeptierte Tickets endgültig fixieren
@@ -71,3 +71,15 @@ Runde R beginnt; Identitäten / Regeln / Gebührenbasis werden eingefroren
 | P-10 | Registry-Administration, Zweitgeräte-Regel, Validator- und normale Gebührenverteilung |

 **Wichtig:** Zahlen aus älteren Diskussionen wie 70/91/97,3 %, 1 PTM Belohnung, 10 Mio. PTM, 10-s-Blockzeit oder 0,001-PTM-Grundkosten bleiben ausschließlich **Rechenbeispiele**. Sie sind nicht implementiert, beschlossen oder für öffentliche Nutzung freigegeben.
+
+## Ergänzung v0.4: Betreibergruppe, Mining-IDs und Cluster
+
+Die zulassungsfähige Mining-Einheit ist eine `mining_id` mit zugehöriger `operator_id`, Signaturschlüssel und Rollenmerkmal (`hub_miner`, `worker`). **Jede genehmigte Mining-ID erhält maximal ein Ticket je Gesamtrunde**, unabhängig vom Gerätetyp oder Hub-Prozess. `operator_id` aggregiert sämtliche PoP-Belohnungen für die progressive ca. 90-Tage-Fee-Basis; eine registrierte Auszahlungsadresse empfängt alle Rewards. Wallet-/Hub-Wechsel erzeugt keine neue Betreiberhistorie. Pro Betreiber nur **ein** kostenloser Hub-Mining-Platz; weitere miningfähige Hubs zählen bei Worker-Kosten wie Workerslots. Registry-Aufnahme und Revocation bleiben manuell auditierbar.
+
+**Zusätzliche Worker-Aktivierungsgebühren** werden als Konzept weiter untersucht (nicht final). Falls eingeführt, ist eine Teilnahmefreigabe **je PoP-Gesamtrunde** im finalisierten Zustand vor Veröffentlichung der neuen Challenge zu bezahlen/reservieren; sonst könnte die Node zuerst rechnen und nur bei Treffer zahlen. Fenster-2/3-Gebühren sind davon separat und ebenfalls vor Bekanntgabe der neuen Fenster-Challenge fällig. Die Bedienoberfläche muss beide Kostenarten sichtbar trennen. Festzulegen: exakte Gebührenformel in Integer-Basiseinheiten, Snapshot, fee allowance/reserve, Kosten bei Hub-Ausfall, Verbindlichkeit des Aktivierungszeitpunkts, eindeutige Workerzahl und Höchstzahl. **Keinerlei vorgeschlagene Zahlen als endgültige Konsensregeln implementieren.** Siehe ADR 0005.
+
+## ADR 0007: On-chain-Fonds statt PoP-Burn und zentrale Aufnahme
+
+PoP-Fenster-2-/3-Gebühren sowie zulassungs-/rundenbezogene Worker-Aktivierungsgebühren fließen **zu 100 % in den On-chain-Fonds** und werden **nicht verbrannt**. Fonds ist Teil des umlaufenden Supply, nicht zusätzliche Emission; deterministische `fund_balance`-/`fund_collected_total`-/`fund_spent_total`-Buchungen und eine eindeutig definierte Gebührenreservierung/Refund-Regel müssen vor Implementierung festgelegt werden. Normale Transaktionsgebühren und Fonds-Ausgaberechte bleiben offen. Frühere Burn-Angaben in ADR 0003 werden für diese Kategorien durch ADR 0007 ersetzt; Burn-Zähler bleibt für echte eventuelle Burns erhalten.
+
+**ADR 0008 gilt:** Keine verpflichtende zentrale Registrierungsplattform. Hubs synchronisieren per CometBFT-P2P anhand konfigurierter/verifizierter Genesis-/Chain-/Peer-Daten. PoP-Zulassung nur nach autorisierter On-chain-Freigabe, Widerruf signiert/auditiert. Siehe `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und ADR 0008.
@@ -10,7 +10,7 @@

 ## M1: Konsens- und Coin-Regeln **zuerst**

- [x] Produktprinzip für **3 Mining-Fenster**, kostenloses Fenster 1, optionale fixe + progressive Zusatzgebühren für Fenster 2/3, 90-Tage-Mininggewinn als Basis, Burn, max. 1 Ticket dokumentiert (`ADR 0003`).
+- [x] Produktprinzip für **3 Mining-Fenster**, kostenloses Fenster 1, optionale fixe + progressive Zusatzgebühren für Fenster 2/3, 90-Tage-Mininggewinn als Basis und max. 1 Ticket dokumentiert; **Gebührenverwendung durch ADR 0007 auf 100 % Fonds statt Burn geändert** (`ADR 0003`).
 - [ ] Tokenomics mit Coinsupply, Genesis, Belohnung, Basis-Einheiten, Gebührensystem, Signatur-/Adressschema entscheiden.
 - [ ] PoP-Runden/Fenster/Schwierigkeit/Nonce-Räume und Zahlungs-/Finalitätsbedingungen spezifizieren.
 - [ ] Rein analytische, ausdrücklich nicht konsenskritische Simulation (5/10/20/50 Miner), Fairness- und Kostenvergleich.
@@ -36,7 +36,7 @@
 ## M5–M6: Bedienung und privates Mehrhost-Testnet

 - [ ] UX, Explorer/Status, Dokumentation, Linux amd64/arm64-Releases, Sicherung/Recovery.
- [ ] Hosts über mehrere Geräte, Restart/Fault-Tests, Monitoring und Warnungen zur verbleibenden zentralen Registrierung.
+- [ ] Hosts über mehrere Geräte, Restart/Fault-Tests, Monitoring und Ausfallprüfungen des optionalen Admin-Dienstes.

 ## F1–F4: Zukunftsvision, erst nach stabilem M6

@@ -50,3 +50,38 @@ Die folgenden Erweiterungen sind **als spätere Produktideen aufgenommen**, aber
 **Abhängigkeit:** erst funktionsfähige Chain, sichere Web-Wallet, PoP, Mehrhost-Testnet und verifizierte Transaktionssignaturen. Vor jedem F-Schritt: neues ADR, Datenmodell, Sicherheits-/Risikobewertung und eigene Akzeptanztests. Kein Börsenlisting, keine Wert-/Gewinngarantie.

 **Keine Implementierungs- oder Testergebnisse behaupten, die nicht tatsächlich ausgeführt wurden.**
+
+## Ergänzende Arbeitspakete: Hub/Worker und Cluster (ADR 0005)
+
+- [ ] **M1:** `operator_id`, Hub-/Worker-/Mining-Identitäten, Zweckreserve, Gebühren-Snapshot, 1 freier Hub-Mining-Platz/Operator und Mehridentitätsrisiken präzise spezifizieren; Worker-Preise/Obergrenze simulieren; Pi-4-Benchmark.
+- [ ] **M2:** Vollständiger eigenständiger Hub inklusive **echter browserseitiger Wallet** und lokalem Status-Cockpit (keine serverseitigen Wallet-Keys), Devnet/Test-PTM.
+- [ ] **M3:** Full-/Validator-Node-Status und sichere API, 1 dann 4 Validatoren. Worker sind keine Validatoren.
+- [ ] **M4:** Hub-eigener PoP-Miner; Hub-gebundene Worker mit eindeutiger Registrierung, widerrufbarer Pairing-Autorisierung, Pre-Paid-Gebührenfreigabe, fristgerechten Proofs und 1 Ticket/ID/Runde.
+- [ ] **M5:** Multi-Node-/Cluster-Ansicht für eigene Hubs/Worker, native amd64/arm64-Releases; optional später Docker, nicht im Entwicklungs-LXC.
+- [ ] **M6:** Betreiber-/Worker-Recovery, Ausfall/Failover, Mehrhost, Registry-Audit und Admin-CLI/Web nach tatsächlichem Bedarf. Kein öffentlicher Adminzugang.
+
+**Status:** Planung, nichts davon als implementiert markieren. Phase F1–F4 bleibt unverändert nach stabilem Testnet.
+
+## Prioritätsanpassung v0.5: Infrastruktur und echte Cockpits ab Devnet (ADR 0006)
+
+**Diese Aufgaben konkretisieren und priorisieren die Phasen M0–M6; sie ändern keine Emissions-, Mining- oder Gebührenwerte.**
+
+- [ ] **M0/M1:** Systemrollen und klare Datenverantwortung dokumentieren, Protokoll von zentraler Admin/DB-Abhängigkeit freihalten. Read-only Network Admin und Teilnehmer-Hub-GUI als feste frühzeitige Lieferbestandteile festhalten. Bei Gerüstbetrieb ausschließlich „nicht verbunden“, keine simulierte Live-Chain.
+- [ ] **M2, erstes lauffähiges Devnet:** Ein realer Validator/Go-App-Kern, eigenständiger synchronisierender Hub, Web-Wallet sobald sichere Transaktionsschnittstelle definiert, **lokales Hub-Status-Cockpit und separater read-only Network Admin** für Chain-ID, Blockhöhe, letzte Bestätigung, Sync/Fehleranzeige. Noch nicht implementiert.
+- [ ] **M3:** Vier getrennte Validatoren und Netzwerkstatus in beiden Cockpits, AppHash-/Quorum-Überwachung, Restart-/Mehrprozess-Tests. Einheitliche echte Datenquellen und Stale/Offline-Erkennung.
+- [ ] **M4:** Operator-/Mining-Registry, PoP, Gebührenreserve/Worker, Hub-Mining, sichere Pairing- und Fee-Freigabe, Monitoring aller echten Runden und Worker. Schreibende Admin-CLI nur mit Autorisierung.
+- [ ] **M5/M6:** Multi-Hub-Clusteransicht und Mehrhost-Monitoring/Alerting vervollständigen, optionale Admin-Web-Schreibfunktionen *erst danach* nach Rechteprüfung. Native VM/Pi zuerst, Docker optional später. Sicherheits-, Backup-/Recovery-Tests.
+
+Spezifikation: `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`, ADR 0006. In der ursprünglichen M5-Phase ist der **Ausbau** von Status/Explorer gemeint, nicht erst der Start der Cockpits.
+
+## Prioritätsanpassung v0.6: Vereinfachter Netzzugang, Identity Admin und Forschung (ADR 0008)
+
+- [x] **M1 Forschung:** 36 Szenarien (1×/3×/5× Workergebühren, fix/dynamisch, Fonds halten/hypothetisch rückverteilen) in `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md` dokumentiert. **Kein** Ergebnis als verbindliche Coin-/Gebührenregel kodiert.
+- [ ] **M1:** On-chain-Identitäts-/Zulassungs- und Widerrufsmodell, Operator-/Node-/Mining-/Wallet-Schlüsseltrennung, Gebührenreserve und Fonds-Übertragungen in Integer-Basiseinheiten definieren. Bootstrap über überprüfbare lokale Chain-ID/Genesis/Peer-Liste, keine zentrale Benutzer-Registrierung.
+- [ ] **M2:** Ein Validator mit Go-App, eigenständig synchronisierender Hub, funktionsfähige Web-Wallet und **read-only Network Admin ab dem ersten lauffähigen Devnet** mit echten Chain-/Validatorwerten und ehrlichem `nicht verfügbar` für künftige Statistiken. Alle Dienste initial gemeinsam auf `potatium-dev` in getrennten Prozessen möglich.
+- [ ] **M3:** Vier separat konfigurierte Validatoren, AppHash-Tests, physische Hosttrennung später; Admin zeigt Peers/Quorum/Status.
+- [ ] **M4:** On-chain-Operator-/Mining-Registry, manuell genehmigte signierte **Freigabe-/Sperraktionen im Admin** (getrennte Schlüssel/Signatur), Worker-Pairing, PoP und deterministische Fondsbuchung. Kein Backdoor-Guthaben, keine zentrale SQL-Freigabe.
+- [ ] **M5/M6:** Native ARM64/AMD64-Distribution, Multi-Hub-Cluster, reale Pi-/Alt-PC-Mining-Last, optional geschützter `ptm-admin`-LXC und Heartbeat-Historie. Bootstrap-Fallback und Admin-Ausfall ohne Konsensabbruch testen.
+- [ ] **M1 vor Tariffestlegung:** Pi-4-Hashmessungen, mindestens 10 Seeds und heterogene Betreiber-/Sybil-Szenarien, Definition zulässiger Fonds-Ausgaben. Erst danach neues Gebühren-/Emission-ADR.
+
+Die frühere Pflicht-`potatium-network`-Registrierung nach ADR 0007 ist **durch ADR 0008 aufgehoben**. 100 % PoP-Fenster-/Workergebühren für den On-chain-Fonds bleiben beschlossen, 0 % Burn dieser Gebühren. Alle WebGUI-/Ledger-/Admin-Funktionen sind weiterhin **nicht implementiert**.
@@ -13,7 +13,7 @@
 ## Zusatzfenster und Gebühren (PoP v0.2)

 - Miner startet immer ohne PTM mit **kostenlosem Fenster 1**.
- Die Web-Wallet kann (nach Festlegung des Protokolls) optional erlauben, für **Fenster 2/3** eine eng begrenzte Gebühr zu bezahlen. Fixpreis und progressive Gebühr anhand der aus dem finalisierten Chain-State berechneten **Mining-Gewinne der letzten ca. 90 Tage** der zugeordneten Identität/Gruppe anzeigen. Die Zahlung wird **verbrannt**.
+- Die Web-Wallet kann (nach Festlegung des Protokolls) optional erlauben, für **Fenster 2/3** eine eng begrenzte Gebühr zu bezahlen. Fixpreis und progressive Gebühr anhand der aus dem finalisierten Chain-State berechneten **Mining-Gewinne der letzten ca. 90 Tage** der zugeordneten Identität/Gruppe anzeigen. Die PoP-Fenstergebühr wird dem **On-chain-Fonds** zugeführt, nicht verbrannt (ADR 0007/0008).
 - Nutzer sieht vor Autorisierung den **konkreten Preis je Zusatzfenster**, die maximale mögliche Gesamtausgabe, Gebührenrisiken und den Unterschied zwischen Qualifikations- und tatsächlicher Gewinnchance.
 - Gebühr nur nach **explizit signierter** Freigabe für Chain-ID, Miner-ID, Runde, Fenster, Betrag, Ablauf und Nonce. Ggf. später vorsichtig modellierbares widerrufbares Budget statt unbeschränkter Dauerfreigabe. Miner benötigt keine Wallet-Secrets.
 - Vor finaler Gebühren-/Signaturspezifikation alle Zahlungs-Aktionen deaktiviert lassen. Keine automatische Abbuchung nur wegen „Mining aktiviert“.
@@ -22,3 +22,17 @@
 ## Sicherheitstests

 Replay über Runden, falsche Chain-ID, abgelaufene Autorisierung, negative/überlaufende Beträge, divergierende Fee-Snapshots, manipulierte Fees/Proofs, Backup-/Recovery-Fehler und Offline-Stati. Browser-/Go-Kompatibilität der gewählten Signatursuite erst nach ADR garantieren.
+
+## Erweiterung: Operator-Wallet und Hub-/Worker-Mining (ADR 0005)
+
+Die Registrierung eines Hub ist **keine automatisch auf dem Server erzeugte Wallet**. Die Wallet entsteht/importiert und signiert weiterhin **nur im Browser**; Hub/Worker erhalten keine Wallet-Seeds/-Spend-Keys. Alle legitimen PoP-Belohnungen des Hub und seiner Worker werden an eine vom Betreiber autorisierte Auszahlungsadresse gebucht. Normale Benutzer können zusätzliche Wallets führen; damit ändern sich weder Operator-Registry noch progressive 90-Tage-Gewinnhistorie.
+
+Die Wallet muss den **separaten** Betrag für Worker-Aktivierung vor Runde und für Zusatzfenster 2/3 vor neuer Challenge anzeigen. Der Nutzer benötigt eine begrenzte vorab bewilligte Gebührenreserve oder ein widerrufbares Zweckmandat, damit Pi-Worker unbeaufsichtigt minen können, ohne die Wallet privat an Backend/Worker auszuhändigen. Gebühren-/Fonds-Historie (und echte separate Burns, falls vorhanden), Reserve-Restbetrag, Rückzahlung, Obergrenzen und Alarmmeldungen gehören ins Hub-Cockpit. Konkretes Signatur-/Reserveformat bleibt offen. Keine selbsttätigen Abbuchungen ohne klare, widerrufbare Autorisierung.
+
+## Wallet, Hub und Network Admin (ADR 0006)
+
+Ein Hub hat eine **eingebundene Browser-Wallet**, aber keine Pflicht, für jede Full-Node-Instanz eine neue Geld-Wallet zu erzeugen. Eine Betreiber-Auszahlungsadresse kann für mehrere Hub-Miner und Worker gelten; mehrere Browser/Hubs übertragen private Schlüssel nicht automatisch. Ein Network Admin ist **nur beobachtend**, hat keine privaten Wallet-Schlüssel und keine Ausgaberechte. Wallet-Kennzahlen im Hub nur aus echter Chain-Antwort und nach clientseitiger Autorisierung anzeigen; „nicht verbunden“ statt ausgedachtem Guthaben. Siehe `docs/COCKPITS_UND_MONITORING.md`.
+
+## Wallet-Anmeldung ist nicht Mining-Zulassung (ADR 0008)
+
+Wallet-Erstellung/Import funktioniert lokal ohne zentrale Benutzerregistrierung; Wallet-Spend-Keys verbleiben verschlüsselt auf Clientseite. Hub und Worker besitzen eigene technische Identitäten; signierte On-chain-Betreiber-/Mining-Freigabe ist eine eigenständige Berechtigung und wird vom geschützten Network Admin autorisiert. Ein registrierter Betreiber kann mehrere Hubs/Worker einer Auszahlungsadresse zuordnen. Hubs synchronisieren per verifiziertem P2P-Bootstrap ohne zentralen Anmelde-Server. Details: `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md` und ADR 0008.
@@ -0,0 +1,42 @@
+# ADR 0006: Validator-Infrastruktur, getrennte Datenspeicherung und Cockpits ab Devnet
+
+> **Entscheidungsverlauf, Stand v0.6:** Die verpflichtende zentrale `potatium-network`-Control-Plane und ein Registrierungsportal sind durch [ADR 0008](0008-schlanker-netzzugang-admin-und-identitaeten.md) **aufgehoben**. Unverändert gelten das frühe Hub-/Network-Admin-Monitoring, die On-chain-Mining-Registry und 100 % PoP-/Worker-Gebühren für den Fonds. Historische Abschnitte unten dokumentieren den früheren Stand.
+
+**Datum:** 2026-10-25  
+**Status:** Produkt-/Betriebsarchitektur akzeptiert; technische Komponenten und Ports offen
+
+## Kontext
+
+Der Projektbetreiber möchte nachvollziehen, welche Komponenten er neben Entwickler-LXC, Teilnehmer-Hubs und Workern selbst deployen muss. Gleichzeitig sollen Betreiber und Teilnehmer **vom ersten lauffähigen Devnet an** echte Statusinformationen erhalten. ADR 0005 plante Admin-Web zunächst später; das gilt für **schreibende Verwaltung**, nicht mehr für read-only Beobachtung.
+
+## Entscheidung
+
+1. Keine zentrale Blockchain- oder Coin-Datenbank. Potatium benötigt aktive **CometBFT-Validatoren**, jeweils mit eigener Potatium-ABCI++-Anwendung und eigenem lokalen Chain-/App-State. Der Network Admin ist ausdrücklich **nicht** für Konsens/Mining erforderlich.
+2. Erst ein Validator für das Devnet, danach vier mit anfangs fester, autorisierter Validatorgruppe für lokale/multihost Testnet-Tests. Initial betreibt der Projektbetreiber diese Infrastruktur. Die spätere Validatorrolle anderer Teilnehmer ist offen; Mining-Worker werden nicht automatisch Validatoren.
+3. **Potatium Hub** bleibt eine autonome Full Node inklusive Browser-Wallet, lokaler Node-GUI und optionalem Mining; Worker bleiben schlanke, gekoppelte Mining-Agenten ohne eigene Full-Chain-/Wallet-Schlüssel. Mehrere eigene Hubs können in der Teilnehmer-Clusteransicht zusammengefasst werden.
+4. **Ab dem ersten lauffähigen Devnet:** Hub-Cockpit und gesonderter **read-only Network Admin** zeigen echte Werte wie Chain-ID, Blockhöhe, Validator-/Peerstatus, Fehlerzustände. Beim initialen UI-Gerüst ohne Chain ausschließlich ehrliche „nicht verbunden“-Werte. Beide werden parallel zur Kernimplementierung iterativ erweitert, nicht auf M5/M6 verschoben.
+5. Network Admin als kleiner separater Monitoring-Dienst, im Dev-LXC zum Anfang, später optional eigene Management-VM. Optionaler Monitoring-Speicher/SQLite/Zeitreihen ist nur Beobachtung, keine Konsensabhängigkeit. Kein allgemeiner zentraler Hostagent oder öffentliches RPC als Voraussetzung.
+6. Netzwerkweite schreibende Betreiberaktionen bleiben späterer separater Admin-CLI mit gültig signierten On-chain-Autorisierungen vorbehalten. Read-only Admin erhält keine Spend-/Validator-/Operator-Admin-Schlüssel und darf weder Guthaben verändern noch Mining-Gewinner beeinflussen.
+7. Native Deployments `linux/amd64`, `linux/arm64` zuerst, Docker später optional. Dev-LXC ohne Docker, APIs zunächst loopback/SSH-Forward; Multi-Host-Verkehr nur mit dediziertem Sicherheits- und Firewall-Konzept.
+
+## Begründung
+
+Klare Trennung von Konsens, Nutzerbetrieb, Worker-Steuerung und Netzwerkbeobachtung; frühe Fehlersichtbarkeit; keine zentralisierte Coins-Datenbank oder Single Point of Failure; keine versteckte Wallet-Schlüsselübergabe. Die im Hub eingebettete Wallet gehört einem Betreiber, nicht technisch jeder Node. Mehrere Hubs/Worker können dieselbe registrierte Auszahlungsadresse verwenden.
+
+## Alternativen
+
+- Zentraler Masterserver samt SQL-Ledger: abgelehnt, widerspricht dezentrales L1-Konzept.
+- Admin-Cockpit als Voraussetzung für Blockproduktion: abgelehnt, wäre zentrale Verfügbarkeitsabhängigkeit.
+- Admin-Web vollständig erst nach M6: für **Statuslesen** abgelehnt, für sensible Schreibverwaltung weiter zurückgestellt.
+- Jeder Worker als Validator/full node: abgelehnt, Ressourcenaufwand und Rollenvermischung.
+- Jeder Hub zwangsweise Validator: abgelehnt, Full Nodes ohne Abstimmungsrecht sind zulässig.
+
+## Konsequenzen und offene technische Entscheidungen
+
+M1/M2 erhalten neue Akzeptanzkriterien für read-only Node-/Netzwerkstatus. M3 muss Validatorausfall und gleiche App-Hashes verifizieren. Die Monitoring-API und Datenbank, CometBFT-Version, Validator-Key-Verwahrung, Portkonfiguration, Metrikenaufbewahrung und Überwachungsberechtigungen werden vor Implementierung geprüft. Gebührenverwendung (Burn/Validator/Fonds) und Emissionsformeln werden **nicht** durch dieses ADR entschieden; bisherige Burn-Entscheidungen sind durch neuere Simulationen erneut in Diskussion.
+
+**Referenzen:** `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`, ADR 0002/0005 und aktuelle offizielle CometBFT-Dokumentation.
+
+## Spätere Präzisierung
+
+**ADR 0007** konkretisiert: Ein zentraler `potatium-network`-Dienst **ist** für bequemen Bootstrap, Anträge und weltweites/privates Netzwerkinventar vorgesehen. Dessen off-chain Managementdatenbank widerspricht **nicht** dem in ADR 0006 abgelehnten zentralen **Coin-/Blockchain-Master**. Hub und Validatoren synchronisieren unabhängig direkt P2P. Die Gebührenverwendung für PoP-/Worker-Gebühren ist seit ADR 0007 auf **100 % On-chain-Fonds, 0 % Burn** festgelegt.
@@ -0,0 +1,41 @@
+# ADR 0007: Zentrale Network Services als Control Plane und 100 % PoP-Gebühren an On-chain-Fonds
+
+> **Entscheidungsverlauf, Stand v0.6:** Die verpflichtende zentrale `potatium-network`-Control-Plane und ein Registrierungsportal sind durch [ADR 0008](0008-schlanker-netzzugang-admin-und-identitaeten.md) **aufgehoben**. Unverändert gelten das frühe Hub-/Network-Admin-Monitoring, die On-chain-Mining-Registry und 100 % PoP-/Worker-Gebühren für den Fonds. Historische Abschnitte unten dokumentieren den früheren Stand.
+
+**Datum:** 2026-10-25  
+**Status:** Akzeptiert als Produkt-/Betriebsprinzip, **nicht implementiert**. Details zu Login, Registry-Transaktionen, Signaturformat, Fonds-Auszahlungen, Tarifen offen.  
+**Präzisiert:** ADR 0005/0006; **ersetzt die Burn-Verwendung für PoP-/Worker-Gebühren aus ADR 0003**, nicht dessen drei Mining-Fenster oder Ticketregeln.
+
+## Kontext
+
+Im privaten Potatium-Netz ist die dezentrale P2P- und Konsensinfrastruktur nicht automatisch eine bequeme Zugangsverwaltung. Neue Betreiber benötigen authentische Bootstrap-Informationen, einen Registrierungsantrag und eine nachvollziehbare manuelle Genehmigung. Der Netzwerkbetreiber braucht gleichzeitig eine vollständige registrierte Node-Liste und einen lesenden Gesamtüberblick, ohne Datenbanken als Konsensquelle einzuführen. Aggressive PoP-Gebühren-Burns entziehen der geplanten geschlossenen Hobby-Ökonomie Liquidität.
+
+## Entscheidung
+
+1. Zentral betriebene **Potatium Network Services** (Arbeitstitel `potatium-network`) als **Control Plane** für signierte Bootstrap-Konfiguration, Registrierungsvorgänge, Betreiber-/Geräteinventar und Telemetrie; ein geschütztes **read-only Network Admin**-Dashboard ist von Beginn des nutzbaren Devnets an Bestandteil. Für eingeschriebene Benutzer ist keine zentrale Online-Authentisierung je Blockchain-Transaktion erforderlich.
+2. Der zentrale Dienst führt **keine Coin-Datenbank** und kontrolliert keine Blockproduktion. CometBFT-Validatoren und Full Nodes replizieren den maßgeblichen Ledger und genehmigte Betreiber-/Mining-Identitäten auf Chain. Eine zentrale DB darf nur Anträge, Kontaktdaten nach Minimalprinzip, Beobachtungen und Status-Caches enthalten.
+3. **Authentisierung getrennt:** Wallet-Spend-Key bleibt im Browser; `operator_id`, Node-P2P-Key und Mining-/Worker-Key sind andere Schlüsselrollen. Ein Besitzer kann mehrere Hubs/Worker und eine gemeinsame registrierte Reward-Wallet verwenden. Ein Fingerprint allein erlaubt keine Registrierung. Zentraler Antrag benötigt Besitznachweis, Mining-Zulassung erst nach signiertem, finalisiertem On-chain-Verwaltungsakt. Initial manuelle Freigabe mit gesonderter CLI, kein Web-Superuser zum Ledger.
+4. **Bootstrap:** `chain_id`, vertrauenswürdiger Genesis-Hash, signiertes Manifest und Seed-/Persistent-Peer-Liste; Node synchronisiert **P2P direkt**, nicht per zentraler Coin-API. Netz darf private VPN/Peer-Zulassung verwenden. Mehrere unabhängige Seed-Kontaktpunkte/Fallback sind vorzusehen.
+5. **100 % der PoP-Fenster-2-/3- sowie Worker-Aktivierungsgebühren fließen an den deterministischen, On-chain gebuchten Community-Fonds; 0 % Burn für diese Kategorien.** Fondsausgaben benötigen eigene, noch zu spezifizierende Governance/Autorisierung. Normale Transaktionsgebühren bleiben separat offen. Tarife/Emission bleiben offen. `burned_total` wird nicht gelöscht, aber PoP-/Worker-Gebühren erhöhen ihn nicht. Der Fonds wird **nicht** zusätzlich zum Umlauf addiert.
+6. Bereits registrierte Betreiber und Validatoren bleiben ohne zentralen Dienst funktionsfähig, solange ausreichend P2P/Quorum, Hub und Finanzierung vorhanden sind; Registrierungs-Portal und gesamtnetzweites Monitoring fallen ggf. aus. Admin-Ausfall ist **kein Chain-Stopp**.
+7. Das normale Hub-UI zeigt nur das eigene Node-/Wallet-/Cluster-Inventar und freigegebene öffentliche Netzwerkdaten. Registrierte Betreiber-Geräte, Fonds-/Supply-Details, alle beobachtbaren Nodes, Host-Status und Pending-Anträge bleiben **im Betreiber-Admin**.
+
+## Alternativen
+
+- **Nur Peer Discovery/ohne Benutzerverzeichnis:** einfach, aber im privaten Netz unpraktische Zulassung, schlechtes Inventar und schwache Administrierbarkeit.
+- **Zentraler Coin-Server mit SQL-Guthaben:** abgelehnt, unterläuft Blockchain-Finality und schafft Single Point of Failure.
+- **Zentraler Login für jeden Block/Miner-Ticket:** abgelehnt, schafft unnötige Betriebsabhängigkeit und Zensurpunkt.
+- **Automatische Freigabe durch Wallet-Fingerprint:** abgelehnt, Sybil-/Geräteproblem ungelöst.
+- **PoP-/Worker-Gebühren weiterhin verbrennen:** gegenüber 100-%-Fonds verworfen; Burn-Forschung bleibt als Vergleich dokumentiert.
+
+## Konsequenzen
+
+M1: Signatur-/Registry-/Bootstrap- und Fonds-Buchungsmodell spezifizieren, den zentralen Dienst und den Local-App-Store getrennt auswählen. M2: minimalen Network Services/Bootstrap-Dienst mit echtem read-only Network Admin und Hub-Status anbinden; M3: mehrere echte Peers/Seeds und Validatoren; M4: Antrags-/Genehmigungsworkflow und on-chain PoP-Registry, Worker-Registrierung, Gebührenfonds, Negativtests. M5/M6: gesicherter Betreiberbetrieb, Monitoring-Historie, Backup, Redundanz und Recovery. Die Anmeldung/Registrierung ist **nicht gleich** Wallet-Erstellung und **nicht gleich** P2P-Handshake.
+
+## Noch offen
+
+Operator-Signaturschema, Challenge/Response, Portal-Sitzungen, Minimal-Personendaten/Aufbewahrung, private P2P-Netz-Zugangspolitik, exaktes Enrollment-/Revocation-Format, Verantwortlichkeiten mehrerer Admins, Governance/Fonds-Ausgaben, Backend-Technologie (SQLite möglicher Kandidat), Ports, Zertifikatserneuerung, Relaying-/NAT-Szenarien und Sybil-Grenze. Keine der offenen Entscheidungen in Code hineinraten.
+
+**Referenz:** `docs/NETWORK_SERVICES_UND_ONBOARDING.md`, `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`.
+
+**Vertraulichkeitsgrenze:** Die Betreiber-WebGUI darf exklusiv sein; **On-chain-Fakten (Emission, Fondsbestand, Gebühren und ggf. öffentliche Registry) sind für technisch versierte Betreiber eigener Full Nodes grundsätzlich selbst abfragbar**. Ein UI-Verbot schützt keine Blockchain-Daten. Nicht-öffentliche Betreiber-Kontaktinformationen, unveröffentlichte Geräteadressen und vollständige Heartbeat-/Host-Inventare gehören ausschließlich in die geschützte Off-chain-Control-Plane. Wenn diese Daten wirklich geheim bleiben sollen, **nicht** auf eine für Full Nodes replizierte Chain schreiben.
@@ -0,0 +1,42 @@
+# ADR 0008: Schlanker P2P-Netzzugang, On-chain-Identitäten und frühes Betreiber-Cockpit
+
+**Datum:** 2026-10-25  
+**Status:** **Akzeptierte Produkt-/Betriebsentscheidung, nicht implementiert.**  
+**Ersetzt teilweise:** ADR 0007 (verpflichtende zentrale `potatium-network`-Registrierungs-/Bootstrap-Control-Plane). **Bestätigt ausdrücklich:** ADR 0007: 100 % PoP-Fenster-/Worker-Gebühren an On-chain-Fonds, 0 % Burn dieser Gebühren.
+
+## Anlass
+
+Der Projektbetreiber will keine Benutzerplattform, keine zentrale Passwort-/Wallet-Datenbank und keine überflüssigen zentralen Dienste. Gleichzeitig soll ein privates Netzwerk einsehbar und Mining-Identitäten manuell kontrollierbar sein. Die bisherige verpflichtende Registrierungs-Control-Plane aus ADR 0007 würde diese Anforderungen unnötig verkomplizieren.
+
+## Verbindliche Entscheidung
+
+1. **P2P-Zugang ist nicht Benutzerregistrierung.** Ein Hub bekommt lokal eine überprüfbare Chain-ID, Genesis-Prüfsumme und Seed-/Persistent-Peer-Konfiguration. Nodes synchronisieren Blockchain direkt über CometBFT. Kein `potatium-network`-Dienst, Login, zentrale SQL-Datenbank oder Online-Genehmigung für regulären Blockchain-Sync zwingend.
+2. **On-chain-Mining-Registry bleibt Pflicht für PoP.** Betreiberidentität (`operator_id`), öffentliche Hub-/Worker-/Mining-Schlüssel, Betreiberzuordnung, eine registrierte Reward-Adresse, Berechtigung, Sperr-/Widerrufsstatus und Audit sind deterministisch im Chain-State. Eine lokale `node.toml` o. Ä. kann Identitäten angeben, **aber keine eigene Berechtigung herbeikonfigurieren**. Kopieren von Schlüsseln, VMs oder Wallets erzeugt nicht automatisch neue gültige Tickets.
+3. **Freigaben und Sperren sind die einzigen frühen schreibenden Betreiberfunktionen.** Ein Betreiber/Worker liefert einen öffentlichen Schlüssel mit Besitznachweis; der Netzwerkbetreiber prüft Anträge/Schlüssel zunächst manuell und autorisiert On-chain-Verwaltungsaktionen mit separater geschützter Signierinstanz/CLI. Sobald ausreichend abgesichert, darf das Admin-Cockpit den Freigabe-/Sperrvorgang **auslösen**, aber die schreibende Freigabe ist nie eine reine DB-Flag-Änderung. Das genaue Signatur-/Rechteschema und die Übermittlung sind M1/M4-Protokollaufgaben. Keine pauschalen Ledger-Admin-Sonderrechte.
+4. **Network Admin ab erstem lauffähigen Devnet, Hub-Cockpit parallel.** Getrennter Betreiberzugang. Das Betreiber-Cockpit liest Chain-ID, Blockhöhe, Validatoren, bestätigte Emission, verbrannte Gesamtmenge, Fondsbestand und Bewegungen, Gebühren- und Fensterparameter, Betreiber-/Mining-Registry, angemeldete IDs/Status. Keine Fake-Werte. Identitätsverwaltung zeigt den Antrags-/Genehmigungszustand, sobald der jeweilige Datenpfad existiert. Bei noch nicht implementiertem State ehrlich „nicht verfügbar“.
+5. **Statuszählungen trennen:** on-chain registriert ≠ P2P-kürzlich beobachtet ≠ signiert meldend ≠ tatsächlich minend. Globales Live-Inventar ist ohne freiwillige signierte Heartbeats oder eine dedizierte Beobachtungsinfrastruktur nicht vollständig. **Optionaler Telemetrie-/Inventarspeicher** (z. B. SQLite) ist zulässig, aber keine Pflicht und nicht Konsensquelle. Datenherkunft, Messzeit und Abdeckungsgrad immer ausgeben.
+6. **Hub und Worker** bleiben die zwei Teilnehmerpakete. Hub = eigenständige Full Node mit lokaler Node-/Cluster-GUI, Web-Wallet mit browserseitigen Spend-Keys und optionalem Miner. Worker = an Hub gebundener schlanker Mining-Agent mit eigenem Mining-Key, ohne Full-Chain-/Spend-Key. Gemeinsam zugelassene Betreiber-Einnahmen und -Gebühren, maximal ein Ticket je zugelassener Mining-ID und Runde. Höchstens ein kostenloser Hub-Mining-Platz je genehmigtem Betreiber; Sybil-Risiko bleibt ohne manuelle Prüfung.
+7. **Fonds**: 100 % der PoP-Zusatzfenster- und Workergebühren werden dem on-chain Fonds zugeschrieben. Fondsausgaben, Tarif- und Transaktionsgebührenentscheidung weiterhin offen. Das Admin-Cockpit darf nicht eigenmächtig Fonds-PTM transferieren.
+8. **Deployments:** zuerst `potatium-dev` allein mit isolierten Devnet-Prozessen; später getrennte Validatoren und nach Bedarf geschützter `ptm-admin`-LXC. Weder die Administration noch ein optionale Statussammler darf Konsens/PoP-Gültigkeit blockieren. Native VM/Pi zuerst, Docker optional später.
+
+## Alternativen
+
+- Pflichtdienst `potatium-network` für Anmeldung/Bootstrap/Mining: **verworfen** (unnötiger Single Point of Failure und Nutzerverwaltung).
+- Nur lokale Node-Konfiguration für PoP-Rechte: **verworfen** (beliebig vermehrbare Node-/Mining-IDs).
+- Volle Web-Administration ab Projektstart: **verworfen** (Signatursicherheit nicht ausreichend spezifiziert); reine Beobachtung plus begrenzte genehmigende/sperrende Aktion sobald kryptografisch korrekt.
+- Zentraler Ledger/SQL-Master: **verworfen**.
+
+## Akzeptanzbedingungen
+
+- Hub synchronisiert über mehrere bootstrapfähige Peers, auch wenn Network Admin offline ist; authentischer Genesis-/Chain-ID-Abgleich.
+- Ohne finale On-chain-Freigabe kein Ticket, Sperre wirkt ab spezifizierter Höhe; Replay/Double-Enroll/Schlüsselkopie mit Negativtests behandeln.
+- Admin-Ansicht zeigt reale Supply-/Burn-/Fund-/Registry-Werte, Datenquelle, Blockhöhe, Messzeit, Stale-Zustand; nie simulierte Live-Werte.
+- Signierende Admin-Schlüssel niemals im lesenden Webserver, im Hub oder Worker; signierte Admin-Aktionen auditieren.
+- Operator-/Wallet-/Node-/Worker-/Validator-Schlüssel getrennt, keine privaten Wallet-Schlüssel auf Servern.
+- Keine zentrale Datenbankänderung kann Guthaben, PoP-Registry, Fonds oder Validatorzustand ersetzen.
+
+## Offene Implementierungsparameter
+
+Kompatible CometBFT-Version, Embedded-State-DB, Ports, Go-API, Operator-Schlüsselschema, pairing/binding-Verfahren, Admin-Signaturschema, On-chain-Antragstransport, IP/Peer-Schutz, vollständige Telemetrie, Wallet-Integration, Rücksetzbarkeit des Devnets. Keine Werte durch einen Codegenerator eigenmächtig entscheiden.
+
+**Referenzen:** `docs/NETWORK_ZUGANG_UND_IDENTITAETEN.md`, `docs/COCKPITS_UND_MONITORING.md`, `docs/INSTALLATIONSPLAN_HOMELAB.md`, `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md`.
@@ -0,0 +1,13 @@
+worker_scale,worker_mode,fund_mode,seeds,fund_balance,fund_pct_supply,fund_distributed,fund_worker_in,fund_window_in,minted,gini_wallets,avg_workers_total,newcomer_wins,newcomer_net_daily,incumbent_net_daily,capacity_0_net,capacity_0_wallet,capacity_0_gross,capacity_0_rebate,capacity_0_activated,capacity_1_net,capacity_1_wallet,capacity_1_gross,capacity_1_rebate,capacity_1_activated,capacity_3_net,capacity_3_wallet,capacity_3_gross,capacity_3_rebate,capacity_3_activated,capacity_5_net,capacity_5_wallet,capacity_5_gross,capacity_5_rebate,capacity_5_activated,capacity_8_net,capacity_8_wallet,capacity_8_gross,capacity_8_rebate,capacity_8_activated,capacity_10_net,capacity_10_wallet,capacity_10_gross,capacity_10_rebate,capacity_10_activated
+1.0,dynamic,hold,3,31000.9627,23.9205,0.0,28618.8737,2382.089,129600.0,0.35426,94.9258,15573.667,24.9277,24.2727,1184.4618,1184.4618,1328.0833,0.0,0.0,2123.8369,2123.8369,2356.9167,0.0,0.9995,4017.5246,4017.5246,4506.4444,0.0,2.9989,5361.3234,5361.3234,6619.4444,0.0,4.9964,7216.1895,7216.1895,9888.0,0.0,7.9895,8121.0838,8121.0838,12081.5556,0.0,9.9972
+1.0,dynamic,redistribute,3,13130.7071,10.1317,17870.2555,28618.8737,2382.089,129600.0,0.30471,94.9258,15573.667,24.9277,24.2727,1184.4618,1960.3123,1328.0833,775.8505,0.0,2123.8369,2899.6874,2356.9167,775.8505,0.9995,4017.5246,4793.3751,4506.4444,775.8505,2.9989,5361.3234,6137.1739,6619.4444,775.8505,4.9964,7216.1895,7992.04,9888.0,775.8505,7.9895,8121.0838,8896.9343,12081.5556,775.8505,9.9972
+1.0,fixed,hold,3,31000.9627,23.9205,0.0,28618.8737,2382.089,129600.0,0.35426,94.9258,15573.667,24.9277,24.2727,1184.4618,1184.4618,1328.0833,0.0,0.0,2123.8369,2123.8369,2356.9167,0.0,0.9995,4017.5246,4017.5246,4506.4444,0.0,2.9989,5361.3234,5361.3234,6619.4444,0.0,4.9964,7216.1895,7216.1895,9888.0,0.0,7.9895,8121.0838,8121.0838,12081.5556,0.0,9.9972
+1.0,fixed,redistribute,3,13130.7071,10.1317,17870.2555,28618.8737,2382.089,129600.0,0.30471,94.9258,15573.667,24.9277,24.2727,1184.4618,1960.3123,1328.0833,775.8505,0.0,2123.8369,2899.6874,2356.9167,775.8505,0.9995,4017.5246,4793.3751,4506.4444,775.8505,2.9989,5361.3234,6137.1739,6619.4444,775.8505,4.9964,7216.1895,7992.04,9888.0,775.8505,7.9895,8121.0838,8896.9343,12081.5556,775.8505,9.9972
+3.0,dynamic,hold,3,52603.6148,40.5892,0.0,49515.871,3087.7438,129600.0,0.24586,73.0943,15471.333,19.4428,18.9575,1401.5994,1401.5994,1628.25,0.0,0.0,2317.8133,2317.8133,2827.5,0.0,0.9993,4111.283,4111.283,5394.1111,0.0,2.9987,4409.7564,4409.7564,7942.6667,0.0,4.9387,4640.5973,4640.5973,9387.8889,0.0,5.9871,4628.1886,4628.1886,9377.2222,0.0,5.9898
+3.0,dynamic,redistribute,3,21442.5825,16.5452,31161.0323,49515.871,3087.7438,129600.0,0.18946,73.0943,15471.333,19.4428,18.9575,1401.5994,2762.1606,1628.25,1360.5611,0.0,2317.8133,3678.3745,2827.5,1360.5611,0.9993,4111.283,5471.8441,5394.1111,1360.5611,2.9987,4409.7564,5770.3176,7942.6667,1360.5611,4.9387,4640.5973,6001.1584,9387.8889,1360.5611,5.9871,4628.1886,5988.7497,9377.2222,1360.5611,5.9898
+3.0,fixed,hold,3,85362.78,65.8663,0.0,82933.581,2429.199,129600.0,0.32795,92.4115,13460.667,8.769,11.192,1192.9846,1192.9846,1348.8333,0.0,0.0,1901.9854,1901.9854,2393.1667,0.0,0.9993,3332.4923,3332.4923,4596.0,0.0,2.996,3168.1911,3168.1911,6755.4444,0.0,4.9956,2245.5886,2245.5886,10092.2222,0.0,7.988,557.498,557.498,12280.1111,0.0,9.9864
+3.0,fixed,redistribute,3,37673.5072,29.0691,49740.6412,85006.161,2407.9874,129600.0,0.18972,94.185,14955.667,7.4858,10.7826,1177.4129,3331.422,1328.0,2154.0091,0.0,1877.9021,4031.9112,2369.0833,2154.0091,0.9993,3289.0478,5443.057,4552.5556,2154.0091,2.996,3044.9689,5198.9781,6632.2222,2154.0091,4.9956,2102.8108,4256.82,9949.4444,2154.0091,7.988,428.498,2582.5071,12151.1111,2154.0091,9.9864
+5.0,dynamic,hold,3,34750.0621,26.8133,0.0,30255.565,4494.4971,129600.0,0.22236,46.2116,15111.667,23.505,23.4091,1956.2867,1956.2867,2230.3333,0.0,0.0,3051.4123,3051.4123,3886.5833,0.0,0.9995,5386.176,5386.176,7491.6667,0.0,2.9992,5360.7506,5360.7506,7523.8889,0.0,3.0235,5319.4582,5319.4582,7484.5556,0.0,3.0253,5347.5764,5347.5764,7506.7778,0.0,3.0255
+5.0,dynamic,redistribute,3,14347.7968,11.0708,20402.2652,30255.565,4494.4971,129600.0,0.19161,46.2116,15111.667,23.505,23.4091,1956.2867,2845.2417,2230.3333,888.955,0.0,3051.4123,3940.3673,3886.5833,888.955,0.9995,5386.176,6275.131,7491.6667,888.955,2.9992,5360.7506,6249.7056,7523.8889,888.955,3.0235,5319.4582,6208.4132,7484.5556,888.955,3.0253,5347.5764,6236.5314,7506.7778,888.955,3.0255
+5.0,fixed,hold,3,90985.0921,70.2045,0.0,87811.1967,3173.8954,129600.0,0.46911,66.0563,13671,8.2827,9.691,1530.1551,1530.1551,1755.5833,0.0,0.0,2262.2745,2262.2745,3048.9167,0.0,0.9994,3809.6369,3809.6369,5880.0,0.0,2.9966,2744.0213,2744.0213,8691.6667,0.0,4.9983,17.5649,17.5649,12498.4444,0.0,7.6456,1.4354,1.4354,5166.8889,0.0,2.6287
+5.0,fixed,redistribute,3,46355.6195,35.7682,60290.02,103694.88,2950.7595,129600.0,0.31169,74.5228,14317.667,2.2037,6.1007,1423.9797,4031.1171,1606.0833,2607.1374,0.0,2084.6015,4691.7389,2869.25,2607.1374,0.9994,3452.101,6059.2384,5520.0,2607.1374,2.9966,2179.3546,4786.492,8127.0,2607.1374,4.9983,-999.8246,1607.3129,11878.8889,2607.1374,7.8911,-1988.8431,618.2943,6934.4444,2607.1374,4.5586