Polygon technisch verifizieren: Whitepaper, Quellcode und aktive Verträge prüfen

Zusammenfassung

Dieser Artikel zeigt in sieben Schritten, wie sich die zentralen Aussagen zum POL-Token technisch überprüfen lassen.

Die technische Prüfung ergibt zum betrachteten Stand drei wesentliche Befunde. Erstens ist die anfängliche Gesamtmenge von 10 Milliarden POL direkt im Token-Vertrag nachvollziehbar. Zweitens ist die Emissionslogik im aktuellen Code deterministisch implementiert und entspricht einer jährlichen Rate von rund 2 % mit Zinseszinseffekt. Drittens lässt sich über Rollenprüfung und Proxy-Historie feststellen, welche Vertragsversion diese Logik aktuell tatsächlich ausführt.

Damit wird aus allgemeinen Tokenomics-Aussagen eine überprüfbare technische Aussage. Der Artikel zeigt nicht nur, was Polygon öffentlich behauptet, sondern wie man selbst kontrollieren kann, ob diese Angaben mit dem veröffentlichten Code und dem aktiven Deployment konsistent sind.

Ziel dieses Artikels

Dieser Artikel beschreibt, wie man zentrale Aussagen rund um den POL-Token technisch verifiziert. Im Mittelpunkt stehen dabei drei Fragen:

1. Welche Aussagen macht das Whitepaper beziehungsweise die offizielle Kommunikation?
2. Wo findet man die dazugehörige Logik im Quellcode?
3. Wie lässt sich prüfen, ob genau diese Logik auch in den aktuell aktiven Verträgen auf der Blockchain läuft?

Der Fokus liegt auf einem reproduzierbaren Prüfpfad. Es geht also nicht um Marktstimmung oder Spekulation, sondern um die Frage, wie sich öffentliche Aussagen mit öffentlich einsehbarem Code und On-Chain-Daten abgleichen lassen.

Was man am Ende überprüft haben sollte

Wenn Sie die folgenden Schritte durchgehen, können Sie insbesondere diese Punkte selbst nachvollziehen:

• die anfängliche POL-Gesamtmenge,
• die technische Logik der POL-Emission,
• die beteiligten Verträge für Gemeinschaftskasse (Treasury) und Token-Hinterlegung (Staking),
• die aktuell aktive Emission-Manager-Implementierung,
• die vollständige Upgrade-Historie des Emission-Manager-Proxys

Benötigte Quellen und Werkzeuge

Für die Prüfung reichen frei zugängliche Quellen:

• POL Whitepaper¹
• POL technische Informationen
• PIP-17: Polygon Ecosystem Token (POL)
• POL Token Repository auf GitHub
• POL Token auf Etherscan
• PIP-26: Council Transparency Report
• PIP-40: Support for Community Treasury Contracts
• PolygonScan Charts

Schritt 1: Die überprüfbaren Aussagen isolieren

Am Anfang steht nicht der Code, sondern die öffentliche Kommunikation von Polygon Labs. Nur wenn klar ist, was genau überprüft werden soll, kann man zielgerichtet nachsehen.

Bei POL sind die zentralen Aussagen unter anderem:

1. Die initiale Ausgabe beträgt 10 Milliarden POL.
2. Weitere Emissionen folgen einer vordefinierten, deterministischen Rate.
3. Die Emission wird oft als rund 2 % pro Jahr beschrieben.
4. Teile der Emission gehen an Gemeinschaftskasse (Treasury) und Token-Hinterlegung (Staking).
5. Die Governance kann Emissionslogik über Upgrades beeinflussen.

Diese Aussagen finden sich verteilt über Whitepaper, technische Dokumentation und Governance-Texte. Für die technische Prüfung ist es sinnvoll, sie in konkrete Prüffragen umzuschreiben:

• Wo steht die initiale Ausgabe im Code?
• Welcher Vertrag erzeugt neue Token (Minting)?
• Welche Formel bestimmt die jährliche Emission?
• Welche Verträge erhalten die neu erzeugten Token?
• Welcher Vertrag ist aktuell aktiv?
• Ist die aktive Implementierung mit dem Quellcode auf GitHub identisch oder zumindest konsistent?

