Solana Programm-Explorer: den Smart Contract prüfen, bevor du ihm vertraust

Ein Solana Programm-Explorer ist die Stelle, an der du einen Smart Contract prüfst, bevor du irgendetwas signierst, das ihn berührt. Die Programmseite zeigt, ob der Code ausführbar ist, welcher Loader ihn besitzt, ob eine Upgrade Authority ihn noch ersetzen kann, ob es einen verifizierten Build des Quellcodes gibt und, bei Anchor-Programmen, eine IDL, die jede Instruktion lesbar macht. Dieser Ratgeber geht jedes Feld an einem echten Beispiel durch, dem Pump.fun-Programm, und endet mit einer kurzen Sicherheits-Checkliste, die du in zwei Minuten auf Solana Explorer, Solscan oder Orb abarbeiten kannst.

Was ist ein Programm-Account auf Solana?

Ein Programm-Account ist ein On-Chain-Account, der als ausführbar (executable) markiert ist und kompilierten Code enthält oder auf ihn verweist. „Programm“ ist auf Solana schlicht das Wort für das, was andere Chains Smart Contract nennen.

Programme auf Solana sind zustandslos. Sie speichern selbst keine Guthaben und keine Nutzerdaten; diese liegen in separaten Accounts, die dem Programm gehören. Wenn du ein Programm aufrufst, übergibt deine Transaktion die benötigten Accounts, und das Programm liest und schreibt sie. Deshalb sieht eine Programmseite im Explorer ganz anders aus als eine Wallet-Seite: Spannend ist nicht der Kontostand, sondern wer den Code ändern darf und was der Code tut.

Die meisten Programme werden heute mit dem BPF Upgradeable Loader (BPFLoaderUpgradeab1e11111111111111111111111) deployt. Bei diesem Loader ist der Programm-Account selbst winzig. Für das Pump.fun-Programm 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P liefert ein roher getAccountInfo-Aufruf gerade einmal 36 Byte Daten, executable: true, den Upgradeable Loader als Owner und ein einziges geparstes Feld: programData. Der eigentliche Code liegt woanders. Falls dir Accounts generell noch neu sind: Die offizielle Dokumentation zu Accounts ist die klarste Einführung (auf Englisch, lässt sich aber gut mit dem Browser übersetzen).

Program-Data-Account und Upgrade Authority erklärt

Der Program-Data-Account speichert den eigentlichen Bytecode plus zwei Metadaten: den Slot des letzten Deployments und die Upgrade Authority. Die Upgrade Authority ist das wichtigste Feld auf jeder Smart-Contract-Seite im Explorer.

Beim Pump.fun-Beispiel zeigt das Feld programData auf B5MvUwXdiW1NMM6QFFD3ssPKBujD4zMohncbM73Z2BQu. Als wir diesen Account am 23. September 2026 abgefragt haben, war dort die Upgrade Authority 7gZufwwAo17y5kg8FMyJy2phgpvv9RSdzWtdXiWHjFr8 eingetragen. Auf gut Deutsch: Wer diesen Schlüssel kontrolliert, kann neuen Pump.fun-Code deployen. Für ein aktiv weiterentwickeltes Protokoll ist das normal, es heißt aber, dass du dem Team vertraust und nicht nur dem Code.

Die Explorer stellen das unterschiedlich dar. Solana Explorer zeigt in der Programmübersicht die Program-Data-Adresse, die Upgrade Authority und den Slot des letzten Deployments. Solscan und Orb zeigen dieselben Fakten, ergänzt um Labels, sofern sie die Adresse kennen. Du kannst den Check mit jedem RPC-Client nachvollziehen oder die Programmadresse in unser Such-Tool einfügen und dir den rohen Account ansehen.

Worauf du achten solltest:

• Eine einzelne Wallet als Authority. Ein einziger kompromittierter Schlüssel könnte das Programm austauschen. Höheres Risiko.
• Ein Multisig- oder Governance-Account. Änderungen brauchen mehrere Unterzeichner oder eine Abstimmung. Geringeres Risiko und bei großen Protokollen üblich.
• Gar keine Authority. Das Programm ist unveränderlich. Mehr dazu im nächsten Abschnitt.

Unveränderliche Programme: wenn sich der Code nie mehr ändert

Ein unveränderliches (immutable) Programm ist eines, dessen Upgrade Authority entfernt wurde. Niemand, auch nicht der ursprüngliche Entwickler, kann seinen Code je wieder ändern.

