4 min read

Overview

This guide addresses the ten most common questions that beginners encounter when starting with Solana. It aims to clarify key concepts and terminology, helping new developers navigate the complexities of onchain development.

Unlock the mysteries of Solana! Join Mike in exploring the top 10 beginner questions and gain clarity on onchain development and Rust programming.

Subscribe to our YouTube channel for more videos!Subscribe

Prerequisites

• Basic understanding of blockchain technology
• Familiarity with programming concepts, particularly in Rust and TypeScript

The Common Questions

1. Instructions that process instructions?

Alright, so here’s where the confusion usually begins. In Solana, we talk about instructions all the time. But then the docs say your program also has “instructions.” Wait—what?

Here’s the deal:

• An instruction is the data being sent over the network to your program.
• The instruction handler is the Rust function in your program that processes it.

Think of it like a web server: requests come in, handlers process them. Same concept. In your Anchor program’s lib.rs, inside the #[program] struct, those top-level functions are your instruction handlers.

2. do_thing and DoThing – why both?

You’ll often see a function named do_thing and a struct named DoThing. Same name, different casing. Super confusing, right?

The pattern is:

• do_thing (snake_case) is the function that runs.
• DoThing (PascalCase) is the accounts struct that describes what accounts the function needs.

The fix? Rename the struct to something like DoThingAccounts. That way you instantly know one’s the code logic and the other’s the data structure.

3. Pubkeys that aren’t really public keys

Okay, another naming nightmare. Solana’s Pubkey type sounds like it represents a real cryptographic public key, but it doesn’t.

In reality, Pubkey just means address. That’s it. Some of those addresses belong to real keypairs (with matching private keys), but others like PDAs (Program Derived Addresses) don’t.

PDAs are generated from seeds like "order" and an ID number. They’re deterministic and have no private key. So think of Pubkey as “address”.

4. What happens when something fails in an instruction handler?

This one’s important. If anything fails inside your instruction handler, the whole instruction fails.

Let’s say your handler first moves tokens from a vault to a taker, and then tries to send tokens from the taker to a maker. If that second step fails, Solana rolls everything back.

There’s no half-done state. The blockchain either records all the changes or none of them. Every handler must return Ok(()) for the transaction to succeed.

5. Where are the transactions in my program?

You might wonder, “Wait, I keep hearing about transactions, but I never write one in my program.”

That’s because transactions live on the client side. A transaction is just a collection of one or more instructions, sometimes even for different programs.

For example:

1. Get a flash loan (instruction 1, flash loan program)
2. Perform swaps (instructions 2–4)
3. Write a memo (instruction 5)
4. Return the loan (instruction 6)

If any instruction handler in any program fails, the entire transaction fails. So the chain always stays consistent no half-finished operations.

6. How can we specify an account that doesn’t exist yet?

You might notice that when you make something like make_offer, you still specify the vault and offer accounts even though they don’t exist yet.

That’s because Solana just wants the addresses up front, not the accounts themselves. This helps the runtime process transactions in parallel safely.

So when you give it those addresses, you’re basically saying, “Hey, I’m going to use these please make sure no one else touches them while I do.”

7. Why do clients get to choose IDs?

You’ll often see clients providing their own IDs for things like offers, and it feels strange why not let the program generate them?

Well, randomness and determinism don’t mix well on a blockchain. Every validator needs to produce the same results.

So, instead, clients pick the ID, and the program checks if it’s valid or already taken (thanks to constraints like init). If that address already exists, the instruction fails. Simple and safe.

8. Why does this handler not need a particular argument?

Sometimes you’ll look at a handler and think, “Wait, where’s the ID argument?”

The answer: it’s already in the accounts. For example, make_offer takes an explicit ID in a swap program because it needs to create a new offer. But take_offer doesn’t just read the existing offer account, which already contains that ID and all its data.

So when an argument seems missing, it’s probably coming from the accounts instead of function parameters.

9. Owner vs. Authority

This one trips up a lot of folks.

If you inspect a token account, you’ll see an owner and possibly an authority. The owner is usually the token program that’s the one managing the rules. The authority is whoever can actually sign to make changes often a PDA.

So think of it like this:

• Owner → the system you interact with

• Authority → the boss who gives the orders

Some explorers even mix up the terms, so don’t rely too heavily on their labels.

10. The mystery of &[&[&[u8]]]

Finally, the big one the three-layered beast.

Anchor calls this signer_seeds, but Andrew Fancong once suggested a much better name: signer_seeds_bytes and he’s right.

Here’s what’s going on:

• The outer array is the list of all signers.
• Each inner array is a set of seeds for one signer.
• The innermost array is the bytes that make up each seed.

So if you’re transferring tokens from an account owned by a PDA called offer, you might have one signer (offer), two seeds ("offer" and offer_id), and each seed’s bytes.

Signers → seeds → bytes. Once you see it that way, it’s really not that scary.

And that’s it. Ten of the most confusing but important Solana concepts demystified. If you remember just one thing: Solana’s naming conventions are creative. But once you get the hang of it, the logic behind the system actually makes a lot of sense.

Next Steps

• Explore more advanced topics in Solana development, such as optimizing transaction processing and implementing complex business logic.
• Engage with the Solana community for support and further learning resources.

By following this guide, you should have a clearer understanding of the foundational concepts in Solana development, enabling you to build more effectively on the platform.

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.