Schritt 2: Die initiale POL-Menge im Token-Vertrag prüfen

Die erste technische Basisprüfung ist der Token-Vertrag selbst. Rufen Sie dazu den veröffentlichten POL-Quellcode auf GitHub auf:

• PolygonEcosystemToken.sol auf GitHub

Suchen Sie dort nach der Mint-Anweisung für die initiale Ausgabe. Relevant ist die Zeile 39:

 _mint(migration, 10_000_000_000e18);

Was das bedeutet

In der Zahl 10_000_000_000e18 dienen die Unterstriche nur der Lesbarkeit. Der Solidity-Compiler ignoriert sie vollständig. Das Suffix e18 ist wissenschaftliche Notation und bedeutet „mal 10 hoch 18“; der Dezimalpunkt wird also um 18 Stellen nach rechts verschoben. Der Wert entspricht daher 10.000.000.000 × 10^18 und damit ausgeschrieben 10.000.000.000.000.000.000.000.000.000.

Beispiel:
Der Wert 0.02856915219677089e18 entspricht ausgeschrieben 28,569,152,196,770,890.

Was dieser Schritt beweist

Damit lässt sich direkt verifizieren:

• Die initiale POL-Menge wurde technisch mit 10 Milliarden Token angelegt.
• Die Zahl ist nicht nur Marketing, sondern im Contract-Code fest codiert.
• Der Startwert der späteren Angebotsentwicklung ist damit technisch nachvollziehbar.

Was dieser Schritt noch nicht beweist

Damit ist nicht geklärt,

• wie viel später neu emittiert wird,
• welche Verträge das Minting steuern,
• oder ob die aktuelle Emissionslogik noch der ursprünglichen Kommunikation entspricht.

Schritt 3: Die Emissionsverträge über PIP-17 identifizieren

Als Nächstes muss geklärt werden, welche Verträge für spätere Emissionen zuständig sind.

Dafür ist der Polygon Verbesserungsvorschlag PIP-17 ein guter Einstieg:

• PIP-17 auf dem Polygon-Forum

In diesem Dokument werden die beteiligten Komponenten beschrieben. Besonders relevant sind:

• der aktuelle Quellcode auf GitHub
• der upgradefähige Emission-Manager-Vertrag mit seiner DefaultEmissionManager-Implementierung,
• die Adresse des Vertrags für Token-Hinterlegungsbelohnungen (Staking Rewards)
  0x5e3ef299fddf15eaa0432e6e66473ace8c13d908,
• die Adresse 0x2ff25495d77f380d5F65B95F103181aE8b1cf898 der Multisignatur-Wallet der Gemeinschaftskasse (community treasury), die laut PIP-17 als Übergangslösung vorgesehen war; der Stichtag 24.06.2024 ist aus dem Erstellungsdatum der späteren Treasury-Adresse 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9 auf Etherscan abgeleitet. Zusätzlich beschreibt PIP-40 explizit die Migration der Treasury-Logik auf die neue Community-Treasury-Adresse 0x86380e136a3aad5677a210ad02713694c4e6a5b9.

Dadurch wird die Prüfung von einem allgemeinen Whitepaper-Vergleich zu einer konkreten technischen Suche: Jetzt weiß man, nach welchen Vertragsnamen und Adressen man auf Etherscan und GitHub suchen muss.

Schritt 4: Den DefaultEmissionManager-Vertrag im Quellcode untersuchen

Jetzt folgt der wichtigste Teil der technischen Prüfung: die konkrete Emissionslogik. Öffnen Sie den aktuellen DefaultEmissionManager-Vertrag auf GitHub:

• DefaultEmissionManager.sol im GitHub-Repository

Achten Sie zunächst auf die Beschreibung in Zeile 14 des Quellcodes auf GitHub:

 /// @dev The contract allows for a 2% mint per year (compounded). 1% staking layer and 1% treasury
 

