Solana Devnet Program Analysis Challenge
Reverse-engineer a Solana devnet program by tracing transactions, decoding accounts, and documenting instructions to build practical on-chain analysis skills.
This challenge will help you sharpen your skills by reverse-engineering existing Solana programs deployed on devnet.
Your goal is to pick a deployed devnet program, analyze its accounts and transactions, and create a report explaining how it works. This includes the instructions it uses, what kind of accounts it manages, and any observed patterns.
This is an open-ended investigation challenge. There is no single "correct" program to pick. The value lies in your process and what you uncover.
What You'll Do
In this challenge, you will:
- Pick a non-trivial devnet program from public transaction history.
- Identify its Program ID and map out its primary instructions by observing interactions.
- Analyze the data structures of the accounts it creates and modifies.
- Interpret the program's purpose and document your findings in a clear report.
Where to Look
Here are a few tools to help you discover interesting programs. Your first step is always to find a Program ID to investigate.
Project Steps
Step 1: Choose a Devnet Program
Find a real program deployed to devnet. For this example, let's pretend we found a program with the ID Vote... that appears to be a simple on-chain voting application. We'll use this hypothetical program for the next steps.
Step 2: Investigate Transactions
On Solscan, look up the program ID Vote... and view its transaction history. You might find two common patterns:
- Initialization Transaction: One instruction that involves the System Program and creates a new account. This is likely the
initialize_pollinstruction. - Voting Transaction: Another instruction that involves an existing "poll" account and a user's wallet. This is likely the
voteinstruction.
By clicking into a "voting" transaction, you might see it takes three accounts: the user's wallet (as a signer), the poll account (writable), and the system clock. This is your first major clue about the program's mechanics.
Step 3: Analyze Account Structures
Pick a "poll" account created by the program and view its details. The data will be shown in a format like Base64. Use an online tool or the solana account <ADDRESS> CLI command to view it.
Let's say the account data (after decoding) is a 16-byte buffer:
[216, 128, 13, 85, 22, 16, 203, 73, 5, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0]
- The first 8 bytes (
[216, 128, ...]) might be the Anchor discriminator for a "Poll" account. - The next 8 bytes (
[5, 0, ...]) in little-endian format represent the number5. This could bevotes_for. - The final 8 bytes (
[3, 0, ...]) represent the number3. This could bevotes_against.
From this, you can infer the account structure stores two counters for votes.
Step 4: Create a Short Report
Based on your investigation, your report for the Vote... program might look like this:
- Program ID:
Vote... - Description: "This program appears to be a simple on-chain polling system. Users can create a poll, and other users can then cast 'for' or 'against' votes, which are tallied in the poll's account."
- Sample Instruction (
vote):Accounts:[Signer]User Wallet[Writable]Poll Account[]System Clock Sysvar
Instruction Data: A single byte,0for an 'against' vote and1for a 'for' vote.
- Account Structure (
Poll):- Bytes 0-7: Anchor Discriminator
- Bytes 8-15:
votes_for(u64) - Bytes 16-23:
votes_against(u64)
- Unknowns: "It's unclear if a user can vote more than once on the same poll. Further investigation is needed."
You can verify an Anchor discriminator. If you suspect an account is named "Poll", you can calculate sha256("account:Poll"). The first 8 bytes of that hash should match the first 8 bytes of the on-chain account data.
Common Pitfalls
Picking token or system programs These are well-documented and not useful for reverse engineering practice. Pick something unfamiliar where you have to deduce the logic yourself.
Assuming too much If something is unclear, write it down as a guess or a question. For example: "This 32-byte field could be a public key, but it could also be a data hash." The goal is analysis, not perfection.
Skipping raw instruction data
Be sure to inspect the base64 instruction data. It often contains a leading byte that indicates which instruction variant is being called (e.g., 0 for initialize, 1 for vote), followed by any arguments. This is a critical clue.
Summary
This challenge helps you think like a blockchain detective. You now know how to:
- Explore and investigate deployed programs on devnet using block explorers.
- Form hypotheses about a program's function by observing its transactions.
- Attempt to decode on-chain account and instruction data to uncover its structure.
- Document your findings with clarity, curiosity, and an awareness of what you don't know.
This skill will help in bug bounty work, dApp frontend integration, or just understanding what’s happening on-chain.