Merkle-Allowlist-Generator: Root und Beweise für Mint und Airdrop

02 / GRUNDLAGE

Eine Root im Vertrag, ein Beweis je Adresse

Die naheliegende Lösung wäre, alle berechtigten Adressen im Vertrag zu speichern. Das wird teuer. Jeder neu belegte Speicherplatz kostet mindestens 20.000 Gas, bei 10.000 Adressen also 200.000.000 Gas, nur fürs Eintragen. Ein Merkle-Baum dreht das um: Die Liste bleibt außerhalb der Chain, im Vertrag steht ein einziger Wert von 32 Byte.

So entsteht er. Aus jeder Zeile der Liste wird ein Hash, das Blatt. Je zwei Blätter werden zusammen gehasht, dann je zwei dieser Ergebnisse, bis ein Wert übrig ist, die Root. Ändert sich auch nur eine Ziffer in einer Menge, ändert sich die Root. Die Idee stammt aus einem Signaturverfahren von 1987, bei dem die Signatur nur logarithmisch mit der Zahl der Nachrichten wächst Merkle 1988.

Beim Claim schickt der Empfänger seinen Beweis mit (englisch Proof): die Geschwister-Hashes auf dem Weg von seinem Blatt zur Root. Der Vertrag rechnet den Weg nach und vergleicht das Ergebnis mit der gespeicherten Root. Das ist das Muster der authentifizierten Datenstrukturen, bei denen der Lieferant der Daten nicht vertrauenswürdig sein muss, weil der Empfänger den Beweis selbst prüft Tamassia 2003. Ihre Claim-Seite kann also keinen Eintrag erfinden; einen falschen Beweis lehnt der Vertrag ab.

Abb. 1 · Echte Werte aus vier Adressen des Beispiels (Format standard, nur Adresse), gekürzt. Beweis für 0x2222…2222: zwei Hashes.

Calldata mit 16 Gas je Byte (EIP-2028), Speicher mit 20.000 Gas je neuem Platz (Yellow Paper, G_sset; nach EIP-2929 kommen für einen kalten Platz 2.100 Gas dazu). Stand 14. November 2026.

Der Beweis wächst also kaum mit der Liste. Von 10.000 auf eine Million Adressen kommen 6 Hashes dazu. Den Beweis bezahlt der Empfänger mit seiner Transaktion; im Vertrag liegt nur die Root, egal wie lang die Liste ist.

03 / FORMAT

Welches Format? Das bestimmt der Vertrag

Die wichtigste Regel zuerst: Generator und Vertrag müssen das Blatt genau gleich bilden. Ein Byte Unterschied, und jeder Claim scheitert mit „Invalid proof". Darum fragt Schritt 1 nicht nach Vorlieben, sondern danach, was im Vertrag steht.

Nur Adresse: keccak256(bytes.concat(keccak256(abi.encode(account)))) bzw. keccak256(abi.encodePacked(account)). Nach OpenZeppelin merkle-tree 1.0.8, Contracts 5.7.0.

Warum OpenZeppelin zweimal hasht

Ein innerer Knoten des Baums entsteht aus 64 Byte, zwei aneinandergehängten Hashes. Wäre ein Blatt vor dem Hashen ebenfalls 64 Byte lang, ließe sich ein innerer Knoten als Blatt ausgeben. Genau so lang ist abi.encode(address, uint256). Mit dem zweiten Hash ist das ausgeschlossen, und in der Doku zu MerkleProof warnt OpenZeppelin ausdrücklich vor 64 Byte langen Blattwerten mit einfachem keccak256. Das einfache Format hat das Problem nicht, weil abi.encodePacked(address, uint256) nur 52 Byte ergibt. Wer weitere Felder ins Blatt nimmt, rechnet die Länge besser nach.

Sortierte Paare, sortierte Blätter

Beide Formate hängen die zwei Hashes eines Paars sortiert aneinander, den kleineren zuerst. So braucht der Beweis keine Angabe, ob ein Geschwister links oder rechts steht, und MerkleProof.verify aus OpenZeppelin prüft beide Formate. Auch die Blätter sortiert der Generator, wie OpenZeppelin. Andere Bibliotheken ordnen anders an, etwa merkletreejs ohne sortLeaves; dieselbe Liste ergibt dort eine andere Root. Falsch ist das nicht. Nur dürfen Root und Beweise dann nicht aus zwei verschiedenen Werkzeugen stammen.

