A Solana program explorer is where you check a smart contract before you sign anything that touches it. The program page shows whether the code is executable, which loader owns it, whether an upgrade authority can still replace it, whether the source has a verified build, and, for Anchor programs, an IDL that decodes every instruction. This guide walks through each field using a real example, the pump.fun program, and ends with a short security checklist you can run in two minutes on Solana Explorer, Solscan or Orb.
What is a program account on Solana?
A program account is an on-chain account marked as executable that holds, or points to, compiled code. On Solana, “program” is the word for what other chains call a smart contract.
Programs on Solana are stateless. They do not keep balances or user data inside themselves; that data lives in separate accounts the program owns. When you call a program, your transaction passes in the accounts it needs, and the program reads and writes them. This is why a program explorer page looks different from a wallet page: the interesting part is not a balance, it is who can change the code and what the code does.
Most programs today are deployed with the BPF Upgradeable Loader (BPFLoaderUpgradeab1e11111111111111111111111). With this loader, the program account itself is small. For the pump.fun program 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P, a raw getAccountInfo call returns just 36 bytes of data, executable: true, owner set to the upgradeable loader, and one parsed field: programData. The code sits elsewhere. If accounts in general are new to you, the official accounts documentation is the clearest primer.
Program data account and upgrade authority explained
The program data account stores the actual bytecode plus two pieces of metadata: the slot of the last deployment and the upgrade authority. The upgrade authority is the single most important field on any smart contract explorer page.
Following the pump.fun example, the programData field points to B5MvUwXdiW1NMM6QFFD3ssPKBujD4zMohncbM73Z2BQu. When we queried that account on 23 September 2026, it listed an upgrade authority of 7gZufwwAo17y5kg8FMyJy2phgpvv9RSdzWtdXiWHjFr8. In plain terms: whoever controls that key can deploy new pump.fun code. That is normal for an actively developed protocol, but it means you are trusting the team, not only the code.
Explorers present this differently. Solana Explorer shows the program data address, the upgrade authority and the last deployed slot on the program’s overview. Solscan and Orb show the same facts with labels where they know them. You can reproduce the check with any RPC client, or paste the program address into our lookup tool to see the raw account.
What to look for:
- A single wallet as authority. One compromised key could replace the program. Higher risk.
- A multisig or governance account. Changes need several signers or a vote. Lower risk, and common for large protocols.
- No authority at all. The program is immutable. See the next section.
Note: Program addresses are shortened in most explorer headers, such as 6EF8…wF6P. Scam programs are sometimes deployed at vanity addresses that share the first and last characters. Compare the full 32–44 character address before trusting a match.
Immutable programs: when code can never change
An immutable program is one whose upgrade authority has been removed. Nobody, including the original developer, can change its code again.
Immutability is a strong guarantee, but it cuts both ways. A bug in an immutable program cannot be patched; the team has to deploy a new program and ask users to migrate. That is why many teams keep an upgrade authority behind a multisig instead of burning it. When an explorer shows “Upgradeable: No” or an empty authority, you know the bytecode you are reading today is the bytecode you will interact with tomorrow. That makes a verified build of an immutable program especially meaningful.
Verified builds: solana-verify and the OtterSec API
A verified build proves that the bytecode deployed on chain was compiled from a specific public repository and commit. It is the Solana equivalent of “verified source code” on Ethereum explorers.
The process, described in the official verified builds guide, uses the open-source solana-verify CLI from OtterSec:
solana-verify buildcompiles the program deterministically inside a Docker image, so anyone gets the same hash.solana-verify verify-from-reporebuilds from the repository and compares the result with the on-chain program hash.- The developer uploads the verification data to an on-chain PDA signed by the upgrade authority, then runs
solana-verify remote submit-jobto have the OtterSec API at verify.osec.io confirm it publicly.
Solana Explorer reads the OtterSec API and shows a verified-build tab with the repository link and commit. Orb also marks verified programs, and Solscan documents “Anchor-verified” programs. When we checked the pump.fun program against the OtterSec status endpoint on 23 September 2026, it returned is_verified: false. That does not mean the program is malicious; it means you cannot confirm from the explorer alone that the deployed code matches a public source.
Solana’s documentation is explicit on this point: a verified build should not be considered more secure than an unverified one. It removes one uncertainty, the gap between source and bytecode, and leaves audits and authority control as separate questions.
The IDL tab for Anchor programs
The IDL tab shows a program’s interface: its instructions, their arguments, the accounts each one expects and the custom data types it uses. For Anchor programs, explorers can read an IDL published on chain and use it to decode transactions.
Anchor is the most common framework for Solana programs, and it can publish the program’s IDL to an on-chain account derived from the program address. Solana Explorer detects it, shows an IDL tab, and decodes Anchor accounts and instructions into named fields. Orb shows verified program IDLs as well. Without an IDL, an instruction appears as a hex or base58 blob, and you have to guess what 0x66063d12... means.
In practice the IDL turns a transaction from “unknown instruction” into something like buy { amount, max_sol_cost } with labelled accounts. That is invaluable when you are checking what a wallet prompt is about to do. Keep in mind that the IDL is uploaded by the developer. It describes the intended interface, but it is not a security proof, and a malicious developer could publish a misleading one. Some teams, pump.fun included, also document their instructions and account layouts in a public GitHub repository, such as the pump.fun public docs.
Reading program logs in a transaction
Program logs are the messages a program writes while it runs, and they are the fastest way to understand why a transaction failed. Every explorer shows them in the transaction view.
Logs follow a pattern. You will see Program 6EF8... invoke [1] when a program starts, Program log: lines with messages from the code, a line reporting how many compute units were consumed, and finally success or failed with an error. Nested calls to other programs appear as invoke [2], invoke [3], which shows you the call tree. An Anchor error usually names itself, for example a custom constraint that failed, which is far more useful than a raw error number.
When a transaction fails, read the last few log lines first. They usually point to a slippage limit, an account that was not initialised, or a compute budget that ran out; the maximum is 1,400,000 compute units per transaction. Our transaction explorer guide explains the rest of the transaction page, and the devnet explorer guide shows how to test the same program calls safely on a test cluster first.
How to explore a program: pump.fun as a worked example
Here is the whole routine on one real program. It takes a couple of minutes and works on any Solana contract explorer.
Open 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P on Solana Explorer, Solscan or Orb. The overview confirms it is executable and owned by the BPF Upgradeable Loader. Follow the program data link and note the upgrade authority: at the time of writing it is set to 7gZu…jFr8, so the code can change. Open that address too; if it belongs to a multisig program, several signers are needed for an upgrade. Check the verification tab: not verified at our last check. Look for an IDL tab and use it, or the public docs repository, to understand the instruction names. Finally, open a recent transaction that called the program and read the logs to see a normal buy or sell flow.
Compare that with a program where the authority is a known multisig and the build is verified, and you have a clear picture of the relative trust each one asks of you. For data at scale, such as pulling all signatures for a program address, see our guide to the Solana explorer API options.
Security checks before you interact with a program
Before approving a transaction that calls an unfamiliar program, check five things: the exact address, the upgrade authority, the verification status, the IDL or docs, and recent activity.
- Exact address. Get the program ID from official docs or GitHub, not from a DM or a random site, and compare it character by character.
- Upgrade authority. Single key, multisig or none. Find out which before you deposit anything large.
- Verified build. Nice to have; confirms the repo you are reading is the code that runs.
- IDL and instructions. Make sure the instruction your wallet shows matches what you expect to do. A “claim airdrop” that calls a transfer to an unknown account is a drainer.
- Security contact. Solana Explorer displays security.txt data when a program embeds it, which tells you where to report issues.
Different explorers surface these fields with varying clarity. Our ranked list of the best Solana explorers scores them on developer tools, and the Orb review covers its readable IDL and program views.
By the Solscanner research deskUpdated · Review methodology