Ein Solana Transaction Explorer macht aus einer rohen Signatur eine lesbare Seite: War die Transaktion erfolgreich, wer hat sie signiert, was hat sie gekostet und welche Token wurden bewegt? Jeder Explorer, von Solscan über den offiziellen Solana Explorer bis zu unserem eigenen Such-Tool, liest denselben On-Chain-Datensatz über die RPC-Methode getTransaction. Wenn du einmal weißt, was die einzelnen Felder bedeuten, kannst du also jeden von ihnen lesen. Unten findest du eine Routine in sechs Schritten, eine Feld-für-Feld-Erklärung der Transaktionsseite, ein durchgerechnetes Beispiel mit einem echten SPL-Token-Transfer und einen Abschnitt zur Fehlersuche für Transaktionen, die fehlschlagen, verschwinden oder verworfen werden.
Solana Transaktion prüfen in sechs Schritten
Am schnellsten prüfst du eine Transaktion, indem du ihre Signatur kopierst, sie in einen Explorer auf dem richtigen Cluster einfügst und zuerst die Statuszeile liest. Alles andere auf der Seite erklärt, warum der Status so ist, wie er ist.
- Transaktionssignatur kopieren. In der Aktivitätsansicht deiner Wallet oder in der Bestätigungsmeldung der dApp findest du einen Link „View on Explorer“ oder einen Kopier-Button. Die Signatur ist Base58-Text, meist 87 oder 88 Zeichen lang.
- In einen Explorer einfügen. Nutze das Such-Tool von Solscanner, Solscan oder Solana Explorer und prüfe, ob der Mainnet-Cluster ausgewählt ist und nicht Devnet.
- Status und Finalität prüfen. Erfolgreich oder fehlgeschlagen ist die Schlagzeile. Daneben steht processed, confirmed oder finalized.
- Gebühr, Compute und Signer lesen. Diese Felder verraten, wer bezahlt hat, wie viel und wie aufwendig die Transaktion war.
- Instructions und Guthaben ansehen. Die Instruction-Liste und die Token-Guthabenänderungen zeigen, was tatsächlich zwischen welchen Accounts bewegt wurde.
- Fehler mit den Logs erklären. Ist etwas schiefgegangen, nennen die Programm-Logs die Instruction und den Fehler.
Mit dieser Routine beantwortest du die meisten Fragen vom Typ „Ist meine Überweisung angekommen?“ in unter einer Minute. Der Rest dieses Ratgebers erklärt, was du bei jedem Schritt siehst, damit du die Seite liest, statt zu raten.
Was jedes Feld auf der Transaktionsseite im Solana Explorer bedeutet
Eine Transaktionsseite im Solana Explorer hat überall dieselben Kernfelder: Signatur, Ergebnis, Commitment, Slot, Block Time, Gebühr, Compute Units, Signer, Recent Blockhash, Version, Instructions, Guthabenänderungen und Logs. Die Layouts unterscheiden sich, die Daten stammen aber aus einer einzigen RPC-Antwort.
Signatur. Eine Transaktionssignatur ist die 64-Byte-Ed25519-Signatur des ersten Signers, kodiert in Base58. Sie dient zugleich als eindeutige ID der Transaktion. Hat eine Transaktion mehrere Signer, trägt sie mehrere Signaturen, Explorer indexieren sie aber über die erste.
Status. Entweder Erfolg oder ein Fehler wie InstructionError mit dem Index der fehlgeschlagenen Instruction. Auch eine fehlgeschlagene Transaktion wird on-chain gespeichert und zahlt ihre Gebühr.
Commitment (processed, confirmed, finalized). Das sind die drei Finalitätsstufen. Processed heißt, dass der abgefragte Knoten die Transaktion in einem Block gesehen hat, über den aber noch nicht abgestimmt wurde. Confirmed heißt, dass eine Supermehrheit des Stakes über den Block abgestimmt hat. Finalized heißt, dass der Block den maximalen Lockout erreicht hat und nicht mehr zurückgerollt werden kann. Lies processed als „wahrscheinlich“, confirmed als „so gut wie sicher“ und finalized als „erledigt“. Alpenglow, das im September 2026 im Testnet läuft und noch keinen Mainnet-Termin hat, soll die Finalität auf etwa 150 ms senken. Diese Stufen könnten also künftig zusammenfallen.
Slot und Block Time. Der Slot ist das Zeitfenster des Leaders, in dem die Transaktion gelandet ist. Slots dauern heute etwa 250–300 ms, nachdem SIMD-0525 sie im August und September 2026 von 400 ms verkürzt hat. Die Block Time ist der geschätzte Unix-Zeitstempel dieses Blocks und wird von den meisten Explorern in deiner lokalen Zeitzone angezeigt, in Deutschland, Österreich und der Schweiz also in MEZ bzw. MESZ.
Gebühr und Priority Fee. Die Grundgebühr beträgt 5.000 Lamports pro Signatur (0,000005 SOL). 50 % werden verbrannt, 50 % gehen an den Validator. Optional kommt eine Priority Fee obendrauf: Compute-Unit-Preis mal Compute-Unit-Limit, geteilt durch 1.000.000, und sie geht vollständig an den Validator. Die vollständige Formel steht in der Solana-Dokumentation zu Gebühren. Manche Explorer zeigen beide Anteile getrennt, andere nur die Summe.
Compute Units. Die verbrauchten Compute Units messen die Ausführungskosten. Das Standardbudget liegt bei 200.000 CU pro Instruction, die harte Obergrenze bei 1.400.000 CU pro Transaktion. Verbraucht eine Transaktion fast ihr gesamtes angefragtes Limit, ist das ein Hinweis darauf, dass sie wegen fehlender Rechenkapazität gescheitert ist.
Signer und Fee Payer. Der erste Signer ist der Fee Payer. Weitere Signer haben bestimmte Instructions autorisiert, zum Beispiel der Eigentümer eines Token-Accounts, von dem abgebucht wird.
Recent Blockhash. Jede Transaktion verweist auf einen aktuellen Blockhash, der 150 Slots gültig ist. Er verhindert Wiederholungen und setzt eine Frist: Wird die Transaktion nicht vor Ablauf des Blockhashs aufgenommen, kann sie nie mehr landen.
Versionierte Transaktionen und Address Lookup Tables
Eine versionierte Transaktion (angezeigt als „v0“ oder „Version 0“) kann auf eine Address Lookup Table verweisen, einen On-Chain-Account mit einer Liste von Adressen. Statt jede 32-Byte-Adresse in die Nachricht zu schreiben, zeigt die Transaktion auf Einträge in dieser Tabelle. So passen große Swaps in das Limit von 1.232 Byte. Explorer markieren solche Accounts in der Account-Liste als „loaded from lookup table“, die Bezeichnung „legacy“ steht einfach für das ältere Format ohne Tabellen. Die Dokumentation zu Transaktionen beschreibt den Aufbau der Nachricht.
Hinweis: Eine Transaktion kann höchstens 64 Accounts auflisten. Siehst du eine längere Account-Liste als erwartet, wurde der Großteil vermutlich aus einer Address Lookup Table geladen und nicht direkt in die Nachricht geschrieben.
Instructions, Inner Instructions und Token-Guthabenänderungen
Instructions sind die eigentlichen Operationen: Jede nennt ein Programm und die Accounts, die es berührt. Inner Instructions sind Aufrufe, die ein Programm während der Ausführung an ein anderes richtet, und die Token-Guthabenänderungen fassen das Nettoergebnis zusammen.
Eine einfache SOL-Überweisung hat eine Instruction des System Program. Ein Token-Transfer ruft das SPL Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) oder Token-2022 (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) auf. Ein Swap über einen Aggregator zeigt womöglich eine einzige Top-Level-Instruction und ein Dutzend Inner Instructions, weil der Router mehrere DEX-Pools aufruft, die ihrerseits das Token-Programm aufrufen. Wenn du wissen willst, was wirklich passiert ist, schaust du in die Inner Instructions. Für Pools und Router erklärt unser Ratgeber zum DeFi-Explorer, wie du Liquidität über Programme hinweg verfolgst.
Der Abschnitt mit den Token-Guthaben ist die Zusammenfassung in Klartext: Guthaben vorher, Guthaben nachher und die Differenz für jeden berührten Token-Account. Diesen Abschnitt machst du als Screenshot, wenn jemand einen Zahlungsnachweis verlangt. Token-Accounts sind von Wallets getrennt, die Zeilen zeigen daher Token-Account-Adressen mit ihrem Owner daneben. Der Ratgeber zum Wallet Explorer erklärt Associated Token Accounts genauer, und der Ratgeber zum Token Explorer behandelt Mints und Dezimalstellen.
Programm-Logs lesen
Programm-Logs sind die Textmeldungen, die Programme während der Ausführung ausgeben. Sie sind das nützlichste Feld überhaupt, wenn eine Transaktion fehlschlägt, weil der Fehler meist in den letzten Zeilen ausgeschrieben steht.
Logs liest du von oben nach unten wie einen Call Stack: „Program X invoke [1]“, Meldungen, „Program X consumed N of M compute units“, „Program X success“. Ein fehlgeschlagener Durchlauf endet mit „failed:“ und einem Fehler wie insufficient funds, slippage tolerance exceeded oder einem Custom-Error-Code. Custom-Codes sind programmspezifisch. Du entschlüsselst sie mit der IDL des Programms, die Solana Explorer und Orb für verifizierte Programme anzeigen.
Beispiel im Solana Transaction Explorer: ein echter SPL-Token-Transfer
Hier ist eine echte Mainnet-Transaktion, die du selbst öffnen kannst. Es ist ein einfacher SPL-Token-Transfer und damit ein sauberes Beispiel, um das Layout kennenzulernen.
WdQE153MoVzxf54wemBxUPXo88x6FDC4VDX2B2zKR9tF2j42QyaM1ub4R8ww7iY2fPcJ3b9F15eMcxCyVu9Sn4X
Füge diese Signatur in unser Such-Tool ein, und du siehst folgende Werte:
| Feld | Wert | Was es dir sagt |
|---|---|---|
| Status | Success | Alle Instructions ausgeführt |
| Slot | 449.561.050 | Wo sie on-chain gelandet ist |
| Gebühr | 5.000 Lamports | Nur Grundgebühr, eine Signatur |
| Priority Fee | 0 Lamports | Kein Aufpreis geboten |
| Compute Units | 13.594 | Leichte Arbeit des Token-Programms |
| Signer | ATAPZ…edYj5 | Fee Payer und Authority |
Lies sie wie einen Kassenbon. Die Gebühr beträgt genau 5.000 Lamports, also eine Signatur zum Grundtarif. Der Absender hat demnach keine Priority Fee gezahlt, und es gibt genau einen Signer: ATAPZxbrc7BAiunpoQPeGiPUbQgx5mGTNgyZgMPedYj5. Dieser Account hat die Gebühr bezahlt und zugleich die Abbuchung von seinem Token-Account autorisiert. Die 13.594 Compute Units sind ein kleiner Bruchteil des Standardbudgets von 200.000 CU, typisch für einen einzelnen Transfer über das Token-Programm. In der Instruction-Liste siehst du den Transfer des Token-Programms, und bei den Token-Guthabenänderungen sinkt ein Account um denselben Betrag, um den ein anderer steigt. Öffnest du dieselbe Signatur bei Solscan oder Solana Explorer, stimmen die Zahlen überein, denn alle drei lesen dasselbe Ledger.
So prüfst du eine Transaktion bei Solscan und anderen Explorern
Solscan, Solana Explorer und Orb akzeptieren alle eine Signatur im Hauptsuchfeld und zeigen dieselben Felder mit unterschiedlicher Gewichtung. Welchen du nimmst, ist vor allem eine Frage deiner Lesegewohnheiten.
Solscan setzt eine Übersichtskarte an den Anfang und verschiebt Token-Transfers in einen eigenen Tab. Deshalb landen viele, die „Solscan Transaktion prüfen“ suchen, genau dort. Unser Solscan-Test erklärt die Tabs im Detail. Der Solana Explorer der Solana Foundation zeigt rohe Instruction-Daten, ein Compute-Unit-Profiling und eine Simulationsoption, was Entwickler schätzen. Orb von Helius ergänzt KI-generierte Zusammenfassungen in Klartext, die beschreiben, was eine Transaktion getan hat. Ein direktes Urteil findest du im Ranking der besten Solana-Explorer. Für Jito-Bundles, bei denen mehrere Transaktionen zusammen mit einem Tip landen, ist der Ratgeber zum Jito Bundle Explorer der bessere Einstieg.
Transaktion nicht gefunden, fehlgeschlagen oder verworfen: so behebst du es
„Not found“ bedeutet meist, dass die Transaktion nie gelandet ist. „Failed“ heißt, sie ist gelandet, aber eine Instruction hat einen Fehler ausgelöst. „Dropped“ heißt, sie ist abgelaufen, bevor ein Leader sie aufgenommen hat. Für jeden Fall gibt es eine andere Lösung.
Transaktion nicht gefunden
Schließe zuerst die einfachen Fehler aus. Prüfe, ob du die ganze Signatur kopiert hast, denn fehlt das letzte Zeichen, entsteht ein gültig aussehender, aber unbekannter String. Prüfe den Cluster: Eine Devnet-Signatur taucht niemals im Mainnet auf, und der Ratgeber zum Devnet-Explorer listet die richtigen URLs. Warte dann ein paar Sekunden und suche erneut, denn ein hinterherhinkender Knoten hat den Block vielleicht noch nicht indexiert. Fehlt sie auch nach Ablauf des Blockhash-Fensters (150 Slots, bei heutigen Slot-Zeiten deutlich unter einer Minute), wurde die Transaktion nicht aufgenommen.
Transaktion fehlgeschlagen
Eine fehlgeschlagene Transaktion erscheint mit einem Fehler on-chain, und die Gebühr wird berechnet. Scroll zu den Logs und lies die letzte Zeile mit „failed“. Häufige Ursachen sind Slippage bei Swaps, zu wenig verbleibendes SOL für die Rent, ein Token-Account, der noch nicht existiert, oder ein überschrittenes Compute-Limit. Behebe die Ursache und sende eine neue Transaktion. Dieselbe signierte Nachricht noch einmal zu senden, hilft nicht.
Transaktion verworfen
Eine verworfene Transaktion wurde ans Netzwerk geschickt, aber kein Leader hat sie aufgenommen, bevor ihr Recent Blockhash ablief. Es gibt überhaupt keinen Signatur-Eintrag, also wurde keine Gebühr berechnet und nichts bewegt. Überlastung und eine Priority Fee von null sind die üblichen Gründe. Deine Wallet kann sie mit einem frischen Blockhash und einer kleinen Priority Fee erneut senden. Scheint eher der Explorer als die Transaktion das Problem zu sein, listet unsere Seite Explorer down? Alternativen auf, und die Referenz zu getTransaction zeigt, was der zugrunde liegende RPC-Aufruf zurückgibt.
Warum ein Solana Transaction Explorer mehr zeigt als der Wallet-Verlauf
Die Aktivitätsliste einer Wallet ist eine Zusammenfassung, die die Wallet-App schreibt. Ein Solana Transaction Explorer zeigt die maßgebliche Quelle on-chain. Widersprechen sich beide, vertraust du dem Explorer.
Wallets verstecken Inner Instructions, runden Guthaben und bezeichnen Swaps manchmal fälschlich als Überweisungen. Außerdem helfen sie nicht, wenn eine Gegenpartei behauptet, sie habe dich bezahlt. Mit der Signatur in der Hand kann jeder in Sekunden Status, Finalität und die genaue Token-Bewegung prüfen, ohne Konto und ohne einer der beiden Seiten vertrauen zu müssen. Genau dafür gibt es ein öffentliches Ledger, und es dauert etwa dreißig Sekunden, sobald du weißt, welche Felder du lesen musst. Die Signatur ist übrigens auch der sauberste Beleg für deine eigenen Unterlagen, etwa wenn du Käufe und Verkäufe später für das Finanzamt dokumentieren willst. Bist du ganz neu bei Explorern, starte mit der Frage, was ein Solana Explorer ist, und komm für die Details hierher zurück.
Von der Solscanner-RedaktionAktualisiert · Testmethodik