Polkadot

Polkadot ist ein Multi-Chain-Netzwerkprotokoll, das viele spezialisierte Blockchains („Parachains“) mit einer zentralen Relay Chain verbindet. Die Relay Chain stellt gemeinsame Sicherheit, Konsens und kettenübergreifende Interoperabilität bereit, während die Parachains parallel laufen und über Polkadots Cross-Consensus Messaging (XCM) kommunizieren. Das Design zielt auf Skalierbarkeit und Komponierbarkeit von Blockchains innerhalb eines Netzwerks ab.

In Polkadots Architektur sind Parachains anwendungsspezifische Chains, deren Blöcke von Collators erzeugt und von Relay-Chain-Validatoren geprüft werden. Durch die Anbindung an die Relay Chain erben Parachains die ökonomische Sicherheit des Validatoren-Sets und können Nachrichten mit anderen Chains über XCM austauschen. Bridges können Polkadot zudem mit externen Netzwerken verbinden – beispielsweise Ethereum über Snowbridge; die Anbindung an Bitcoin erfolgt durch Parachains wie Interlay statt über eine native Light-Client-Bridge. Operative Details zur Cross-Chain-Kommunikation finden Sie im dedizierten Abschnitt zu XCM.

DOT ist der native Token des Netzwerks auf der Relay Chain. Laut Polkadots Spezifikation unterlegt er drei Kernfunktionen: Governance des Protokolls, Staking zur Netzwerksicherheit sowie Bonding (historisch zur Hinzufügung neuer Chains verwendet).

Das Ressourcenmodell von Polkadot entwickelt sich mit „Polkadot 2.0“ weiter. Projekte mieten nun Compute-Leistung der Relay Chain nicht mehr über langfristige Slots, sondern erhalten Coretime („Zeit auf virtuellen Kernen“). Coretime wird System Chains durch Governance zugeteilt und von anderen Chains auf dem offenen Markt erworben.

DOT ist der native Token der Polkadot Relay Chain und bildet die Grundlage für zentrale Netzwerkfunktionen:

Netzwerksicherheit via Staking (NPoS): DOT-Besitzer können Validatoren nominieren oder selbst einen Validator betreiben, um bei der Block-Finalisierung zu helfen und das System ehrlich zu halten. Gestakte DOT sichern das Verhalten von Validatoren und bringen Staking-Belohnungen; Fehlverhalten kann durch Slashing bestraft werden. Siehe: Nominated Proof-of-Stake und Slashing für Mechanik und Risiken.

On-Chain-Governance (OpenGov): DOT wird verwendet, um Referenden in mehreren „Tracks“ vorzuschlagen und darüber abzustimmen, Stimmrechte zu delegieren und an Protokoll-Upgrades und Entscheidungen zu System Chains teilzunehmen. Siehe: OpenGov und Wie können Nutzer an der Governance teilnehmen… für Details zu Tracks, Einzahlungen und Delegation.

Netzwerkgebühren und erforderliche Einlagen: Transaktionen auf der Relay Chain verursachen Gebühren, die in DOT bezahlt werden, und Accounts müssen einen Mindestguthaben („Existenzielle Einlage“) vorhalten, um aktiv zu bleiben. Manche On-Chain-Aktionen erfordern zudem rückzahlbare DOT-Einlagen (z. B. Identität). Siehe: Welche On-Chain-Utilities bietet DOT... für Gebührentypen und Einlagen.

Erwerb von Relay-Chain-Compute („Coretime“) in Polkadot 2.0: Projekte erhalten Ausführungszeit auf den Kernen der Relay Chain, indem sie Coretime mit DOT kaufen; diese DOT werden verbrannt. Dieses Modell ersetzt langfristige Slot-Leases/Crowdloans. Siehe: Was ändert sich mit Polkadot 2.0… und Wie kann ein Team eine Chain starten… für Ökonomie und Wege zur Implementierung.

Systemfinanzierung über die On-Chain-Treasury: Zuflüsse in die Treasury (Teil der Block-Belohnungen, Gebühren, Tipps, Slashes) sind in DOT denominiert und dürfen — via Governance — auf genehmigte Vorschläge verwendet werden. Siehe: Wie funktioniert die On-Chain-Treasury… für Prozess und Umfang.

Cross-Chain-Transfers und Ökosystemnutzung: DOT kann mittels XCM zwischen der Relay Chain und System-Parachains wie Asset Hub teleportiert werden; Cross-Chain-Transfers können auf Quell- und Zielchain Gebühren verursachen. Einige Parachains/Apps akzeptieren DOT nativ; andere fordern eine gebridgte/gewrapte Version. Siehe: Asset Hub und Wie interagiert DOT mit anderen Netzwerken… für Spezifika.

Wenn Sie die genauen Gebührentypen, Minimums, Einlagen und Stakingprozesse suchen, lesen Sie weiter in „Welche On-Chain-Utilities bietet DOT (Staking, Fees, Governance und Deposits)?“

