Een Solana program explorer is de plek waar je een smart contract controleert voordat je iets ondertekent dat ermee te maken heeft. De programmapagina laat zien of de code uitvoerbaar is, welke loader de eigenaar is, of een upgrade authority de code nog kan vervangen, of er een verified build van de broncode bestaat en, bij Anchor-programma’s, een IDL die elke instructie decodeert. In deze gids lopen we elk veld langs aan de hand van een echt voorbeeld, het pump.fun-programma, en we sluiten af met een korte veiligheidschecklist die je in twee minuten afwerkt op Solana Explorer, Solscan of Orb.
Wat is een program account op Solana?
Een program account is een on-chain account dat als uitvoerbaar (executable) is gemarkeerd en gecompileerde code bevat of ernaar verwijst. Op Solana heet een smart contract simpelweg een “program”.
Programma’s op Solana zijn stateless. Ze houden zelf geen saldi of gebruikersgegevens bij; die data staat in aparte accounts waarvan het programma de eigenaar is. Roep je een programma aan, dan geeft je transactie de benodigde accounts mee en leest en schrijft het programma daarin. Daarom ziet een programmapagina er anders uit dan een walletpagina: het interessante is niet een saldo, maar wie de code kan wijzigen en wat die code doet.
De meeste programma’s worden tegenwoordig uitgerold met de BPF Upgradeable Loader (BPFLoaderUpgradeab1e11111111111111111111111). Bij deze loader is het program account zelf klein. Voor het pump.fun-programma 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P geeft een ruwe getAccountInfo-aanroep slechts 36 bytes data terug, executable: true, de upgradeable loader als owner en één geparsed veld: programData. De eigenlijke code staat ergens anders. Zijn accounts in het algemeen nieuw voor je, dan is de officiële documentatie over accounts de helderste introductie.
Program data account en upgrade authority uitgelegd
Het program data account bevat de echte bytecode plus twee stukjes metadata: de slot van de laatste deployment en de upgrade authority. Die upgrade authority is het belangrijkste veld op elke pagina van een smart contract explorer.
In het pump.fun-voorbeeld verwijst het veld programData naar B5MvUwXdiW1NMM6QFFD3ssPKBujD4zMohncbM73Z2BQu. Toen we dat account op 23 september 2026 opvroegen, stond er als upgrade authority 7gZufwwAo17y5kg8FMyJy2phgpvv9RSdzWtdXiWHjFr8. In gewone taal: wie die sleutel beheert, kan nieuwe pump.fun-code uitrollen. Voor een protocol dat actief wordt ontwikkeld is dat normaal, maar het betekent wel dat je het team vertrouwt en niet alleen de code.
Explorers presenteren dit elk op hun eigen manier. Solana Explorer toont het program data-adres, de upgrade authority en de laatst uitgerolde slot op het overzicht van het programma. Solscan en Orb laten dezelfde gegevens zien, met labels waar ze die kennen. Je kunt de controle met elke RPC-client nadoen, of plak het programma-adres in onze zoektool om het ruwe account te bekijken.
Waar je op let:
- Eén enkele wallet als authority. Eén gelekte sleutel kan het programma vervangen. Hoger risico.
- Een multisig of governance-account. Wijzigingen vragen meerdere ondertekenaars of een stemming. Lager risico, en gebruikelijk bij grote protocollen.
- Helemaal geen authority. Het programma is immutable. Zie de volgende sectie.
Let op: In de kop van de meeste explorers wordt een programma-adres ingekort, bijvoorbeeld 6EF8…wF6P. Oplichters rollen soms programma's uit op vanity-adressen met dezelfde eerste en laatste tekens. Vergelijk het volledige adres van 32 tot 44 tekens voordat je een match vertrouwt.
Immutable programma’s: code die nooit meer verandert
Een immutable programma is een programma waarvan de upgrade authority is verwijderd. Niemand, ook de oorspronkelijke ontwikkelaar niet, kan de code nog aanpassen.
Onveranderlijkheid is een sterke garantie, maar het snijdt aan twee kanten. Een bug in een immutable programma kan niet worden gepatcht; het team moet een nieuw programma uitrollen en gebruikers vragen over te stappen. Daarom houden veel teams de upgrade authority liever achter een multisig in plaats van hem te ‘verbranden’. Toont een explorer “Upgradeable: No” of een lege authority, dan weet je dat de bytecode die je vandaag leest ook de bytecode is waarmee je morgen werkt. Juist daardoor zegt een verified build van een immutable programma extra veel.
Verified builds: solana-verify en de OtterSec API
Een verified build bewijst dat de bytecode on-chain is gecompileerd uit een specifieke openbare repository en commit. Het is de Solana-tegenhanger van “verified source code” op Ethereum-explorers.
Het proces, beschreven in de officiële gids over verified builds, gebruikt de opensource solana-verify CLI van OtterSec:
solana-verify buildcompileert het programma deterministisch in een Docker-image, zodat iedereen dezelfde hash krijgt.solana-verify verify-from-repobouwt opnieuw vanuit de repository en vergelijkt het resultaat met de hash van het programma on-chain.- De ontwikkelaar uploadt de verificatiegegevens naar een on-chain PDA, ondertekend door de upgrade authority, en draait daarna
solana-verify remote submit-jobzodat de OtterSec API op verify.osec.io het publiekelijk bevestigt.
Solana Explorer leest de OtterSec API uit en toont een verified-build-tab met de link naar de repository en de commit. Orb markeert geverifieerde programma’s ook, en Solscan documenteert “Anchor-verified” programma’s. Toen we het pump.fun-programma op 23 september 2026 tegen het statusendpoint van OtterSec controleerden, kwam er is_verified: false terug. Dat betekent niet dat het programma kwaadaardig is; het betekent dat je vanuit de explorer alleen niet kunt vaststellen dat de uitgerolde code overeenkomt met een openbare bron.
De documentatie van Solana is daar heel duidelijk over: een verified build moet je niet als veiliger beschouwen dan een niet-geverifieerde. Het haalt één onzekerheid weg, het gat tussen broncode en bytecode, en laat audits en het beheer van de authority als losse vragen over.
De IDL-tab bij Anchor-programma’s
De IDL-tab toont de interface van een programma: de instructies, hun argumenten, de accounts die elke instructie verwacht en de eigen datatypen. Bij Anchor-programma’s kunnen explorers een on-chain gepubliceerde IDL uitlezen en daarmee transacties decoderen.
Anchor is het meest gebruikte framework voor Solana-programma’s en kan de IDL publiceren in een on-chain account dat is afgeleid van het programma-adres. Solana Explorer herkent dat, toont een IDL-tab en decodeert Anchor-accounts en -instructies in velden met namen. Orb laat de IDL’s van geverifieerde programma’s ook zien. Zonder IDL verschijnt een instructie als hex- of base58-blob en moet je raden wat 0x66063d12... betekent.
In de praktijk maakt de IDL van “onbekende instructie” iets als buy { amount, max_sol_cost } met gelabelde accounts. Dat is goud waard als je wilt nagaan wat een wallet-pop-up op het punt staat te doen. Bedenk wel dat de ontwikkelaar de IDL zelf uploadt. Die beschrijft de bedoelde interface, maar is geen veiligheidsbewijs, en een kwaadwillende ontwikkelaar kan een misleidende versie publiceren. Sommige teams, waaronder pump.fun, documenteren hun instructies en account-layouts daarnaast in een openbare GitHub-repository, zoals de openbare pump.fun-documentatie.
Programmalogs lezen in een transactie
Programmalogs zijn de berichten die een programma schrijft terwijl het draait, en ze zijn de snelste manier om te begrijpen waarom een transactie is mislukt. Elke explorer toont ze in de transactieweergave.
Logs volgen een vast patroon. Je ziet Program 6EF8... invoke [1] wanneer een programma start, regels met Program log: die berichten uit de code bevatten, een regel met het aantal verbruikte compute units en ten slotte success of failed met een foutmelding. Geneste aanroepen naar andere programma’s verschijnen als invoke [2], invoke [3], en zo zie je de hele call tree. Een Anchor-fout noemt meestal zichzelf, bijvoorbeeld een eigen constraint die niet klopte, en dat is veel nuttiger dan een kaal foutnummer.
Mislukt een transactie, lees dan eerst de laatste paar logregels. Die wijzen meestal naar een slippagelimiet, een account dat niet was geïnitialiseerd of een compute budget dat op was; het maximum is 1.400.000 compute units per transactie. Onze gids voor de Solana transaction explorer legt de rest van de transactiepagina uit, en de gids voor de devnet-explorer laat zien hoe je dezelfde programma-aanroepen eerst veilig op een testcluster probeert.
Een programma verkennen: pump.fun als uitgewerkt voorbeeld
Hier is de volledige routine op één echt programma. Het kost een paar minuten en werkt in elke Solana contract explorer.
Open 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P in Solana Explorer, Solscan of Orb. Het overzicht bevestigt dat het programma uitvoerbaar is en in eigendom is van de BPF Upgradeable Loader. Volg de link naar het program data account en noteer de upgrade authority: op het moment van schrijven staat die op 7gZu…jFr8, dus de code kan veranderen. Open ook dat adres; hoort het bij een multisig-programma, dan zijn er meerdere ondertekenaars nodig voor een upgrade. Bekijk de verificatietab: bij onze laatste controle niet geverifieerd. Zoek een IDL-tab en gebruik die, of de openbare docs-repository, om de namen van de instructies te begrijpen. Open ten slotte een recente transactie die het programma aanriep en lees de logs om een normale buy- of sell-flow te zien.
Zet dat naast een programma waarvan de authority een bekende multisig is en de build geverifieerd, en je ziet precies hoeveel vertrouwen elk van beide van je vraagt. Wil je data op grote schaal, zoals alle signatures voor een programma-adres ophalen, lees dan onze gids over de API-opties van Solana explorers.
Veiligheidschecks voordat je met een programma werkt
Voordat je een transactie goedkeurt die een onbekend programma aanroept, check je vijf dingen: het exacte adres, de upgrade authority, de verificatiestatus, de IDL of documentatie, en recente activiteit.
- Exact adres. Haal de program ID uit officiële documentatie of van GitHub, niet uit een DM of een willekeurige site, en vergelijk hem teken voor teken.
- Upgrade authority. Eén sleutel, een multisig of geen. Zoek uit welke van de drie het is voordat je iets groots stort.
- Verified build. Mooi meegenomen; het bevestigt dat de repo die je leest ook de code is die draait.
- IDL en instructies. Controleer of de instructie die je wallet toont overeenkomt met wat je wilt doen. Een “claim airdrop” die een transfer naar een onbekend account uitvoert, is een drainer.
- Beveiligingscontact. Solana Explorer toont security.txt-gegevens als een programma die heeft ingebouwd, zodat je weet waar je problemen kunt melden.
Kijk ook naar de recente activiteit. Een programma dat dagelijks duizenden transacties verwerkt en al maanden live staat, heeft een ander risicoprofiel dan een contract dat gisteren is uitgerold en waar alleen een handvol wallets mee werken. Een nieuwe deployment-slot vlak voor een grote airdrop of mint is een reden om extra goed te kijken.
Welke Solana explorer is het beste voor programma’s?
Voor programmacontroles is er geen enkele winnaar; elke explorer heeft een sterk punt. Solana Explorer van de Solana Foundation is het meest volledig op de technische velden: verified-build-tab, IDL, security.txt en de ruwe account-gegevens. Orb van Helius legt instructies in begrijpelijke taal uit en is prettig als je snel wilt zien wat een onbekende transactie deed. Solscan, sinds januari 2024 eigendom van Etherscan, combineert labels en Anchor-verificatie met uitgebreide token- en transferdata.
Nederlandstalige interfaces zijn er bij deze explorers vrijwel niet, maar de programmavelden zijn overal in het Engels en tamelijk gestandaardiseerd: wie “upgrade authority”, “executable” en “program data” eenmaal kent, vindt ze overal terug. De verschillende explorers tonen deze velden elk met hun eigen helderheid. Onze ranglijst van de beste Solana explorers scoort ze op developer tools, en de review van Orb gaat dieper in op de leesbare IDL- en programmaweergave.
Door de researchdesk van SolscannerBijgewerkt · Reviewmethodiek