Kostenloser Ethereum-ABI-Decoder

uint256, address, bool, string und bytes32. Dynamische Typen (Arrays, Tupel) erfordern eine manuelle Prüfung.

Die ersten 4 Bytes der Aufrufdaten, abgeleitet aus dem keccak256-Hash der Funktionssignatur (z. B. "transfer(address,uint256)").

Ja, völlig kostenlos.

Absolut. Der Ethereum-ABI-Decoder verarbeitet alles clientseitig in deinem Browser. Es werden keine Daten auf einen Server hochgeladen oder dort gespeichert. Deine Inhalte bleiben jederzeit privat auf deinem Gerät.

Ja, der Ethereum-ABI-Decoder ist vollständig responsiv und funktioniert auf Smartphones und Tablets. Du kannst ihn auf jedem Gerät mit einem modernen Webbrowser nutzen, ganz ohne App-Download.

Es ist kein Konto und keine Registrierung erforderlich. Öffne einfach den Ethereum-ABI-Decoder in deinem Browser und beginne sofort mit der Nutzung. Es gibt keine Anmeldeschranken oder Nutzungsbeschränkungen.

Gib einfach deine Daten in das vorgesehene Feld ein, passe die Einstellungen nach Wunsch an, und das Tool verarbeitet sie sofort. Anschließend kannst du das Ergebnis in die Zwischenablage kopieren oder herunterladen.

Der Ethereum-ABI-Decoder funktioniert in allen modernen Browsern, einschließlich Chrome, Firefox, Safari, Edge und Opera. Für das beste Erlebnis verwende die neueste Version deines bevorzugten Browsers.

Ein uint256 in der Calldata ist eine reine Ganzzahl ohne Dezimalpunkt, weshalb ein Token-Transferbetrag als sehr große Zahl in der kleinsten Einheit des Tokens erscheint. Bei den meisten ERC-20-Token bedeutet das Wei-artige Einheiten mit 18 Dezimalstellen: Der Wert 1000000000000000000 (0xde0b6b3a7640000) entspricht exakt 1 Token. Zum Umrechnen teilst du die dekodierte Ganzzahl durch 10 hoch der Dezimalstellenzahl des Tokens. USDC und USDT verwenden 6 Dezimalstellen, sodass 1000000 gleich 1,00 ist, während WBTC 8 Dezimalstellen nutzt. Der Decoder liest den 32-Byte-Block big-endian und zeigt dir die exakte Ganzzahl samt dem rohen Hexwert, aus dem sie stammt, sodass du den Betrag selbst überprüfen kannst. Füge dein ABI und deine Calldata ein, um die genaue Zahl zu sehen, bevor du einer Wallet-Anfrage vertraust.

Der Decoder berechnet für jede Funktion in deinem ABI einen Keccak-256-Selector und vergleicht ihn mit den ersten 4 Bytes deiner Calldata. Gibt es keine Übereinstimmung, bedeutet das, dass das eingefügte ABI nicht die Funktion enthält, die tatsächlich aufgerufen wurde. Häufige Ursachen sind das ABI des falschen Contracts, ein Proxy-Contract, der Aufrufe an eine andere Implementierung weiterleitet, oder ein ABI, dem die spezifische Funktion fehlt. Schon ein einzelnes abweichendes Zeichen in einem Parametertyp, etwa uint statt uint256, verändert den Selector und verhindert den Abgleich. Die Lösung besteht darin, das verifizierte ABI für den exakten Contract aus einem Block-Explorer zu laden und erneut zu dekodieren. Die Fehlermeldung selbst ist ein nützliches Signal dafür, dass die Transaktion nicht das ist, was du angenommen hast. Prüfe die Quelle noch einmal und versuche es mit dem richtigen ABI erneut.

Ein Function Selector besteht aus nur 4 Bytes, dem führenden Ausschnitt des Keccak-256-Hashes einer kanonischen Signatur wie transfer(address,uint256), der angibt, auf welche Funktion eine Transaktion abzielt. Er verrät dir die Funktion, aber nichts über Parameternamen oder wie die nachfolgenden Bytes zu interpretieren sind. Ein vollständiges ABI ist die komplette JSON-Beschreibung der Funktionen eines Contracts, einschließlich Name und Typ jedes Inputs sowie der Outputs. Der Decoder benötigt das ABI und nicht nur den Selector, denn die 32-Byte-Argumentblöcke sind bedeutungslos, solange du nicht weißt, dass einer eine address und der nächste einen uint256 enthält. Mit nur einem Selector kannst du nach einer wahrscheinlichen Signatur suchen; mit dem ABI erhältst du benannte, typisierte Werte. Füge das ABI-Array hier ein, um rohes Hex in eine beschriftete Parameteraufschlüsselung zu verwandeln.

Es verarbeitet string und bytes nach den ABI-Kodierungsregeln: Der statische Block enthält einen Offset-Zeiger auf einen separaten Bereich, in dem zuerst die Länge und anschließend die eigentlichen Daten gespeichert sind. Der Decoder liest diesen Zeiger aus, springt zur Länge und rekonstruiert den Text- oder Hexwert. Statische Typen fester Größe wie uint256, int, address, bool und bytes32 belegen jeweils einen einzigen 32-Byte-Block und werden jedes Mal sauber dekodiert. An seine Grenzen stößt das Tool bei komplexen dynamischen Strukturen wie Arrays variabler Länge und verschachtelten Tupeln, die eine mehrteilige Kodierung nutzen und eher eine manuelle Prüfung als einen einzelnen sauberen Wert erfordern können. Bei alltäglichen Aufrufen wie ERC-20-Transfers, Genehmigungen und einfachen Settern ist die automatische Ausgabe vollständig. Füge deine Calldata ein, um zu sehen, welche Parameter sich direkt auflösen lassen.

Ausgangspunkt ist die kanonische Signatur: der Funktionsname gefolgt von seinen Parametertypen in Klammern, durch Kommas getrennt, ohne Leerzeichen und ohne Parameternamen, zum Beispiel transfer(address,uint256). Diese exakte Zeichenfolge wird durch die Keccak-256-Hashfunktion geschickt, und man nimmt die ersten 4 Bytes des 32-Byte-Ergebnisses. Für transfer ergibt das 0xa9059cbb. Die kanonische Form ist entscheidend, denn uint muss als vollständiges Alias uint256 geschrieben werden und int als int256 — sonst ändern sich Hash und Selector komplett. Dieses Tool berechnet Selektoren mit einer integrierten Keccak-256-Implementierung direkt in deinem Browser und benötigt daher niemals umständliche Online-Signaturdatenbanken, um einen Aufruf zuzuordnen. Lade das ERC-20-Transfer-Beispiel, um zu sehen, wie eine echte Signatur zu ihrem Selector aufgelöst wird, und setze dann deine eigene Funktion ein, um zu prüfen, was eine Transaktion tatsächlich aufruft.