Diese Kommentarzeile ist wichtig, weil sie zeigt, wie die Entwickler selbst die Logik beschreiben. Danach kommt die zentrale Konstante in Zeile 19:

 uint256 public constant INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18;
 

Festpunktdarstellung

Die Skalierung von 0.02856915219677089 mit zehn hoch achtzehn (10^18) hat einen einfachen Hintergrund: In der Ethereum Virtual Machine, die Polygon nutzt, gibt es keine echten Floating-Point-Typen (float, double), daher rechnet man “on-chain” nur mit Ganzzahlen. Auch die Programmiersprache Solidity unterstützt deshalb nur Ganzzahlen und nutzt die Festpunktdarstellung. Die Anzahl Stellen nach dem Dezimaltrennzeichen sind festgelegt: 1e18 = 1 * 10^18.

Anders ausgedrückt bedeuten bei der Festpunktdarstellung 10,000,000,000e18 der Teil vor e zehn Milliarden Token – das ist der ganzzahlige Anteil, und achtzehn Stellen sind die Basiseinheit “Wei” eines Tokens, sozusagen der Festkommaanteil eines Tokens:

• 1e18 Basiseinheiten = 1 ganzer Token
• 1e17 Basiseinheiten = 0,1 Token
• 1 Basiseinheit = 1 Wei

Wie man diese Zeile interpretiert

Laut Kommentar in Zeile 14 steht die Konstante INTEREST_PER_YEAR_LOG2 in Zeile 19 für eine 2-prozentige Erhöhung. Gemeint ist die Erhöhung der initialen Umlaufmenge von 10_000_000_000e18 POL. Zur Vereinfachung nennen wir diese Umlaufmenge x.

Möchte man eine Menge x um zwei Prozent erhöhen, muss man x + x * 0.02 rechnen.

  // "Prozent" = "per centum" = pro Hundert 
  // Zwei pro Hundert => 2/100 = 0.02
   x + x * 0.02
= (1 + 0.02) * x
= x * 1.02

Logarithmus und Exponent zur Basis 2

Weiterhin legt der Kommentar in Zeile 14 nahe, dass die Konstante INTEREST_PER_YEAR_LOG2 das Ergebnis eines Logarithmus zur Basis 2 sein soll: log2(p) = INTEREST_PER_YEAR_LOG2.

In Zeile 89 findet man den Beleg dazu in Form der Umkehrrechnung:

  uint256 supplyFactor = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);

Die Funktion PowUtil.exp2(q) rechnet zwei hoch q: 2^q. Unser gesuchtes p ist also
p = PowUtil.exp2(q) = PowUtil.exp2( log2(p) )

Es gilt also:

    p = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days)
