Program Interaction Analysis: Using Solscan to Reverse-Engineer Unknown Smart Contracts

A developer encounters a transaction on the Solana blockchain that appears to invoke an unfamiliar program, moving tokens through a wallet in ways that are not immediately obvious from the address alone. The transaction succeeded, fees were paid, and the account balances changed, but the actual program logic remains hidden—no source code is published, no documentation is readily available, and the contract address itself provides no human-readable explanation of what functions were called or why. This is a common situation in decentralized applications where third-party integrations, wrapped tokens, automated market makers, or proprietary protocols operate without transparent source code. Understanding what happened requires analysis rather than assumption.

Solscan, the official blockchain explorer for the Solana network, provides the tools needed to decode these interactions and reconstruct the contract’s behavior from on-chain evidence. By examining transaction details, instruction logs, account state changes, and program-derived addresses, an analyst can reverse-engineer the intent and structure of unknown smart contracts without requiring access to the original source code. The method is not a complete decompilation, but it is comprehensive enough to answer the practical questions: what program was called, what accounts were modified, what data was passed, and what outcomes resulted.

Locating and identifying the program address

Every transaction on Solana identifies the programs it invokes through a program ID, which is a public key that points to executable code stored as an account on the blockchain. When you search for a transaction in Solscan, the “Instruction” section lists each program called and the order in which it was executed. A single transaction may invoke multiple programs in sequence—for example, a decentralized exchange swap might call the token program, then a routing contract, then the exchange’s own program. The first step is to isolate the program address whose behavior you want to understand.

The program address is displayed as a long base58-encoded string. Clicking on the program ID takes you to its dedicated page within Solscan, where you can see metadata about the program itself. Some programs display a name and description if they are verified contracts; others show only the address. If the program is part of a widely-used system—such as the Token Program, Metadata Program, or a major DEX—Solscan will label it accordingly. Unknown programs appear without annotation, which is where reverse engineering begins.

A program’s page on Solscan shows total transactions, recent activity, and the program’s owner account (which usually indicates who deployed it). For verified programs, the page may include a link to source code on GitHub or another repository. If source code is available, you can save significant effort by reading the code directly. However, many production contracts are either not verified, or verification is incomplete. The developer tools available through the solana blockchain explorer allow you to reconstruct behavior from transaction data alone.

Reading instruction logs and account state changes

An instruction log shows exactly which program was invoked and which other accounts were referenced as inputs to that instruction. Solana’s instruction model is explicit: a program receives a list of accounts, some marked as writable and others as read-only. If an account is writable, the program is authorized to modify it. By observing which accounts changed and which remained static, you can infer what the program did. For example, if a writable token account’s balance decreased by 1,000 tokens and a different writable token account’s balance increased by 900 tokens, you can reasonably infer that a transfer occurred, with 100 tokens consumed as a fee or lost to rounding.

The Account State Change tab in a transaction provides a before-and-after snapshot of relevant accounts. This is more precise than trying to guess from the address alone. A token mint account, for instance, has fields for total supply, decimals, and the authority that can mint or freeze tokens. If the supply field changed between the start and end of a transaction, the program minted or burned tokens. If the freeze authority was changed, the program altered permissions. These state changes are objective evidence of what the program executed.

Program logs, sometimes called “program output” or “program messages,” are console-style text strings that smart contracts can emit during execution. A well-designed contract emits logs describing important events, such as “Transfer: from=Alice, to=Bob, amount=1000.” Unknown contracts may emit minimal or cryptic logs, but any text output can serve as a clue. Developers sometimes log function names, error conditions, or intermediate calculations. By collecting these messages across multiple transactions involving the same program, patterns emerge.

Decoding instruction data and function selectors

Beyond account references, each instruction to a program includes instruction data, which is a byte sequence encoding the function name and its parameters. Solana programs often use a convention called discriminators or function selectors to identify which function to call. For Anchor-based programs—a common framework—the first eight bytes of the instruction data form a discriminator derived from the function name. By collecting multiple transactions that call the same program and examining their instruction data prefixes, you can map discriminators to functions.

Solscan’s transaction detail page displays instruction data in hexadecimal format. If you see transactions with data starting with “0x6ddf6db1fb67f41e,” you can infer they are calling the same function. By comparing these transactions to their account state changes and logs, you can reverse-engineer what that function does. Does it always reduce a balance in one account and increase it in another? It is likely a transfer or swap. Does it modify a counter field and emit an incrementing sequence number? It is probably tracking state or minting events.

The remainder of the instruction data, after the discriminator, encodes the function’s parameters. These may include amounts, addresses, or boolean flags. Without the contract’s schema, decoding parameter data requires educated guessing based on the account state changes and the context of typical DeFi operations. If a program receives instruction data with a large number (like 0x00000000000f4240, which is 1,000,000 in decimal) and a token balance increases by exactly that amount, the parameter was probably an amount. If an instruction data field matches the public key of an account being used, it is probably a reference parameter.

Following program-derived address patterns

Program-derived addresses, or PDAs, are accounts that a program generates deterministically using the program’s public key and a seed value. A PDA is not controlled by a private key; instead, the program that derives it has the authority to sign transactions on its behalf. When you examine a transaction and see an account you do not recognize, Solscan’s details may indicate whether it is a PDA and which program controls it. This is useful because PDAs often serve as state storage for the contract—a vault holding tokens, a registry of users, or a configuration file.