Ob der Generator wirklich wie OpenZeppelin rechnet, prüft unser Test bei jeder Änderung. Das Beispiel aus dem README der Bibliothek, zwei Adressen mit Menge, ergibt die Root 0xd4dee0beab2d53f2cc83e567171bd2820e49898130a22622b10ead383e90bd77, Zeichen für Zeichen dieselbe wie dort. Die Testdateien aus dem Repository von OpenZeppelin rechnet er Knoten für Knoten nach. Eine Baumdatei aus Ihrem Projekt (tree.json) können Sie in Schritt 3 einfügen; der Generator sagt dann, ob sie noch zu ihren Werten passt.

Die häufigsten Fehler in Listen

• Tippfehler in Adressen. Nach EIP-55 steckt in der Groß- und Kleinschreibung eine Prüfsumme. Passt sie nicht, meldet der Generator die Zeile. Ganz klein geschriebene Adressen tragen keine Prüfsumme, dort fällt ein Tippfehler nicht auf; einzelne Adressen vergleicht der Ethereum-Adress-Prüfer Zeichen für Zeichen.
• Mengen aus Excel. Excel rechnet mit 15 Stellen Genauigkeit. Aus 5000000000000000001 wird beim Export schnell 5E+18, und die letzten Stellen sind weg. Der Generator lehnt diese Schreibweise ab; in der Tabelle die Spalte als Text formatieren.
• Token oder kleinste Einheit. Ein Token mit 18 Dezimalstellen sind 10¹⁸ kleinste Einheiten (wei), bei USDC sind es 6 Stellen. Schreiben Sie ganze Token, tragen Sie in Schritt 2 die Dezimalstellen ein; das Ergebnis nennt die Summe in beiden Einheiten zur Kontrolle.
• Dubletten. Dieselbe Adresse, einmal klein, einmal mit Prüfsumme geschrieben, ist für den Vertrag eine Adresse. Der Generator findet sie und fasst sie auf Wunsch zusammen; gleiche Zeilen streicht er, verschiedene Mengen addiert er.

04 / VERTEILEN

Verteilen oder abholen lassen?

Warum Projekte überhaupt Token verschenken, haben Allen, Berg und Lane an Airdrops von 2014 bis 2022 untersucht: vor allem als Marketing und um Eigentum und Kontrolle breiter zu streuen Allen u. a. 2023. Die Verteilung soll also viele erreichen und dabei nicht mehr kosten, als sie bringt.

Grundsätzlich gibt es zwei Wege. Beim Push überweist der Verteiler jedem Empfänger selbst. Beim Pull holen die Empfänger ab, und genau das ist ein Merkle-Claim. Fröwis und Böhme haben 35 Szenarien durchgerechnet: Pull spart dem Verteiler nur mäßig und legt jedem Empfänger unverhältnismäßig hohe Kosten auf, und insgesamt wachsen die Kosten bei allen Verfahren ungefähr linear mit der Zahl der Empfänger Fröwis und Böhme 2019. Ein Merkle-Claim lohnt sich deshalb weniger wegen der Gebühren als wegen der Ordnung: Die Liste bleibt aus dem Vertrag heraus, und abgeholt wird nur, was jemand wirklich haben will.

Bei kleinen Beträgen kann es halt passieren, dass die Gebühr für den Claim höher ist als das, was abgeholt wird. Dann eher auf einer günstigen Layer-2-Chain verteilen oder eine Mindestmenge setzen. Was ein Claim bei aktuellen Gaspreisen kostet, rechnet der Gas-Rechner.

NFT-Mint: Allowlist statt Wettbieten

Bei einem offenen Mint mit knapper Menge überbieten sich Käufer mit Gasgebühren. Das treibt die Gebühren für alle hoch und verschwendet Gas, wie eine Untersuchung zu NFT-Starts zeigt, die als Ausweg eine Verlosung vorschlägt Ko u. a. 2023. Eine Allowlist mit festem Zeitfenster nimmt den Wettlauf ebenfalls heraus. Aufs Vordrängeln haben sich Bots spezialisiert, die offene Transaktionen mitlesen und mit höheren Gebühren überholen Daian u. a. 2020.