Unveränderlichkeit ist eine starke Garantie, hat aber zwei Seiten. Ein Bug in einem unveränderlichen Programm lässt sich nicht patchen; das Team muss ein neues Programm deployen und die Nutzer zur Migration bewegen. Genau deshalb behalten viele Teams eine Upgrade Authority hinter einem Multisig, statt sie zu verbrennen. Zeigt der Explorer „Upgradeable: No“ oder eine leere Authority, weißt du: Der Bytecode, den du heute liest, ist der Bytecode, mit dem du morgen interagierst. Ein verifizierter Build hat bei einem unveränderlichen Programm deshalb besonders viel Aussagekraft.

Verifizierte Builds: solana-verify und die OtterSec-API

Ein verifizierter Build belegt, dass der on-chain deployte Bytecode aus einem bestimmten öffentlichen Repository und Commit kompiliert wurde. Das ist das Solana-Gegenstück zu „Verified Source Code“ auf Ethereum-Explorern wie Etherscan.

Der Ablauf ist im offiziellen Leitfaden zu Verified Builds beschrieben und nutzt die Open-Source-solana-verify CLI von OtterSec:

1. solana-verify build kompiliert das Programm deterministisch in einem Docker-Image, sodass jeder denselben Hash erhält.
2. solana-verify verify-from-repo baut das Programm aus dem Repository neu und vergleicht das Ergebnis mit dem Hash des On-Chain-Programms.
3. Der Entwickler lädt die Verifizierungsdaten in eine On-Chain-PDA hoch, signiert von der Upgrade Authority, und lässt sie mit solana-verify remote submit-job von der OtterSec-API unter verify.osec.io öffentlich bestätigen.

Solana Explorer liest die OtterSec-API aus und zeigt einen Verified-Build-Tab mit Repository-Link und Commit. Auch Orb markiert verifizierte Programme, und Solscan dokumentiert „Anchor-verified“-Programme. Als wir das Pump.fun-Programm am 23. September 2026 gegen den Status-Endpunkt von OtterSec geprüft haben, kam is_verified: false zurück. Das heißt nicht, dass das Programm bösartig ist. Es heißt nur, dass du allein über den Explorer nicht bestätigen kannst, ob der deployte Code zu einer öffentlichen Quelle passt.

Die Solana-Dokumentation ist hier eindeutig: Ein verifizierter Build sollte nicht als sicherer gelten als ein unverifizierter. Er beseitigt eine Unsicherheit, nämlich die Lücke zwischen Quellcode und Bytecode, und lässt Audits und die Kontrolle über die Authority als eigene Fragen offen.

Der IDL-Tab bei Anchor-Programmen

Der IDL-Tab zeigt die Schnittstelle eines Programms: seine Instruktionen, deren Argumente, die Accounts, die jede Instruktion erwartet, und die eigenen Datentypen. Bei Anchor-Programmen können Explorer eine on-chain veröffentlichte IDL auslesen und damit Transaktionen dekodieren.

Anchor ist das verbreitetste Framework für Solana-Programme und kann die IDL eines Programms in einen Account schreiben, der von der Programmadresse abgeleitet ist. Solana Explorer erkennt das, zeigt einen IDL-Tab und dekodiert Anchor-Accounts und -Instruktionen in benannte Felder. Auch Orb zeigt die IDLs verifizierter Programme an. Ohne IDL erscheint eine Instruktion als Hex- oder Base58-Blob, und du darfst raten, was 0x66063d12... bedeuten soll.

In der Praxis macht die IDL aus „Unknown Instruction“ etwas wie buy { amount, max_sol_cost } mit beschrifteten Accounts. Das ist Gold wert, wenn du prüfen willst, was eine Wallet-Abfrage gleich ausführt. Denk aber daran, dass die IDL vom Entwickler hochgeladen wird. Sie beschreibt die beabsichtigte Schnittstelle, ist aber kein Sicherheitsbeweis, und ein böswilliger Entwickler könnte eine irreführende IDL veröffentlichen. Manche Teams, darunter Pump.fun, dokumentieren ihre Instruktionen und Account-Layouts zusätzlich in einem öffentlichen GitHub-Repository, etwa in den öffentlichen Pump.fun-Docs.

Ein praktischer Tipp für deutschsprachige Nutzer: Die Instruktionsnamen in der IDL sind fast immer englisch (buy, sell, withdraw, set_authority). Präg dir die kritischen Begriffe ein, vor allem alles mit authority, close oder transfer, denn genau diese Namen tauchen auch in der Transaktionsvorschau deiner Wallet auf.

Programm-Logs in einer Transaktion lesen

Programm-Logs sind die Meldungen, die ein Programm während der Ausführung schreibt. Sie sind der schnellste Weg, um zu verstehen, warum eine Transaktion fehlgeschlagen ist. Jeder Explorer zeigt sie in der Transaktionsansicht.