DOT verwendet eine feste jährliche Ausgabe, die zum Start bei ca. 8 % der Gesamtmenge lag und seither konstant ~120 Millionen DOT pro Jahr beträgt. Dadurch sinkt die prozentuale Inflationsrate, während die Gesamtmenge wächst. Von jeder Jahresausgabe werden 15 % direkt an die Treasury gemünzt und 85 % finanzieren Staking-Belohnungen (pro Era ausgezahlt). Diese Parameter wurden durch OpenGov (Referendum #1139) eingeführt und im Runtime-Code implementiert.

Emissionsprozess und Verteilung: Neue DOT werden laufend erzeugt und zum Ende jeder Era (~24 h auf Polkadot) bilanziert. Die Verteilung erfolgt an Validatoren und Nominatoren gemäß dem Staking-Belohnungsmechanismus; der Treasury-Anteil von 15 % wird direkt auf das Systemkonto gemünzt. Im Fixed-Issuance-Modell wird diese Aufteilung nicht mehr durch die Staking-Beteiligung angepasst, was Rewards im Vergleich zum vorherigen Design vereinfacht.

Burns, die die Bruttoemission ausgleichen: Zwei Quellen verringern das Nettowachstum des Angebots: Coretime-Käufe (in Polkadot 2.0) werden verbrannt, und die Treasury kann Mittel auch via Governance verbrennen. Die tatsächliche Jahresinflation entspricht somit der festen Emission (~120 M DOT) minus der pro Jahr verbrannten Beträge.

Unterschiede zum vorherigen Modell: Vor der Änderung 2024 zielte Polkadot auf ca. 10 % jährliche Inflation, wobei Rewards anhand einer „ideal“-Staking-Quote moduliert wurden; ein möglicher Überschuss floss an die Treasury („Staking Inefficiency“). Das neue Modell entfernt diese Anpassung und ersetzt sie durch den festen 15 %-Treasury-Anteil.

Kein Hard Cap (Governance gesteuert): DOT hat keine im Protokoll festgelegte maximale Gesamtmenge. Emissionsparameter können per On-Chain-Governance geändert werden; die Updates 2024–2025 erfolgten auf diese Weise. Aktuelle Einstellungen und Änderungsvorschläge finden Sie in den relevanten OpenGov-Referenden.

2020 Redenomination (nur Einheit, kein Wertverlust): Am 21. August 2020 („Denomination Day“, Block #1.248.328) wurde DOT umbenannt mit 1 altem DOT = 100 neuem DOT. Dies war eine Änderung der Einheit, nicht des Werts oder Besitzes: Guthaben und Preise skalierten um das 100-fache, die Basiseinheit (Planck) pro DOT wandelte sich von 10¹² auf 10¹⁰ Planck. Die wirtschaftlichen Rahmenbedingungen blieben unverändert.

Staking (Netzwerksicherheit): DOT kann gebondet werden, um das Netzwerk im Rahmen von Nominated Proof-of-Stake (NPoS) zu sichern. Inhaber nominieren entweder Validatoren oder betreiben selbst einen Validator; Belohnungen werden pro Era gezahlt, Fehlverhalten wird (via Slashing) bestraft. Das Validatoren-Set wird per Phragmén-Algorithmus gewählt, Nutzer können auch über Nomination Pools teilnehmen — eine Option mit geringerem Eintrittsbetrag. Spezielle Mechanismen wie Unbonding-Fristen, Slashing-Bedingungen und Wahldetails sind im NPoS- und Slashing-Abschnitt erläutert.

Gebühren (Transaktionskosten): Auf der Relay Chain zahlen Transaktionen Gebühren in DOT, die vom frei verfügbaren Guthaben abgezogen werden (nicht vom gebondeten Anteil). Die Gebühren setzen sich zusammen aus Base Fee, Length Fee und einer gewichtsbasierten Fee, außerdem kann ein optionales Tipp das Einschluss-Prioritätslevel erhöhen. Ein Congestion Multiplier passt Gebühren anhand der Blockauslastung nach oben oder unten an. Wallets zeigen die geschätzte Gebühr an, bevor Sie signieren.

Cross-Chain-Aktionen ziehen ggf. auf Quell- und Zielchain Gebühren nach sich. Beim Teleportieren von DOT zwischen Relay Chain und Asset Hub fällt z. B. eine Zielkettengebühr an; der „Keep-Alive“-Schutz greift dabei nicht, so dass das Zielguthaben den Mindestwert übersteigen muss, um ein Reaping zu vermeiden.

Governance (OpenGov): DOT wird verwendet, um in OpenGov Referenden zu initiieren oder darüber abzustimmen. Vorschläge verlangen eine Decision Deposit; die Abstimmung erfolgt mit convictions-basierten Balancen (Tokens werden zur Gewichtserhöhung zeitlich gesperrt). Nutzer können Stimmrechte — auch track-spezifisch — delegieren. Operationelle Details (Voting, Delegation, Sperren verwalten) sind im Abschnitt zu OpenGov dargestellt.

Einlagen und Mindestguthaben: Polkadot fordert eine existenzielle Einlage (ED) — ein Mindestguthaben, damit ein Konto aktiv bleibt. Fällt das freie Guthaben darunter, kann das Konto „gereaped“ und Staub verbrannt werden. Der aktuelle Wert liegt bei 1 DOT auf der Relay Chain bzw. 0,01 DOT auf Asset Hub (werte chain-spezifisch, änderbar durch Governance). Keep-alive-Prüfungen schützen vor versehentlichem Reap beim Senden; Teleports bieten diesen Schutz nicht.

Bestimmte Funktionen erfordern reservierte Einlagen (Bonds), die solange gehalten werden, wie die Funktion aktiv ist und meist zurückerstattet werden, wenn diese aufgehoben wird. Beispiel: On-Chain-Identität, nun verwaltet auf der People-Parachain, erfordert eine rückzahlbare Einlage plus eine Registrar-Gebühr; bei Löschung der Identität wird die Einlage freigegeben (Mittel liegen bis zum Teleport zurück auf People). Governance-bezogene Einlagen (z. B. Decision Deposits) siehe im Abschnitt zur Governance.

Die Relay Chain ist Polkadots zentrale Chain. Sie gewährleistet Netzwerksicherheit und globalen Konsens und ist bewusst in der Anwendungslogik minimal gehalten: Ihre Aufgabe ist es, viele parallele Chains zu koordinieren, nicht Endnutzeranwendungen selbst auszuführen. Im Polkadot-Design garantiert die Relay Chain eine einheitliche, global konsistente Sicht auf den Zustand über alle angebundenen Shards („Parachains“).

Parachains sind anwendungsspezifische Chains, die parallel laufen und an die Relay Chain angebunden sind. Sie verwalten eigenen Zustand und Logik, erben aber Sicherheit vom Validatoren-Set der Relay Chain. Parachain-Nodes, die sogenannten Collators, sammeln Transaktionen und fertigen Kandidatenblöcke mit Nachweisen an; Relay-Chain-Validatoren prüfen danach auf Verfügbarkeit und Gültigkeit, bevor diese Parachain-State-Transitions in den Shared State aufgenommen werden. Diese Trennung lässt die Parachains spezialisieren, während die Relay Chain Konsens, Finalität und Koordination übernimmt.

Parachains können mittels Polkadots Cross-Consensus Messaging (XCM) untereinander kommunizieren, wobei die Relay Chain die Routing-/Validierungsschicht koordiniert, damit Chains sicher Daten und Assets austauschen können. Die Funktionsweise von XCM ist im entsprechenden Abschnitt detailliert.

Polkadot betreibt außerdem System-Parachains für Kernprotokollfunktionen, z. B. Asset Hub für fungible und nicht-fungible Assets — so lagern Funktionen von der Relay Chain aus, nutzen aber weiterhin deren Sicherheit. System Chains werden per On-Chain-Governance vergeben.

Mit Polkadot 2.0 greifen Projekte auf Relay-Chain-Compute über Cores („Coretime“) zu. System Chains erhalten Cores über Governance, andere Chains erwerben Coretime auf dem offenen Markt; das Grundverhältnis bleibt: Parachains führen ihre Logik aus, die Relay Chain validiert und finalisiert.

XCM (Cross-Consensus Messaging) ist Polkadots Sprache zum Versand von Intent-basierten Nachrichten zwischen Konsenssystemen (Relay Chain, Parachains und — über Bridges — andere Netzwerke). XCM beschreibt, was passieren soll, unabhängig von spezifischer Runtime-Logik. XCMP (Cross-Chain Message Passing) ist das Transportprotokoll für Parachain↔Parachain-Nachrichten; Relay↔Parachain-Traffic nutzt UMP (Upward) und DMP (Downward). Nachrichten sind asynchron.

Transfers: Die zwei nativen XCM-Muster

• Teleport: Vermögen wandert direkt zwischen vertrauenswürdigen Orten ohne Reserve-Chain. Typisches Beispiel: DOT zwischen Relay Chain und Asset Hub. Teleports erfordern gegenseitige Trust-Konfiguration.
• Reserve-basierter Transfer: Die Reserve-Chain verwaltet den Gesamtbestand; der Ursprung sperrt/verbrennt eine Repräsentation, die Reserve passt das Guthaben an, das Ziel prägt/bucht eine Repräsentation. Dieses Muster ist typisch für das Verschieben von Assets auf Parachains, die nicht die Reserve sind.

In der Praxis bevorzugen Teams oft Reserve-Transfers wegen der Sicherheits- und Buchhaltungsvorteile; Teleports sind meist nur für streng autorisierte Routen aktiviert (für DOT: Relay Chain ↔ Asset Hub).

Channels und Routing: Parachain↔Parachain-Nachrichten laufen über Channels. Aktuell nutzen die meisten Netzwerke HRMP (Horizontal Relay-routed Message Passing), das das gleiche Interface wie XCMP bietet, aber Nachrichten in der Relay Chain speichert; XCMP ist der effizientere Endzustand. HRMP-Kanäle sind unidirektional; vollständige Zweiwegekommunikation erfordert pro Richtung einen Channel und muss von beiden Chains geöffnet/akzeptiert werden.

Fees, Weight und Ausführung: Ein XCM muss die Ausführung auf der Zielkette „einkaufen“ (gegen Weight, sprich Compute bezahlen). Welche Assets als Fee akzeptiert werden und wie viel Weight verlangt ist, bestimmt die Zielchain. Standardextrinsics sind z. B. teleport_assets und reserve_transfer_assets, die Ziel, Empfänger, Assets und Fee-Asset spezifizieren.

Nutzerverhalten und Schutzmaßnahmen:

• Existenzminima & Keep-Alive: Teleports prüfen „Keep-Alive“ nicht. Achten Sie auf ein Nach-Gebühr-Guthaben am Ziel ≥ Existenzminimum, sonst kann das Konto gereaped werden. Teleports enthalten stets eine Ziel-Chain-Gebühr.
• Asynchronität & Reihenfolge: Lieferung ist nicht instantan; Reihenfolge ist nur innerhalb eines Channels garantiert.

Für Bridges zu externen Netzwerken und Wrapped DOT siehe den Abschnitt zur Interoperabilität weiter unten.

Asset Hub ist Polkadots System-Parachain (früher „Statemint“) für das Ausgeben, Halten und Übertragen von Assets — einschließlich fungibler Tokens und NFTs. Asset Hub ist eine Common-Good-Kette mit niedrigeren Gebühren und kleinerer existenzieller Einlage als die Relay Chain und verwendet DOT als nativen Token für Gebühren und Einlagen. Der Existenzial-Deposit beträgt hier 0,01 DOT (zehnmal weniger als auf der Relay Chain), und Assets können als sufficient (kein DOT-Guthaben notwendig) oder non-sufficient (Account muss das DOT-Minimum erfüllen) markiert werden.

Betrieblich ist Asset Hub der Ort, an dem Nutzer und Teams Assets erzeugen, Metadaten verwalten und Transfers ausführen; offizielle Anleitungen empfehlen sie auch als günstige Plattform für Non-Native Tokens und NFTs. (Kusamas Asset Hub erlaubt Smart-Contracts; auf Polkadot sind native EVM/PVM-Smart-Contracts auf der Polkadot-Hub-System-Chain geplant, nicht auf Asset Hub.)

Wann lohnt sich das Teleportieren von DOT?

Das Teleportieren ist der vertrauenswürdige XCM-Weg Relay Chain ↔ Asset Hub für DOT. Es ist nützlich, wenn DOT auf Asset Hub benötigt wird, beispielsweise um:

• Niedrigere Gebühren zu zahlen oder das 0,01 DOT-Existenzminimum für „non-sufficient“ Assets zu erfüllen, oder
• Features und Anwendungen zu nutzen, die auf Asset Hub laufen.

Wichtige Verhaltensregeln vor dem Teleport:

• Von der teleportierten Menge wird die Zielkett-Gebühr abgezogen; der Rest muss mindestens dem Existenzminimum der Zielkette entsprechen — sonst gehen die Mittel verloren.
• Teleports erzwingen kein „Keep Alive“. Achten Sie darauf, dass Ihre Guthaben nach dem Teleport (abzgl. Gebühren) auf beiden Ketten über dem jeweiligen Existenzminimum bleiben, wenn Sie die Accounts weiter nutzen möchten.
• Teleportieren Sie nie direkt auf eine Exchange-Depot-Adresse (die meisten Exchanges erkennen keine Teleports).

Für die Mechanik von Teleports vs Reserve-basierte Transfers und weiterführende Cross-Chain-Routen siehe den Abschnitt XCM/XCMP. Ist eine Asset-Hub-Migration oder Wartung im Gang, können Teleports/XCM-Transfers temporär ausgesetzt sein – aktuelle Support-Infos checken.

Zweck und Rolle: Polkadot und Kusama sind unabhängige Netzwerke mit eigenen Tokens (DOT, KSM) auf ähnlichem Code. Kusama ist das „Canary Network“: ein reales Ökosystem mit schnellerem Feature-Rollout; Polkadot priorisiert Stabilität und Zuverlässigkeit für produktive Deployments.

Governance-Rhythmus: Beide nutzen OpenGov, aber Kusama verwendet generell kürzere Zeitrahmen (track-abhängig) von Entscheidung bis Bestätigung/Enactment, was schnellere Upgrades ermöglicht; Polkadot operiert konservativer. Parameter gelten pro Track und können via Governance geändert werden.

Staking-Timing: Die Unbonding-Periode beträgt ca. 28 Tage auf Polkadot und etwa 7 Tage auf Kusama. Eras — die Zeit für Validator-Auszahlung — sind ca. 24 h auf Polkadot und ~6 h auf Kusama. Dies betrifft Belohnungstakt und die Dauer, in der Mittel nach Unbonding gesperrt bleiben.

Mindesteinlage (Existenzdeposit): Für ein aktives Konto verlangt Polkadot 1 DOT, Kusama 0.000333333 KSM (Werte können sich via Governance ändern). Asset-Hub-Parachains haben noch geringere EDs.

Upgrade-Pfad: Größere Protokolländerungen und neue Features werden auf Kusama im Realbetrieb getestet und nach Bewährung auf Polkadot eingespielt. Dies bewahrt Agilität auf Kusama und sorgt für konservative Entwicklung auf Polkadot.

Beide Netzwerke teilen das Architekturmodell (Relay Chain + Parachains) und OpenGov-Tools; die Unterschiede betreffen Zielsetzung (Speed vs. Stabilität) und Betriebsparameter (Timer, Minimums), nicht das Grunddesign.

NPoS ist Polkadots Staking-Modell mit zwei Rollen: Validatoren betreiben Nodes, die Blöcke produzieren und validieren; Nominatoren unterstützen ausgewählte Validatoren mit DOT. Beide teilen sich Belohnungen und das Risiko von Sanktionen bei Fehlverhalten der Validatoren. Elections bestimmen das aktive Validatoren-Set und ordnen ihm pro Era Nominator-Stake zu.

Wahlzyklus und Timing: Auf Polkadot dauert eine Era ca. 24 Stunden. Das Validatoren-Set für die nächste Era wird während der Endphase der laufenden Era bestimmt und bei Era-Wechsel aktiviert; Belohnungen werden pro Era berechnet.

So nehmen Nominatoren teil: Ein Nominator kann bis zu 16 Validatoren unterstützen. Der Wahlalgorithmus kann das eigene Stake nur einem Teil dieser Targets zuteilen, um eine ausgeglichene und gut gestützte Validatorenmenge zu erreichen; nicht alle nominierten Validatoren erhalten automatisch Stake im Endergebnis.

Wie Validatoren gewählt werden (Ziel und Algorithmus): Wahlen optimieren drei Ziele zugleich: (1) Gesamteinsatz maximieren, (2) Minimale Stake-Höhe pro Validator maximieren, (3) Stake-Varianz im Set minimieren. Polkadot berechnet Lösungen off-chain und submitted sie via Election Provider on-chain (multi-phase, signed/unsigned+On-Chain-Fallback). Das Netzwerk nutzt Proportionalwahlverfahren nach Phragmén, off-chain gelöst per Election Provider, und ersetzt frühere sequentielle Ansätze.

Stake-Zuteilung und Auszahlung (Kurzüberblick): Nach Wahlgewinn spezifiziert die Lösung die Stake-Verteilung der Nominator-Token über die gewählten Validatoren. Validatoren werden pro Era für Aktivität bezahlt, Nominatoren über ihren/n Validator(en). Details siehe Abschnitt zu Staking-Rewards.

Accountability: Nominatoren können slashed werden, wenn ihr nominiertes Validator-Target Verstöße begeht und im aktiven Set ist. Für Bedingungen und Prozentsätze siehe Slashing.

Für Unbondingzeiten, Pools und Rewards siehe die Staking-Abschnitte; dieser Abschnitt behandelt Wahlmodell und Validatorenselektion.

Slashing ist eine On-Chain-Sanktion bei Konsensverstößen eines Validators. Dabei wird ein Prozentsatz des Stakes dieses Validators (Eigenbond + zugeordneter Nominator-Stake) verbrannt (gebrannt). Die Höhe hängt von der Schwere des Vergehens ab; slashed Funds gehen an die Polkadot Treasury. Nur Nominatoren, deren Stake auf den betroffenen Validator entfiel, sind betroffen.

Slashing-Auslöser (Beispiele): Ausgewählte Verstöße aus Polkadots Katalog:

• Equivocation (BABE/GRANDPA/BEEFY): Double-Signing von Blöcken oder Votes. Slash-Range 0,01%–100%, je nach Schwere/Anzahl involvierter Validatoren; Validator wird deaktiviert.
• Backing ungültiger Parachain-Block: Para-Validator signierte ungültigen Block. 100% Slash; On-Chain-Disable.
• ForInvalid Vote: Sekundär-Prüfer votete für ungültigen Block. 2% Slash; Deaktivierung.
• AgainstValid Vote: Votete gegen gültigen Block. 0% Slash (kein Stake-Verlust), aber Deaktivierung.

Unavailability vs. Slashing: Routinemäßige Ausfälle führen meist zu Forced Chilling (Validator wird gestoppt), nicht zu Slashing. Eine „Offline“-Slash ist auf Polkadot erst denkbar, wenn ein Netzwerk-Event vorliegt, z. B. ≥10 % des aktiven Sets gehen gleichzeitig offline. „Prolonged offline“ (um 4 h) führt i. d. R. zu Chilling, nicht zu Slashing.

Wer zahlt wieviel: Slashes werden prozentual auf den "Exposed Stake" (Eigenbond + anteiliger Nominator-Bond) des Validator-Slots angewendet. Verluste verteilen sich pro-rata nach Exponierung der betroffenen Nominatoren; anderer Stake bleibt unberührt. Das Prozentsystem skaliert mit dem Kapitaleinsatz und fördert Diversifizierung.

Anwendung, Verzögerung, Reversals: Viele Slashes werden für ca. eine Unbonding-Periode (~28 Tage) verzögert; Governance kann sie in dieser Zeit rückgängig machen, falls ein Protokollfehler o. ä. zugrunde lag. Ansonsten erfolgt die Anwendung vor Auszahlung nach dem Unbonding.

Wohin gehen gebrannte DOT: Alle slashed DOT werden der On-Chain-Treasury gutgeschrieben, die sie über OpenGov für Netzwerkinitiativen verwendet.

Weitere Infos: Validatorenselektion, Staking-Aufteilung → NPoS; Unbonding und Pools → Staking-Abschnitte.

Bei Staking-Stopp werden gebondete DOT „Unlocking“ und sind erst nach Ablauf der 28-tägigen Unbonding-Periode abziehbar. Danach muss „Withdraw Unbonded“ ausgeführt werden, um sie wieder transferieren zu können. (Kusama braucht 7 Tage.)

Sonderfall: Fast Unstake. Wenn ein Account mindestens 28 Eras lang keinen aktiven Validator unterstützt hat, kann Fast Unstake ohne Wartezeit erfolgen. Bei Exponierung gilt die normale Periode.

Staking Pools vs. Direkte Nominierung

Einstiegsvoraussetzung & Reward-Fähigkeit:

• Direkte Nominierung: Um Rewards zu erhalten, muss die gebondete Summe das dynamische Minimum für aktive Nominations übersteigen.
• Nomination Pools: Erlauben auch kleinen Inhabern Teilnahme — laut Offizieller Doku ab 1 DOT (abhängig von Poolgröße/-aktivität).

Kontrolle & Verwahrung:

• Direkt: Sie wählen Validatoren selbst.
• Pool: DOT bleiben in Ihrem Account (gebondet), aber der Pool-Nominator bestimmt die Validatoren; Misswahl kann Erträge beeinflussen, Slashing-Risiko bleibt.

Abläufe (beitreten, wechseln, verlassen):

• Unbonding-Zeit: Beide Formen sind auf Polkadot = 28 Tage; Poolexit wartet 28 Tage bis Auszahlung.
• Wechseln: Erst Unbonding nötig (28 Tage, keine Rewards in dieser Zeit).
• Rebond während Unbonding: Direkt-Nominator können jederzeit rebonden, solange die 28 Tage nicht abgelaufen sind; Pool-Mitglieder nicht.
• Reward-Auszahlung: Beim Pool-Unbond werden alle offenen Rewards beim Withdraw auto-geclaimed. Manche Pools bieten Auto-Compounding (opt-in).

Derzeit können Sie in OpenGov auch mit Pool-Stake abstimmen und einem Pool beitreten, wenn Tokens bereits für Governance gelockt sind. (Frühere Einschränkungen entfallen.)

Für Strafen bei Validatorefehlverhalten siehe Slashing.

Existenzielle Einlage (ED) und Account-Minimums:

• Relay Chain ED: 1 DOT benötigt, um ein Polkadot-Account aktiv zu halten. Fällt das Guthaben darunter, wird das Konto „gereaped“ (entfernt) und Staub vernichtet.
• Asset Hub ED: 0,01 DOT bei Polkadot Asset Hub (chain-spezifisch, Governance-gesteuert). Assets dort können sufficient (kein DOT nötig) oder non-sufficient (DOT-ED erforderlich) sein.

Keep-Alive-Schutz: Wallets wie Polkadot-JS haben „Keep Alive“ standardmäßig aktiv: Eine Überweisung, die das Account-Guthaben unter das ED senkt, wird blockiert. Deaktiveren Sie das Feature, können Sie alles senden und das Konto reapen lassen.

Gebührenmodell auf der Relay Chain:

Polkadot verwendet ein gewichts-basiertes Gebührensystem. Die Gebühr einer Transaktion summiert sich aus:

• Basiskomponente (Overhead)
• Length Fee (skalierend mit der Bytegröße)
• Weight Fee (skalierend mit dem Ausführungsgewicht des Calls)
• Optionales Tipp (vom Nutzer gesetzt)
• Dynamischer Fee Multiplier passt Gebühren bei Blockauslastung an.

Wie Gebühren angezeigt/geschätzt werden: Wallets und SDKs weisen eine Schätzung aus (z. B. paymentInfo in polkadot.js) – Gebühren werden vom frei verfügbaren Guthaben abgezogen.

Praktische Hinweise:

• Reaktivierung eines gereapten Kontos: Einfach mindestens das ED (z. B. 1 DOT auf der Relay Chain) einzahlen.
• Chain-spezifische EDs: Werte variieren je Chain; Asset Hub hat ein niedrigeres ED. Aktuelle Werte siehe Support-Docs.
• Cross-Chain-Überweisungen: XCM-Operationen (z. B. Teleports) verlangen eine Zielkett-Gebühr und prüfen kein Keep-Alive; achten Sie darauf, dass das Guthaben auf der Zielkette nach Gebühren mindestens das ED erfüllt. Mechanik siehe XCM-Teil.

Für Staking-Minimums und Unbonding siehe Staking-Kapitel; hier: Kontogebühren/Minima.

OpenGov ist das On-Chain-Governance-System von Polkadot. Vorschläge („Referenden“) sind bindend: Eine beschlossene Referendum wird nach Ablauf der Enactment-Periode automatisch On-Chain umgesetzt. Mehrere Referenden können parallel laufen.

Tracks und Origins: Jede Referendum läuft auf einem Track, der eine Origin (Berechtigungsebene) vorgibt. Jeder Track definiert: erforderlichen Decision Deposit, Zeitfenster (Prepare/Decision/Confirmation/Enactment), Approval/Support-Kurven (Schwellenwerte), üblicherweise auch eine Kapazitätsbeschränkung, wie viele Items zeitgleich entschieden werden. Hochprivilegierte Tracks (z. B. Root) haben strengere Schwellen und längere Zeiten als niedrige Tracks (z. B. Small Tipper).

Bestimmte Calls kann die Polkadot Fellowship als „whitelisted“ einstufen, so dass sie via Whitelisted Caller Track mit schnelleren Parametern ausgeführt werden. Das Verhalten der Tracks und Beispiele werden im OpenGov-„Origins“-Guide dokumentiert.

Abstimmen und Conviction: Tokenhalter stimmen Aye/Nay/Abstain mit DOT ab. Es kann Conviction-Voting (Multiplikator durch längeres Locken) gewählt werden; Locks starten nach Ende der Referendum und enden erst mit Ablauf der gewählten Conviction. OpenGov erlaubt verschiedene Convictions für verschiedene gleichzeitige Referenden.

Delegation und Multidelegation: Statt selbst zu stimmen, können Inhaber Voting Power delegieren. OpenGov unterstützt Delegation pro Track (Multidelegation): Sie können verschiedene Beträge (und Convictions) an verschiedene Delegierte pro Track geben. Eine Delegation ist nicht möglich, wenn auf dem Track noch nicht abgelaufene Stimmen oder Delegationen liegen — dann erst löschen. Offizielle UIs bieten Track-Auswahl und Conviction beim Einstellen einer Delegation an.

Lifecycle einer Referendum (Überblick):

• Submission & Prepare Period – Einreichung auf einem Track; Voting kann beginnen, wird aber erst nach Ende der Prepare-Phase gezählt. Ein Decision Deposit muss für den Eingang in die Entscheidungsphase gesetzt werden.
• Decision Period – Aktive Entscheidungsphase. Ein Durchkommen erfordert Erreichen der Approval-/Support-Kurve dieses Tracks.
• Confirmation Period – Schwellenwerte müssen für ein Minimum an Zeit gehalten werden.
• Enactment Period – Nach Bestätigung wird der Aufruf in die Queue gelegt und nach dem Enactment Delay ausgeführt.

Jeder DOT-Holder kann bei OpenGov teilnehmen: Sie können Referenden vorschlagen, direkt abstimmen oder Voting Power delegieren. Die Aktivitäten erfolgen je Track, der Origin (Berechtigung), Decision Deposit, Schwellen und Zeitfenstern vorgibt. Die Parameter differieren nach Track und werden via Governance gesetzt.

Vorschlagen (Referendum erstellen):

1. Wählen Sie den passenden Track für Ihre Maßnahme (z. B. Root für hochprivilegierte Calls, Tippers/Spenders für Treasury-Vorgänge).
2. Reichen Sie das Referendum ein und leisten Sie das Decision Deposit; die Einzahlung ist On-Chain nachvollziehbar und Pflicht, damit das Item nach der Lead-In-Periode in die Entscheidungsphase kommt. Beträge pro Referendum werden in UIs angezeigt und sind nach Track-Regeln rückzahlbar.

Anforderungen: Polkadot-Konto mit genügend DOT für Fees und das Decision Deposit des Tracks. On-Chain-Identität ist optional, wird aber für Glaubwürdigkeit oft genutzt; das Einstellen erfordert eine rückzahlbare Einlage plus Registrar-Gebühr auf der People-Parachain.

Abstimmen (direkte Teilnahme):

• Choice: Aye, Nay, Abstain, Split (prozentual Aye/Nay), oder SplitAbstain (prozentual Aye/Nay/Abstain).
• Conviction Voting: Optional Locken von DOT, um Stimmgewicht zu vervielfachen; Locks beginnen nach Referendumsende und laufen mit der gewählten Conviction ab. Locks können überlappen, sodass die gleiche Balance mehrere Votes oder Stakings abdeckt. Die Stimme kann während der Laufzeit auch entfernt werden, dann lock sofort weg; abgelaufene Locks sollten danach entfernt werden.

Gestakte/gepoolte DOT können mitstimmen: OpenGov gestattet Abstimmung auch mit Solo-Stakes oder via Nomination Pools; eine Laufzeitaktualisierung ermöglichte die Teilnahme Pool-Konten.

Delegation (pro Track, Multidelegation): Wer nicht jedes Item abstimmen möchte, kann Voting Power delegieren. OpenGov erlaubt Multidelegation pro Track: verschiedene Delegierte für verschiedene Tracks, mit jeweils individuellen Beträgen/Convictions. Tracks können nicht delegiert werden, wenn eigene Stimmen/Delegations noch aktiv sind. Delegation einstellbar in Polkadot-JS, Polkassembly, Nova, PolkaGate.

Tools:

• Polkadot-JS UI: Vorschlagen, Abstimmen, Delegation, abgelaufene Referendums-Locks entfernen.
• Polkassembly/Subsquare/Nova/PolkaGate: Referenden entdecken, stimmen (inkl. Split/Abstain), pro Track delegieren.

Für Schwellen, Zeitfenster und Deposit-Größen bitte den spezifischen Track prüfen; Parameter variieren, ändern sich ggf. per Governance.

Die Treasury ist ein On-Chain-Fonds, gesteuert durch OpenGov. Sie erhält Zuflüsse automatisiert und darf nur für Governance-abgesegnete Maßnahmen Mittel ausgeben. Funds liegen auf einem Systemkonto; externe Accounts können diese Mittel nicht direkt bewegen.

Wie wird die Treasury finanziert (Zuflüsse):

• Transaktionsgebühren: 80 % jeder Gebühr gehen an die Treasury; 20 % an Blockproduzenten.
• DOT-Emission: 15 % der jährlichen Inflation gehen an die Treasury.
• Slashes: Ein Anteil gebrannter Staking-Anteile bei Validatorverstößen wird der Treasury gutgeschrieben.
• Direkte Transfers: Nutzer können (selten, z. B. Rückerstattungen) Assets an die Treasury senden.

Wie funktioniert das Ausgeben (Abflüsse):

• Treasury-Proposals (Spends): Governance entscheidet per Referendum über Auszahlungen an Empfänger. Die Auszahlung erfolgt nach dem Spend-Intervall; am Ende jeder Spend-Periode wird ein Anteil verbleibender Mittel verbrannt.
• Tips: Kleine/schnelle Zahlungen über die Small/Big Tipper-Tracks.
• Bounties/Child Bounties: Einmalige „Parent“-Bounties reservieren Mittel, die Curators über Child-Bounties für Teilaufgaben schrittweise auszahlen – hilfreich bei mehreren Zahlungen über längere Zeit. Curators hinterlegen Deposit, erhalten ggf. eine Kuratorgebühr und verwalten die Auszahlung während der Laufzeit.

Governance-Tracks für Treasury-Spends: OpenGov verwaltet Treasury-Ausgaben über sechs Tracks mit jeweils eigenen Origins/Parametern: Treasurer, Big/Medium/Small Spender sowie Big/Small Tipper. Größere Ausgaben gehen strengere Tracks; Tips sind für kleine Prämien.

Multi-Asset-Treasury: Die Treasury kann auch andere Assets als DOT halten/ausgeben (z. B. USDT/USDC), sofern die Assets via Asset Hub eingebunden und ein Wechselkurs per Treasurer-Track gesetzt wurde. Freigegebene Multi-Assets-Spends spezifizieren Asset, Chain und Betrag; Meilensteinzahlungen und manuelle Claim-Zeitfenster werden unterstützt.

Sub-Treasuries (Budget-Delegation): Governance kann Teile der Treasury an Sub-Treasuries für Collectives oder System Chains delegieren. Sub-Treasuries folgen eigenen Regeln für die Auszahlung und entlasten so die Haupt-Treasury von Einzelreferenden.

Für Vorschläge, Abstimmungen, Delegation bei Treasury-Proposals siehe OpenGov.

Die Polkadot Fellowship ist eine On-Chain-Collective aus technischen Contributors, die Polkadots Runtime und Standards betreut. Ihre Arbeit erfolgt auf der Collectives-System-Chain von Polkadot und wird On-Chain und im öffentlichen Repository (z. B. RFCs) koordiniert. Die Fellowship pflegt Polkadots und Kusamas Runtimes, entscheidet aber nicht exklusiv über Protokolländerungen – jeder DOT-Holder kann ein Runtime-Upgrade auf Root bei OpenGov vorschlagen.

Mitgliedschaft und Ränge: Fellows besitzen einen Rank; interne Abstimmungen gewichten Verantwortung und Review-Tiefe entsprechend. Öffentliche Dashboards auf der Collectives Chain zeigen Ränge und Fellowship-Aktivitäten.

Whitelisting & Whitelisted Caller Track: Für zeitkritische/geringriskante, gut geprüfte Aktionen (z. B. Runtime-Releases), kann die Fellowship eine bestimmte Call-Hash whitelisten. So kann der Whitelisted Caller Track in OpenGov mit Root-Befugnis nach Passieren der Referendum die Ausführung übernehmen. Der Track nutzt beschleunigte Zeitrahmen und andere Approval/Support-Kurven als Root – biete so einen schnellen Pfad für geprüfte Items.

Wie Upgrades umgesetzt werden: Auf Polkadot sind Runtime-Upgrades nur via Root- oder Whitelisted Caller-Referenden möglich. Die Fellowship reviewed und whitelisted Releases, die dann via Schnell-Track eingeführt werden können; andere Upgrades laufen über den Root-Prozess.

Offener Entwicklungsprozess: Technische Vorschläge/Designs werden im öffentlichen RFC-Repo der Fellowship nachverfolgt; Approval/Ablehnung-Signale und On-Chain-Entscheidungen sind für Tokenholder sichtbar.

Agile Coretime (Blockspace als Markt)

Polkadot 2.0 ersetzt langfristige Slot-Miete/Crowdloans durch einen Coretime-Markt. Projekte bekommen Ausführungszeit auf den „Cores“ der Relay Chain auf zwei Wegen:

• Bulk Coretime: Monatlicher „Region“ (~28 Tage, 5.040 Timeslices), verkauft auf einer speziellen Coretime-Chain. Besitz als Non-Fungible Asset On-Chain dokumentiert/veräußerbar.
• Instantaneous Coretime: Kurzfristig aus einem Pool, bei Bedarf, Pay-as-you-go.

Der Verkauf erfolgt via Dutch-Auction (Preis sinkt während der Lead-in-Periode); ein Basispreis wird durch Governance-Regeln langsam an die Nachfrage angepasst. Ein Zweitmarkt für Regionen ist vorgesehen. Einnahmen aus dem Verkauf von Coretime werden laut Fellowship RFC verbrannt. Netto-Emission = Bruttoemission minus Burns.

Kostenwirkung: Teams planen Budgets durch zugekaufte, exakte Kapazitäten, ohne mehrjährige Bindung; Preissignale sind klarer. Auktionen/Crowdloans entfallen seit Agile Coretime.

Async Backing (Throughput & Latenz)

Asynchrones Backing entkoppelt Parachain-Blockproduktion vom gerade jüngsten Relay-Chain-Block und erlaubt Collators, Blöcke im Voraus zu pipelinen und Backing/Inclusion zu überlappen. Praktisch bedeutet das:

• Parachains können alle ~6 s einen Block bauen (vorher 12 s).
• Das Ausführungsfenster steigt (von ~0,5 s auf ~2 s), Blockgröße wächst um den Faktor 4.
• Bringt ca. 8× höheren Throughput solo, ca. 10× mit PoV-Reclaim (Proof-Größe inkl.).

Diese Features gingen 2024 live (Kusama zuerst, dann Polkadot).

Performance: Höhere nachhaltige TPS und schnellere Inclusion für Parachains mit dieser Funktion, Opt-in möglich für Chains, die die Extrakapazität später nutzen möchten.

Elastic Scaling (mehrere Cores pro Chain)

Elastic Scaling gestattet einer Chain, mehrere Cores parallel zu nutzen (vertikales Skalieren) statt strikt 1-Core-per-Parachain. Kombiniert mit Async Backing und neuen Collator-/Validator-Parametern wächst die Durchsatzkapazität weiter und die Latenz sinkt. Stand August 2025: Elastic Scaling wird für Mainnet via OpenGov finalisiert (zuerst Kusama, dann Polkadot).

Performance: Rollups/Parachains mit hoher Last verteilen Arbeit über mehrere Cores – mehr Luft nach oben, ohne mehrere Chains aufspalten zu müssen.

Effekte, Zusammenfassung:

• Kosten & Planung: Vorhersagbare, marktorientierte Coretime ersetzt lange Leases; Teams kaufen monatliche Regionen oder On-Demand-Slices; Einnahmen aus Coretime-Brands reduzieren Emission.
• Durchsatz & Latenz: Async Backing verdichtet Blockfrequenz/-kapazität, Elastic Scaling ermöglicht Multicore-Ausführung. Insgesamt mehr Durchsatz, bei konstantem Shared-Security-Modell.

1. Chain bauen:

   • Polkadot SDK (Substrate + Cumulus) nutzen, von Parachain-Vorlage starten. Enthält FRAME-Runtime, Collator-Node und XCM-Hooks.
   • Lokal mit einer Relay Chain verbinden für Blockproduktion/XCM-Basics; ein offizielles Tutorial zeigt die Konnektion einer lokalen Parachain.

2. Testnet-Proofing & ParaID holen:

   • Upgrades und XCM auf Paseo (Testnet mit Coretime-Features) beweisen.
   • Eine ParaID auf der Ziel-Relay-Chain via Registrar reservieren: zuerst reserve (Ketteinlage zahlt), später register mit Validation-Code (WASM) und Genesis Head. Deposits sind chain-spezifisch im registrar pallet definiert. (Konstanten im Testnet, Mainnetwerte via Governance.)

3. Coretime erwerben (Polkadot 2.0):

   • Bulk Coretime (eine „Region“): ~28-Tage-Region mit 5.040 Timeslices auf einem Core, verkauft auf der Coretime Chain. Besitz wird On-Chain getrackt, ist übertragbar/veräußerbar; Verkauf via Dutch-Auction zum „Regular Price“.
   • Instantaneous Coretime: Kurzfristige Kapazität On-Demand aus dem Pool.
   • Abrechnung: Einnahmen werden gemäß Fellowship RFC-0010 verbrannt; Budget für DOT-Kosten einplanen; keine Lockup-/Crowdloans.

4. Weiterleitung/Registration in der Relay Chain:

   • Mit ParaID, Runtime-WASM und Genesis Head Registrierung/Activation der Chain. Auf Polkadot erfolgt das übliche Onboarding via Registrar; Systemchains (z. B. Coretime, Asset Hub) werden via OpenGov (häufig Whitelisted Caller Track) registriert, wie in der Coretime-Chain-Referendum.

5. Netzbetrieb führen:

   • Collators: Mindestens zwei zuverlässige Collators betreiben, später Geo- und Lastskalierung. (Validation erfolgt durch die Relay Chain; Parachains stellen Collators.)
   • XCM & HRMP: HRMP-Channels zu Peers (z. B. Asset Hub) öffnen, XCM konfigurieren (Fees, Reserves). Für DOT-Routing aktuelle Guidance zum Asset Hub als DOT-Reserve beachten (Migration läuft).
   • Upgrades: Runtimes via Chain-Governance aktualisieren; die Relay Chain prüft Inclusion. (Parameter/Governance-Mechanik siehe Governance-Kapitel.)

6. Rollups vs. Parachains („Rollup“-Einordnung):

   • Teams implementieren oft „Rollups“ als Parachains via SDK (Settle & Verify via Relay Chain) und erben damit Availability/Validity & XCM. Wer einen Rollup-as-a-Service auf fremder Parachain startet, stimmt sich mit dem Host ab; die Relay-Onboarding-Schritte bleiben im Wesentlichen analog. (Architektur ist projektspezifisch.)

Mindestanforderungen (Checkliste)

Technisch:

• Polkadot SDK-Runtime (WASM) + Chain Spezifikation, Genesis Head, ParaID.
• Collator-Nodes, RPC-Endpunkte, Telemetrie/Monitoring.
• XCM-Konfiguration, mindestens ein HRMP-Channel für Integrationen.

Ökonomisch:

• DOT-Budget für Coretime (Bulk/Instantaneous) und Transaktionsgebühren; beachten, dass Coretime-Verbrauch verbrannt wird.
• Registrar-Deposit für Reservierung/Registration der ParaID (chain-spezifisch).

Governance-Kontaktpunkte:

• Keine bei üblichem Registrar-Onboarding, nur eigene Chain-Governance; System Chains werden via OpenGov eingebracht (Beispiel: Coretime-Chain-Registration).

Native DOT vs Wrapped/Derivative DOT:

• Native DOT lebt auf Polkadot selbst (Relay Chain + System Chains wie Asset Hub). DOT bewegt sich innerhalb Polkadots per XCM: entwerder Teleport (Relay ↔ Asset Hub für DOT) oder Reserve-basiert beim Transfer auf andere Parachains. DOTs Reserve Location in XCM wird von der Relay Chain zum Asset Hub migriert; Parachains sollten künftig Asset Hub als DOT Reserve behandeln.
• Wrapped/Derivative DOT existiert außerhalb Polkadot (z. B. auf Ethereum) oder als ERC-20-Form in einer EVM-Parachain. Auf Moonbeam ist DOT als xcDOT verfügbar, ein XC-20: ERC-20-kompatibles Asset, dessen Basis-DOT auf der Reserve Chain gesperrt bleibt, während die ERC-20-Schnittstelle lokal genutzt wird.

XCM im Polkadot-Ökosystem vs Bridges zu anderen Netzwerken:

• XCM (im Ökosystem): Message-Format & Muster für Asset-Movement zwischen Relay Chain und Parachains. Für DOT ist Teleport auf die vertrauenswürdige Route Relay ↔ Asset Hub beschränkt; Movement auf andere Parachains erfolgen meist Reserve-basiert, Reserve Chain bilanziert die Bestände.
• Bridges (aus dem Ökosystem heraus): Für Netzwerke wie Ethereum nutzt Polkadot Bridges auf Bridge Hub. Snowbridge ist die offizielle Polkadot↔Ethereum Bridge auf Light-Client-Basis. Sie mintet gebridgte ERC-20s auf Asset Hub (ForeignAssets-Pallet), dann wird via XCM ein Reserve-Transfer zum Ziel-Parachain durchgeführt – Bridge & XCM arbeiten zusammen.

EVM-Kompatibilität via Moonbeam (XC-20s):

• XC-20-Standard: Auf Moonbeam erscheinen Cross-Chain-Assets als XC-20s (ERC-20 + Permit-Schnittstellen). Für DOT: xcDOT. Entwickler nutzen Ethereum-Tools, während Polkadot über Sovereign Accounts Reserve behandelt.
• Local vs. External XC-20s: Tokens mit Reserve auf Moonbeam sind „local“ XC-20s; Assets wie DOT sind „external“ XC-20s, deren Ursprungs-Saldo auf der Reserve-Chain bleibt, mit ERC-20-Darstellung auf Moonbeam.

Praxishinweise:

• Wann was nutzen: XCM für Transfers innerhalb Polkadots (z. B. DOT zwischen Asset Hub & Parachains). Brücke (z. B. Snowbridge) für Asset-Transfers nach/von externen Netzwerken wie Ethereum; gebridgte Tokens sind eigene Darstellungen mit eigenem Risiko/Trust.
• Aktuelle Entwicklungen: Die Migration der DOT-Reserve-Location (zu Asset Hub) ist aktiv; Parachains/Apps müssen XCM-Konfiguration aktualisieren, um Transfers/Buchungen kanonisch zu halten. Endnutzerinfos werden von Polkadot Support/Forum veröffentlicht.

Polkadot wurde von der Web3 Foundation (W3F) initiiert, einer Non-Profit-Organisation mit Sitz in der Schweiz; ihr Leuchtturm-Projekt ist Polkadot. W3F-Gründer ist Dr. Gavin Wood, der 2016 das ursprüngliche Polkadot-Whitepaper zur heterogenen Multi-Chain-Architektur schrieb.

Die Entwicklung von Protokoll und Runtime leitete Parity Technologies, das Engineering-Team, welches Polkadot mit der W3F 2020 zum Mainnet führte.

Das Kernteam von Polkadot besteht laut allgemeiner Angabe aus Gavin Wood, Robert Habermeier und Peter Czaban. Die W3F-Launch-Ankündigung nennt Robert Habermeier als Polkadot-Mitgründer und Core-Dev sowie Peter Czaban als Co-Founder von Polkadot und der Web3 Foundation.

Die W3F startete das Live-Netz von Polkadot am 26. Mai 2020 nach mehreren Jahren Entwicklung; in den anschließenden Phasen erhielten Tokenholder die Kontrolle und DOT wurde erstmals On-Chain ausgegeben. Details zu Tokenomics und Redenomination siehe vorherige Abschnitte.