Daraus folgt eine Regel für den Vertrag: Die Adresse im Blatt und der Empfänger müssen dieselbe sein. Am einfachsten bildet der Vertrag das Blatt aus msg.sender, so wie im Solidity-Ausschnitt des Generators. Ein Beweis, den jemand im Mempool mitliest, nützt ihm dann für sich selbst nichts.

05 / MEHRFACHKONTEN

Was die Liste nicht leistet: Mehrfachkonten und Datenschutz

Ein Merkle-Baum prüft, ob eine Adresse auf der Liste steht. Ob hinter zehn Adressen zehn Menschen stehen oder einer, weiß er nicht. Das ist ein altes Ergebnis der Informatik: Ohne eine Stelle, die Identitäten bestätigt, lassen sich Mehrfach-Identitäten (Sybil-Angriffe) nicht verhindern, außer unter unrealistischen Annahmen Douceur 2002. Die Dublettenprüfung findet deshalb nur dieselbe Adresse, auch in anderer Schreibweise.

• Airdrop-Jäger sind Alltag. Am Airdrop von ParaSwap beschreiben Fan und Kollegen mehrere Muster, mit denen Teilnehmer abschöpfen, und die übliche Erkennung siebte sie nicht ausreichend aus Fan u. a. 2023. Bessere Verfahren werten Transaktionsgraphen und Metadaten aus Zhou u. a. 2024; dafür braucht es Daten der Chain, die Liste allein reicht nicht.
• Regeln werden ausgereizt. Sobald Kriterien bekannt sind, passen sich Nutzer an. Allen beobachtet deshalb immer verwickeltere Kriterien und erwartet Airdrops in mehreren Runden Allen 2024. Jede Runde bekommt ihre eigene Root; Beweise aus der alten gelten dann nicht mehr.
• Handelsvolumen ist kein sauberes Kriterium. In den 52 größten NFT-Sammlungen fielen 3,93 Prozent der Adressen mit Mustern auf, die nach Scheinhandel aussehen, meist zwischen wenigen Adressen hin und her von Wachter u. a. 2023.
• Aufgaben locken Skripte an. Ein Quest-System mit 80 Millionen erledigten Aufgaben zog Farming und Bots an, und echte Nutzer ließen sich schwer von Skripten trennen Al-Chami und Clark 2025. Kriterien, die ein Skript nicht billig erfüllt, halten länger.
• Gegenmittel liegen außerhalb der Liste. Nachweise, dass hinter einer Adresse ein Mensch steht, etwa über Bürgen und Abstimmen in der Gemeinschaft, sind ein eigenes Feld mit eigenen Schwächen Siddarth u. a. 2020.

Die Liste wird öffentlich

Root und Beweise sind öffentlich, sobald der Vertrag läuft, und jeder Claim legt Adresse und Menge auf der Chain offen. Baumdatei und Beweisdatei enthalten sogar die komplette Liste. Wie viel sich aus solchen Daten ablesen lässt, zeigt eine Untersuchung des Clam-Airdrops von 2014: Über die Aktivität auf der neuen Chain ließen sich Adressen derselben Person auf drei anderen Blockchains verknüpfen Harrigan u. a. 2018. Stammt die Liste aus Ihrer Kundendatei, gehört die Veröffentlichung vorher in die Datenschutzprüfung. Der Generator selbst schickt nichts weg, er rechnet in Ihrem Browser.

06 / VORGEHEN

So setzen Sie eine Allowlist um

1. Kriterien und Stichtag festschreiben. Wer bekommt wie viel, und auf welchem Block beruht die Auswahl? Schriftlich, bevor die Liste entsteht; sonst lässt sich später nicht erklären, warum eine Adresse fehlt.
2. Liste sauber exportieren. Mengen als Text, nicht als Zahl, und klar in kleinsten Einheiten oder in ganzen Token.
3. Format nach dem Vertrag wählen. Neuer Vertrag: das Format von OpenZeppelin. Bestehender Vertrag: nachsehen, wie er das Blatt bildet, und Schritt 1 danach einstellen.
4. Auf dem Testnetz abholen. Root in den Vertrag, dann zwei, drei Adressen echt claimen lassen, auch eine, die nicht auf der Liste steht. Scheitert etwas, zeigt die Beweisprüfung, wo der Weg abbricht.
5. Liste und Baumdatei aufbewahren. Aus genau derselben Liste rechnet der Generator wieder dieselbe Root. Ändert sich eine Zeile, passt nichts mehr.
6. Das Ende gleich mit einplanen. Eine Frist für den Claim und eine Funktion, die Reste zurückholt, gehören in den Vertrag, bevor er läuft. Bei einem Vertrag ohne Upgrade lässt sich das später nicht nachrüsten.