Die Logs folgen einem festen Muster. Du siehst Program 6EF8... invoke [1], wenn ein Programm startet, Program log:-Zeilen mit Meldungen aus dem Code, eine Zeile mit den verbrauchten Compute Units und am Ende success oder failed samt Fehler. Verschachtelte Aufrufe anderer Programme erscheinen als invoke [2], invoke [3] und zeigen dir so den Aufrufbaum. Ein Anchor-Fehler nennt sich meist selbst beim Namen, zum Beispiel eine fehlgeschlagene Constraint, und das hilft deutlich mehr als eine nackte Fehlernummer.

Scheitert eine Transaktion, lies zuerst die letzten Logzeilen. Meist verweisen sie auf ein Slippage-Limit, einen nicht initialisierten Account oder ein aufgebrauchtes Compute-Budget; das Maximum liegt bei 1.400.000 Compute Units pro Transaktion. Unser Ratgeber Solana Transaktion prüfen erklärt den Rest der Transaktionsseite, und der Devnet-Explorer-Ratgeber zeigt, wie du dieselben Programmaufrufe vorher gefahrlos auf einem Test-Cluster ausprobierst.

Ein Programm im Explorer prüfen: Pump.fun als Praxisbeispiel

Hier die komplette Routine an einem echten Programm. Sie dauert ein paar Minuten und funktioniert in jedem Solana Smart Contract Explorer.

Öffne 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P auf Solana Explorer, Solscan oder Orb. Die Übersicht bestätigt, dass das Programm ausführbar ist und dem BPF Upgradeable Loader gehört. Folge dem Link zum Program-Data-Account und notiere die Upgrade Authority: Zum Zeitpunkt des Schreibens ist sie auf 7gZu…jFr8 gesetzt, der Code kann sich also ändern. Öffne auch diese Adresse; gehört sie zu einem Multisig-Programm, sind für ein Upgrade mehrere Unterschriften nötig. Sieh dir den Verifizierungs-Tab an: bei unserem letzten Check nicht verifiziert. Such nach einem IDL-Tab und nutze ihn, oder das öffentliche Docs-Repository, um die Instruktionsnamen zu verstehen. Zum Schluss öffnest du eine aktuelle Transaktion, die das Programm aufgerufen hat, und liest die Logs, um einen normalen buy- oder sell-Ablauf zu sehen.

Vergleich das mit einem Programm, dessen Authority ein bekanntes Multisig ist und dessen Build verifiziert ist, und du bekommst ein klares Bild davon, wie viel Vertrauen jedes der beiden von dir verlangt. Für Daten in größerem Umfang, etwa alle Signaturen einer Programmadresse, lies unseren Überblick zu den API-Optionen für Solana-Explorer.

Sicherheits-Check, bevor du mit einem Programm interagierst

Bevor du eine Transaktion freigibst, die ein unbekanntes Programm aufruft, prüfe fünf Dinge: die exakte Adresse, die Upgrade Authority, den Verifizierungsstatus, IDL oder Doku und die jüngste Aktivität.

• Exakte Adresse. Hol dir die Program ID aus der offiziellen Doku oder von GitHub, nicht aus einer DM oder von einer zufälligen Website, und vergleiche sie Zeichen für Zeichen.
• Upgrade Authority. Einzelner Schlüssel, Multisig oder keine. Finde das heraus, bevor du größere Beträge einzahlst.
• Verifizierter Build. Schön zu haben; bestätigt, dass das Repo, das du liest, auch der Code ist, der läuft.
• IDL und Instruktionen. Stell sicher, dass die Instruktion in deiner Wallet zu dem passt, was du vorhast. Ein „Claim Airdrop“, der einen Transfer an einen unbekannten Account auslöst, ist ein Drainer.
• Sicherheitskontakt. Solana Explorer zeigt security.txt-Daten an, wenn ein Programm sie einbettet. Daraus erfährst du, wo du Schwachstellen melden kannst.

Gerade bei Airdrop-Kampagnen, die über Telegram-Gruppen oder X-Accounts in deutscher Sprache beworben werden, lohnt sich dieser Check doppelt: Betrüger übersetzen ihre Landingpages inzwischen sauber, die Programmadresse dahinter bleibt aber das, was zählt.

Die Explorer zeigen diese Felder unterschiedlich klar an. Unser Ranking der besten Solana-Explorer bewertet sie unter anderem nach Entwickler-Tools, und der Orb-Test geht auf die lesbare IDL- und Programmansicht ein.