If a program consistently writes to a specific PDA and the account’s data changes in predictable ways, you can infer its purpose. For example, many protocols create one PDA per user to store the user’s balances or deposit history. By finding multiple transactions to the same program with different PDAs and comparing the patterns, you can map out the program’s storage layout. A PDA that increases in size over time and contains many entries probably stores a list or map of records. A PDA that is fixed in size and has individual fields probably stores configuration or global state.

The Seeds field in Solscan sometimes displays the seeds used to derive a PDA, if they are standard formats like UTF-8 strings or known identifiers. A PDA derived from seeds [“vault”, “SOL”] is almost certainly an account called “vault” for Solana’s native token. If you see a program creating PDAs with seeds like [“user”, user_public_key, “stake”], you can reasonably infer that the program tracks per-user stake amounts. This pattern recognition, applied across multiple transactions, builds a mental map of the program’s architecture.

Cross-referencing accounts and signatures across transactions

A single transaction involving an unknown program is insufficient for confident analysis. By examining multiple transactions that invoke the same program, you can cross-reference accounts, instruction data patterns, and outcomes. A good strategy is to identify 5 to 10 transactions to the same program, spanning different times and users if possible, and then compare them side-by-side. Solscan’s account page shows all transactions involving that account, which makes it straightforward to gather a sample.

Pay special attention to the transaction signers, shown in the “Signers” section. A program never signs its own transactions; a user or bot does. If you notice that the same signer appears in multiple transactions to the same program, you may be observing a user’s repeated interactions. If different signers use the same program, the program is genuinely multi-user. Some programs require a specific authority or admin account to call certain functions. If one account appears as a signer only in transactions that modify critical state, it is probably the admin.

By plotting account participation across transactions, you can identify clusters. A cluster is a set of accounts that repeatedly appear together, suggesting they are part of the same logical operation or entity. For example, if accounts A, B, and C always appear together in transactions to a program, and account D and E never appear with them, the program probably uses (A, B, C) for one type of operation and (D, E, others) for another. This clustering helps you understand the program’s operational modes.

Inferring contract functionality from token and NFT movements

If the program interacts with tokens or NFTs, token-level analysis on Solscan becomes decisive. The Token Overview page for any SPL token shows its total supply, holders, and recent transfers. If you see a program repeatedly receiving transfers of token X and distributing a different token Y in return, it is almost certainly an exchange or conversion contract. The ratio of input to output amounts reveals whether the program takes a fee and how much.

NFT-related programs can be analyzed similarly. Solscan’s NFT analytics show collection metadata, trading history, and sales trends. If an unknown program is invoked every time an NFT changes hands, it is likely a marketplace, royalty enforcer, or collection-specific contract. The account changes will show which wallet received the sale proceeds and which received the NFT, while the instruction data may encode sale price or terms.

For programs that mint new tokens, compare the total supply before and after the transaction. If supply increased, the program exercised the mint authority. By observing which accounts received the newly-minted tokens, you can determine whether the program is implementing a yield farm, a community distribution, a collateral mechanism, or something else. Repeated minting patterns reveal whether the program mints continuously, on-demand, or under specific conditions.

Smart contract verification as a validation tool

If you suspect you have correctly reverse-engineered a contract’s behavior, smart contract verification becomes a way to validate your hypothesis. Some programs are verified on Solscan, meaning their source code has been uploaded and compiled on-chain, with the result matching the bytecode of the deployed program. If you find a verified version of the contract you are analyzing, you can compare your reverse-engineered conclusions against the actual source code.

Even if the specific program you are studying is not verified, similar programs often are. Major DEXs, lending platforms, and token bridges publish their source code. By studying verified contracts in the same category, you develop pattern recognition for common structures. You learn that Anchor programs follow a predictable instruction layout, that token exchanges typically involve three to five account modifications, and that governance contracts emit specific event logs.

Solscan’s developer tools, including API access, allow you to query transaction history programmatically and perform bulk analysis. Writing a script to scan all transactions to a program over a month and extract patterns is feasible and often more efficient than manually reviewing individual transactions. This statistical approach can reveal functions that are rarely called or hidden business logic that appears only under specific market conditions.

Practical workflow for real-world reverse engineering

Start by identifying a transaction of interest. Copy the program ID and search it on Solscan. Review its page for any metadata, source code links, or related programs. If source code is available, read it. If not, proceed to the transaction view. Look at the account state changes and instruction data. Make a hypothesis about what the program did. Then, find 5 to 10 other transactions to the same program and check whether your hypothesis holds. If the instruction data discriminators match and the account state changes follow the same pattern, your hypothesis is likely correct.

Next, examine the instruction data more carefully. Identify which bytes encode parameters versus which are padding. Cross-reference the parameters with account state changes. If a parameter value matches a token amount, or if it corresponds to an account index, note that. Build a table mapping discriminators to function names, account lists to purposes, and outcome patterns to business logic. Solscan’s real-time data and full transparency across the Solana blockchain ecosystem make this detective work practical, even without access to source code or the developer’s documentation.

Finally, test your conclusions by predicting the outcome of future transactions to the same program. If you correctly identified the function and parameters, you should be able to forecast which accounts will change and by how much. When your predictions match actual outcomes, your reverse engineering is sound. Share your findings in community forums or GitHub to help other developers. Over time, collaborative reverse engineering builds institutional knowledge about programs that operate without published documentation.