Wo der Generator aufhört

• Keine Prüfung auf Mehrfachkonten. Er findet gleiche Adressen, nicht mehrere Adressen einer Person.
• Ein Baumlayout. Das von OpenZeppelin mit sortierten Blättern. Bäume aus anderen Bibliotheken baut er nicht nach; deren einzelne Beweise prüft die Beweisprüfung trotzdem.
• Blätter aus address und uint256. Weitere Felder wie eine laufende Nummer, Multiproofs und eigene Hashfunktionen sind nicht dabei.
• Kein Blick auf die Chain. Er liest weder Salden noch Verträge und ersetzt keine Prüfung des Vertrags.

Vertrag, Claim-Seite und Anbindung an Wallets bauen wir unter Web3-Entwicklung. Was eine Transaktion tatsächlich aufruft, bevor jemand sie unterschreibt, zeigt der Calldata-Decoder. Alle Web3-Werkzeuge stehen in der Übersicht Web3.

07 / FORSCHUNG

Was die Forschung dazu sagt

Fünf Befunde tragen die Hinweise im Generator. Die vollständige Liste mit Prüfvermerk steht weiter unten.

• Der Beweis wächst logarithmisch. Daher reichen bei 10.000 Adressen 13 oder 14 Hashes Merkle 1988, und der Vertrag prüft sie selbst Tamassia 2003.
• Abholen lassen verlagert Kosten. Pull spart dem Verteiler mäßig und belastet jeden Empfänger Fröwis und Böhme 2019; darum der Hinweis auf kleine Beträge.
• Eine Adresse ist keine Person. Ohne Identitätsstelle bleiben Mehrfachkonten möglich Douceur 2002, und Airdrop-Jäger sind gut belegt Fan u. a. 2023.
• Offene Transaktionen werden mitgelesen. Bots bieten um die Reihenfolge Daian u. a. 2020; darum hängt das Blatt im Solidity-Ausschnitt an msg.sender.
• Airdrop-Daten verraten Zusammenhänge. Adressen einer Person lassen sich über Chains hinweg verknüpfen Harrigan u. a. 2018; darum der Hinweis zur Veröffentlichung der Liste.

08 / FÜR KI-ASSISTENTEN

Dieses Werkzeug aus einem KI-Assistenten nutzen

Assistenten wie Claude oder ChatGPT, die das Model Context Protocol (MCP) sprechen, können die Rechnung dieser Seite direkt aufrufen, statt sie nachzubauen. Der Server ist öffentlich, braucht keine Anmeldung und speichert nichts. Die Antwort enthält immer den Link auf diese Seite, den Stand der Daten und die Grenzen des Ergebnisses.

Endpunkt

https://aureum-tech.com/mcp

Werkzeug

werkzeug_merkle_allowlist

Transport

Streamable HTTP, nur lesend

Fragen, bei denen ein Assistent es aufrufen sollte

• „Erzeuge eine Merkle-Root für diese Allowlist im Format von OpenZeppelin und gib mir den Beweis für die erste Adresse."
• „Wie lautet die Merkle-Root für diesen Airdrop mit Adresse und Menge in wei, und wie prüfe ich das Blatt in Solidity?"
• „Passt dieser Merkle-Beweis zu meiner Root, oder rechnet mein Vertrag mit abi.encodePacked statt abi.encode?"
• „Stimmt meine tree.json von StandardMerkleTree noch mit den Werten darin überein?"

Wie die Anbindung funktioniert und was MCP im eigenen Betrieb leisten kann, steht auf der Seite zu MCP-Integrationen.

09 / HÄUFIGE FRAGEN

Häufige Fragen zu Merkle-Root, Proof und Allowlist