<=> p = 2^ ((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);
<=> p = 2^ ((log2(p) * timeElapsed) / 365 days);

Was dies konkret bedeutet kann man mit einem Taschenrechner einfach selbst ausprobieren:

  // zur Erinnerung:
  INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18 // ~ 0.02857

  // Prüfen Sie mit dem Taschenrechner nach
  2 ^ 0.02857 => 1.02 => ~2.0 %  // => p=1.02, d.h. Faktor zur Erhöhung um 2 %

  // Gegenprobe mit Umkehrfunktion
  log2(1.02)= 0.02857 // = INTEREST_PER_YEAR_LOG2

Diese Rechnung belegt, dass die Konstante INTEREST_PER_YEAR_LOG2 für eine zwei-prozentige Erhöhung steht.

Anteilige Verzinsung

Bisher haben wir allerdings vernachlässigt, dass q im Term 2^q tatsächlich
q = (INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days ist. Hier ist zu beachten, dass in Solidity 365 days ein Zeiteinheitenliteral ist und zu Sekunden ausgewertet wird.

    (log2(p) * timeElapsed) / 365 days   // 365 Tage = 31,536,000 Sekunden
<=>  log2(p) * timeElapsed  / 31,536,000  
<=>  0.02857 * (timeElapsed / 31,536,000)  

// 0.02857 = jährliche 2-Prozent Verzinsung
// 1 Jahr = 365 Tage = 31,536,000 Sekunden
// 0.02857 * (timeElapsed  / 365 days) => Anteil der Verzinsung pro Sekunde

Eine 2 % Verzinsung pro Jahr wird hier anteilig auf Sekunden umgerechnet.

Warum das wichtig ist

Mit diesem Schritt lässt sich präzise zeigen:

• Die mathematische Konstante im aktuellen GitHub-Code steht in dieser Version tatsächlich für 2 %.
• Wer den Wert falsch liest, könnte zu einer falschen Inflationsrate kommen.

Schritt 4.1: Die Menge der neu erzeugten Token nachvollziehen

Im DefaultEmissionManager Vertrag steht in Zeile 88:

   function inflatedSupplyAfter(uint256 timeElapsed) public view returns (uint256 supply) {
      uint256 supplyFactor = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);
      supply = (supplyFactor * START_SUPPLY_1_4_0) / 1e18;
   }
 

An diese Funktion wird in Zeile 68 der Wert block.timestamp - startTimestamp übergeben, der den Funktionsparameter timeElapsed setzt.

block.timestamp hat die Einheit Sekunden und gibt den Erstellungszeitstempel des aktuellen Blocks in der Ethereum-Blockchain an. Es handelt sich um die aktuelle Ausführungszeit der Funktion inflatedSupplyAfter().

Die Variable startTimestamp wurde auf den Zeitpunkt des Beginns, d.h. der Initialisierung bzw. Reinitialisierung der Startmenge, des POL-Tokens gesetzt. Siehe die beiden Funktionen in den Zeilen 44 bzw. 49.

Die Formel, mit der die Variable supplyFactor gesetzt wird, modelliert eine 2%-Rate mit Zinseszinseffekt. Dazu wird ein kontinuierlicher Zeitanteil in Sekunden pro Jahr genutzt.

Kurzgefasst wird die Variable supply in jedem Jahr seit Beginn des POL-Tokens um näherungsweise 2,0 % erhöht. Dies kann man mit einer Tabellenkalkulation leicht nachrechnen:

Die Spalte C zeigt die Entwicklung der Umlaufmenge pro Jahr anhand der Formel aus dem Default­Emission­Manager-Vertrag. Die Spalte D zeigt zum Vergleich eine gewöhnliche Zinsrechnung, die jeweils auf dem Vorjahreswert basiert.

Was dieser Schritt belegt

Die jährlichen POL-Emissionen werden durch eine deterministische Formel bestimmt, die auf der im vorigen Schritt identifizierten Konstante basiert. Konkret lässt sich hier nachweisen:

• Die Menge neu erzeugter Token ist nicht willkürlich, sondern ergibt sich rechnerisch aus der seit Beginn vergangenen Zeit.
• Die Formel setzt exakt den Zinseszinseffekt um: Jedes Jahr wird nicht nur auf die ursprüngliche Startmenge, sondern auf das jeweils schon gewachsene Angebot aufgezinst.
• Die Emission von rund 2 % pro Jahr lässt sich mit einer einfachen Tabellenkalkulation anhand der Formel unabhängig nachvollziehen und prüfen.
• Der Startzeitpunkt (startTimestamp) ist im Vertrag fest verankert, sodass die Emissionskurve von einem definierten Ausgangspunkt aus nachvollziehbar ist.

Schritt 4.2: Die Verteilung der neu erzeugten Token im Code prüfen

Im selben Vertrag lässt sich nachvollziehen, wohin emittierte Token fließen. Relevant sind die Zeilen 74 und 75:

 uint256 treasuryAmt = amountToMint / 2;
 uint256 stakeManagerAmt = amountToMint - treasuryAmt;
 

“Amt” steht für das englische Wort “Amount”, also „Menge" im Deutschen. Die Menge der neu zu prägenden Token (amountToMint) wird in zwei gleiche Hälften aufgeteilt.

Einige Zeilen danach, in den Zeilen 82 und 84, folgt:

 _token.safeTransfer(treasury, treasuryAmt);

 _token.safeTransfer(stakeManager, stakeManagerAmt);
 

Die Beträge werden also jeweils an die treasury-Adresse und die stakeManager-Adresse gesendet. Beide Adressen werden beim Erstellungsvorgang, im Englischen Deployment genannt, auf der Blockchain gesetzt und sind danach unveränderlich (immutable).

 constructor(address migration_, address stakeManager_, address treasury_) {
   if (migration_ == address(0) || stakeManager_ == address(0) || treasury_ == address(0)) revert InvalidAddress();
   DEPLOYER = msg.sender;
   migration = IPolygonMigration(migration_);
   stakeManager = stakeManager_;
   treasury = treasury_;

   // so that the implementation contract cannot be initialized
   _disableInitializers();
 }
  

Was dieser Schritt zeigt

Die Mint-Menge wird hier aufgeteilt in:

• Treasury-Anteil
• Staking-Anteil

Das ist deshalb relevant, weil ein Whitepaper oder Blogtext oft nur die grobe Emissionsrate betont, während die ökonomische Wirkung erst dann verständlich wird, wenn klar ist, wer die neuen Token erhält.

Schritt 5: Emission-Manager-Vertragsversionen auf der Blockchain prüfen

In PIP-17 steht, dass der Emission-Manager upgradefähig ist. Daher müssen wir die derzeit aktuelle Version finden. Öffnet man einen älteren einsehbaren DefaultEmissionManager-Vertrag auf Etherscan, stellt man fest, dass die dort enthaltenen Konstanten deutlich vom aktuellen GitHub-Quellcode abweichen:

Siehe Zeile 19

 uint256 public constant INTEREST_PER_YEAR_LOG2 = 0.04264433740849372e18;
 

und Zeilen 65 und 66

 uint256 treasuryAmt = amountToMint / 3;
 uint256 stakeManagerAmt = amountToMint - treasuryAmt;
 

Ein einzelner Vertrag reicht daher nicht aus, wenn das System upgradefähig ist. Deshalb kann als Nächstes geprüft werden, welche Versionen überhaupt existieren.

Dafür eignet sich die Vertragssuche auf Etherscan:

• Suche nach weiteren DefaultEmissionManager Verträgen

Allerdings ist nicht klar, ob Verträge dieses Namens ausschließlich für POL verwendet werden. Außerdem sind hier nur die tatsächlich aktiv gewesenen Verträge von Interesse. Etherscan bietet dafür eine direkte Lösung: Über den Proxyvertrag lassen sich alle jemals aktiv gewesenen Implementierungen einsehen – chronologisch geordnet, ohne zusätzliche Werkzeuge:

• Historische Verträge des Emission-Manager-Proxys

Ziel dieses Schritts

Sie wollen herausfinden:

• wie viele Versionen des Vertrags es gibt,
• welche Versionen bisher hinter dem Proxy aktiv waren,
• welche Version aktuell aktiv ist.

Gerade bei Upgrade-Systemen ist das entscheidend. Ein sauberer GitHub-Stand nützt wenig, wenn auf der Blockchain längst eine andere Implementierung aktiv ist.

Bildquelle: Screenshot vom 31.03.2026 - etherscan.io

Vorgehen

1. Öffnen Sie die Historical Proxy-Ansicht der Proxy-Adresse 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53.
2. Identifizieren Sie den zuletzt aktivierten Eintrag als aktuell laufende Implementierung.
3. Öffnen Sie die einzelnen Implementierungsadressen und prüfen Sie auf der jeweiligen Contract-Seite den verifizierten Quellcode.

Was man dort kontrollieren sollte

• Versionshinweise
• Emissionsparameter (INTEREST_PER_YEAR_LOG2)
• Aufteilung zwischen Treasury und Staking
• Startwerte und Initialisierungslogik

Was dieser Schritt ermöglicht

Sie sehen auf einen Blick, welche Version aktuell aktiv ist und welche Versionen zuvor produktiv waren. Damit ist die Upgrade-Historie transparent und die Einordnung der Emissionslogik belastbar.

Schritt 6: Prüfen, ob der Emission-Manager die nötige Rolle besitzt

Auch der Proxyvertrag selbst ist nicht automatisch aktiv. Deshalb muss geprüft werden, ob die Emission-Manager-Proxy-Adresse tatsächlich über die Emissionsrechte für POL verfügt.

Dazu gehen Sie auf die Read-Ansicht des POL-Token-Vertrags:

• Read Contract des POL-Tokens

Vorgehen

1. Suchen Sie den Eintrag 4. EMISSION_ROLE.
2. Kopieren Sie den bytes32-Wert dieser Rolle, z.B.
   • 0x573321b8a13c75b2702bc4b0ad9afaae98bf6985285411964a564e68bf6da1c9
3. Öffnen Sie die Funktion 14. asRole.
4. Tragen Sie als role den kopierten Wert ein.
5. Tragen Sie als account (address) den Emission-Manager-Proxy ein:
   • 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53
6. Führen Sie die Abfrage mit einem Klick auf Query aus.

Anmerkung:
Die Emission-Manager-Proxy-Adresse 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53 haben wir aus dem Council Transparency Report: PIP-26.

Erwartetes Ergebnis

Wenn die Antwort true lautet, ist technisch belegt, dass diese Proxy-Adresse die Emissionsrolle besitzt.

Warum dieser Schritt unverzichtbar ist

Damit wird nicht nur ein Vertrag gefunden, sondern ein aktiver Vertragspfad identifiziert. Erst dadurch wird die Prüfung der laufenden Emissionslogik belastbar.

Schritt 7: Vertragshistorie und Umlaufmenge einordnen

Ein Blick auf die Umlaufmenge zeigt, warum die Gesamtmenge am 31.03.2026 bereits bei rund 10.617.468.716 POL lag: Die heute geltende 2-%-Regel galt nicht über den gesamten Zeitraum, sondern ist das Ergebnis mehrerer Vertragsversionen.

Die Historical Proxy-Ansicht dokumentiert die Abfolge der aktiven Implementierungen:

1. Vertrag vom 25.10.2023, 0x2126E6952C3af75C9D4CF21f63F509195C79ce44

   • 3 % Emission pro Jahr (mit Zinseszinseffekt), davon 2 % für die Token-Hinterlegung und 1 % für die Gemeinschaftskasse.

2. Vertrag vom 06.07.2024, 0x5e875267f65537768435c3c6c81cd313a570b422

   • 2.5 % Emission pro Jahr (mit Zinseszinseffekt), davon 1,5 % für die Token-Hinterlegung und 1 % für die Gemeinschaftskasse.

3. Vertrag vom 04.09.2024, 0x152442D77E9fB9C210953d583Cbb2da88027fCB9

   • 2,5 % Emission pro Jahr (mit Zinseszinseffekt), davon 1,5 % für die Token-Hinterlegung und 1 % für die Gemeinschaftskasse.

4. Vertrag vom 09.07.2025, 0x282FD46E108E40A45e4CE425bA75f80245e6C2E0

   • 2 % Emission pro Jahr (mit Zinseszinseffekt), davon 1 % für die Token-Hinterlegung und 1 % für die Gemeinschaftskasse.

Nachgerechnet

Die initiale Ausgabemenge beträgt 10.000.000.000 POL. Wenn man die Emissionen stufenweise entlang der jeweils aktiven Vertragsversionen berechnet und Gas-Effekte ausblendet, ergibt sich eine theoretische maximale Umlaufmenge.

Auf Etherscan kann man die aktuelle Umlaufmenge einsehen. Am 31.03.2026 betrug
Circulating Supply: 10.617.468.716,00 POL

Die tatsächliche Umlaufmenge liegt daher etwas darunter – unter anderem weil Token-Anteile im Zuge von Transaktionsgebühren vernichtet werden. Zum Prüfzeitpunkt lag die Differenz bei rund 84.322 POL.

Hinweis:
Über die Tabellenkalkulation kann man, abhängig von der Emissionsrate, Prognosen treffen, wie sich das Polygon-Angebot in Zukunft entwickeln wird. Diese Werte sind eine modellhafte Fortschreibung und können je nach tatsächlichem Gasverbrauch und Rundungseffekten leicht abweichen. Für Ende 2026 erwarten wir weniger als 10.777.152.308 POL.

Das Ergebnis

Wir haben am 31.03.2026 eine Prüfung durchgeführt.

1. Zu diesem Zeitpunkt war der aktive Emission-Manager-Vertrag
   • 0x282fd46e108e40a45e4ce425ba75f80245e6c2e0.
2. Die im Vertrag hinterlegte Adresse für Token-Hinterlegungsbelohnungen (Staking Rewards) war
   • 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908.
3. Die eingetragene Adresse der Gemeinschaftskasse ist ein ERC-1967-Proxy-Vertrag. Etherscan führt die vorgelagerte Erstelleradresse mit dem Nametag “Agglayer: Deployer”; das ist ein Indiz für die Zuordnung im Polygon-Umfeld, aber kein alleinstehender Eigentumsnachweis. Der Proxy ist die dauerhaft eingerichtete Community-Treasury, die die temporäre Multi-Signature Wallet abgelöst hat:
   • 0x32bdc6a4e8c654df65503cbb0edc82b4ce9158e6 Etherscan-Nametag: Agglayer: Deployer
   • 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9 ERC-1967-Proxy-Vertrag
   • 0x2ff25495d77f380d5F65B95F103181aE8b1cf898 Multisignatur-Wallet

Unser Vergleich ergab:

1. INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18
2. START_SUPPLY = 10_000_000_000e18;
3. uint256 treasuryAmt = amountToMint / 2;
uint256 stakeManagerAmt = amountToMint - treasuryAmt;
4. version() = "1.4.0"
5. Arg[1]: stakeManager_ (address): 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908
6. Arg[2]: treasury_ (address): 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9
7. Circulating Supply
   • 10.617.468.716,00 POL - am 31.03.2026
   • 10.777.152.308,67 POL - zum 31.12.2026 erwartet

Fazit

Mit dieser 7-Schritte-Anleitung lässt sich die technische Prüfung der zentralen POL-Aussagen systematisch durchführen. Der entscheidende Punkt ist dabei: Man bleibt nicht bei allgemeinen Formulierungen aus Whitepaper, Blogposts oder Governance-Beiträgen stehen, sondern verfolgt jede relevante Aussage bis in den tatsächlich aktiven Vertrag auf der Blockchain.

Die Prüfung zeigt, dass sich drei Kernfragen sauber beantworten lassen:

• Die initiale Ausgabe von 10 Milliarden POL ist im Token-Vertrag direkt nachvollziehbar.
• Die spätere Emission folgt im aktuellen Code einer deterministischen Logik mit rund 2 % pro Jahr und Zinseszinseffekt.
• Über Proxy-Historie und Rollenvergabe lässt sich prüfen, welche Vertragsversion diese Logik aktuell tatsächlich ausführt.

Gerade der Abgleich zwischen GitHub, Etherscan und Governance-Quellen ist unverzichtbar. Ein Repository allein reicht nicht aus, wenn Verträge upgradefähig sind. Erst wenn klar ist, welche Implementierung aktiv war oder ist und welche Rechte der Proxy besitzt, wird aus einer Codelektüre eine belastbare technische Verifikation.

Für POL ergibt sich damit zum Prüfzeitpunkt ein konsistentes Bild: Die öffentlich kommunizierten Kernaussagen zu Startmenge, Emissionslogik und Verteilung auf Gemeinschaftskasse und Token-Hinterlegung lassen sich in den wesentlichen Punkten technisch nachvollziehen.

Gleichzeitig zeigt die Methode auch ihre Stärke über den Einzelfall hinaus. Sie ist nicht nur für Polygon nützlich, sondern generell für Token-Projekte mit Upgrade-Verträgen, Emissionsmechanismen und Governance-Strukturen. Wer so vorgeht, prüft nicht Erzählungen, sondern die tatsächlich wirksame technische Realität.