# Arc 9 Catch-Up: Writing Your First Solana Program

With Arc 9 of 100 Days of Solana, we enter the third big phase — or Epoch, as we call them — of the learning program.

And we make a pretty big shift.

Up until now, we have been getting hands-on with Solana mostly through JavaScript. We have created wallets, sent transactions, minted tokens, configured Token-2022 extensions, and inspected on-chain state from the client side.

Arc 9 changes the angle.

Rust is the native language of Solana programs, and this arc is our first step into writing Solana logic ourselves.

The program we built was deliberately simple: a counter.

Initialize it. Store who owns it. Increment it. Reject anyone else who tries.

This was a great way to learn a little about the shape of Solana program dev:

instructions as program entry points
accounts as state
account constraints as guardrails
tests that prove both success and failure paths

So, let's get into the details.

Anchor gives us a framework for Solana programs

In Web2, we use frameworks like Next.js, Ruby on Rails, Django, and .NET.

The principal Solana equivalent is Anchor.

Like its Web2 equivalents, Anchor gives us a project structure, a way to define instructions, a way to describe the accounts each instruction needs, and a testing setup that makes local development much more approachable.

And that really helps when we're taking our first steps with Rust development for Solana. We don't need to be learning low-level details at this stage. Instead, we are trying to get a working program in place, understand its shape, and build enough confidence to change it.

A counter is enough to learn the shape

The first program we built was a counter because it gives us just enough state and behavior to make the Solana program model visible:

create an account
store some data in it
update that data later
restrict who is allowed to update it
write tests that prove those rules work

The program starts with an initialize instruction.

That instruction creates a new counter account, stores the wallet that created it as the authority, and sets the count to zero.

pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
    let counter = &mut ctx.accounts.counter;

    counter.authority = ctx.accounts.authority.key();
    counter.count = 0;

    Ok(())
}

Even if you're brand new to Rust, you can probably get the idea of what's happening here.

We get the counter account from ctx.accounts.counter, store the authority's public key, set the count to 0, and return Ok(()).

But there is a lot happening around that small handler.

That setup lives in the accounts struct.

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = authority, space = 8 + Counter::INIT_SPACE)]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub authority: Signer<'info>,

    pub system_program: Program<'info, System>,
}

This is one of the first big Anchor lessons.

The instruction handler tells us what the program does.

The accounts struct tells us what accounts the instruction needs, what permissions they need, and what checks Anchor should run before the handler executes.

In this case, it says:

create a new counter account
use authority to pay for it
make sure authority signed the transaction
allocate enough space for the account data
use the System Program to create the account

The handler is short because the accounts struct is doing a lot of the setup work.

That is the shape we keep coming back to in Arc 9: instruction logic in one place, account requirements in another.

The account is the program's state

The counter data itself lives in a custom account.

#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub authority: Pubkey,
    pub count: u64,
}

This is the first bit that feels different if you are coming from normal web development.

In a Web2 app, you might expect this state to live in a database row. You might have a counters table with an owner_id column and a count column.

In this program, the state lives in a Solana account.

The count field stores the number.

The authority field stores the wallet that is allowed to update it.

That second field is what makes the example useful. Without it, anyone could increment the counter. With it, the program has a rule it can check later.

So even though the counter is simple, it already has the ingredients of a real program:

stored state
ownership
an update path
a rule about who is allowed to use that path

Incrementing the counter introduces authorization

Once the counter exists, the next step is to update it.

That happens through an increment instruction.

pub fn increment(ctx: Context<Increment>) -> Result<()> {
    let counter = &mut ctx.accounts.counter;

    counter.count = counter.count
        .checked_add(1)
        .ok_or(ProgramError::ArithmeticOverflow)?;

    Ok(())
}

Again, the handler itself is easy enough to follow.

It gets the counter account, adds one to the count, and returns Ok(()).

The checked_add(1) part is worth noticing. Rather than adding blindly, it checks for overflow and returns an error if the number cannot safely be increased.

But the more important part of this instruction is not the arithmetic.

It is the account constraint.

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut, has_one = authority)]
    pub counter: Account<'info, Counter>,

    pub authority: Signer<'info>,
}

The key line is this:

#[account(mut, has_one = authority)]

mut says the counter account can be changed.

has_one = authority says the authority field stored in the counter account must match the wallet signing this instruction.

That is the rule that stops one wallet from incrementing someone else's counter.

In a web app, we might write that as an authorization check inside a controller or route handler:

if counter.owner_id != current_user.id:
    reject the request

In Anchor, that rule is declared on the account instead.

So the instruction has two parts working together:

the handler says what happens when the instruction is allowed to run
the accounts struct says what must be true before it runs

That is why this tiny counter example is useful. It is not just changing a number. It is changing a number only when the right signer is present.

LiteSVM makes the tests feel like normal development

Once we had initialize and increment, we needed to prove they worked together.

That is where LiteSVM came in.

LiteSVM lets us run the program locally in an in-process Solana environment. We do not need to deploy to devnet, request SOL, wait for confirmations, or debug against a remote cluster.

For this arc, that was exactly what we needed.

We could build the program, run the tests, change the code, and run the tests again.

anchor build
cargo test -p counter -- --nocapture

The first useful test followed the happy path:

create a local Solana test environment
load the compiled counter program
create a counter account
call initialize
call increment
read the counter account back
check that the count is now 1

That test matters because it is not just calling a Rust function directly.

It sends transactions to the program.

The program receives accounts.

The account data changes.

Then the test reads the account back and checks what actually happened.

So even though the test runs locally, it still teaches the right execution model.

That is the main value of LiteSVM here: it gives us a fast feedback loop without pretending that Solana programs work like ordinary local functions.

The happy path is not enough

At this point, the program worked.

We could initialize a counter. We could increment it. We could read the account back and check that the count was 1.

That is a good start, but it only proves the program works when everything is used correctly.

It does not prove the program refuses to do the wrong thing.

That matters because Solana programs are public. Anyone can call them. Anyone can try different accounts, different signers, and different transaction shapes.

So the next test was more interesting:

wallet A creates the counter
wallet B tries to increment it
the program rejects the transaction

That test proves the authority rule is actually doing something.

The important line was still this:

#[account(mut, has_one = authority)]

The happy-path test proves the right wallet can increment the counter.

The failure test proves the wrong wallet cannot.

Without that second test, we could remove has_one = authority and the happy-path test would still pass.

That is the trap Arc 9 was trying to show us.

A green test suite is not enough if it only checks the path where everything goes right.

Breaking the program proved the tests mattered

The best part of the arc was breaking the program on purpose.

That might sound strange, but it is a useful habit.

Once the tests were passing, we made small changes that should have broken the program, then checked whether the tests caught them.

First, we removed the authorization rule.

#[account(mut)]
pub counter: Account<'info, Counter>,

Now the counter was still mutable, but Anchor was no longer checking that the signer matched the stored authority.

That is exactly the kind of bug the wrong-wallet test should catch.

And it did.

Then we changed the arithmetic so the counter added 2 instead of 1.

The transaction still succeeded. Nothing crashed. But the stored value was wrong, so the happy-path assertion caught it.

That is a different kind of bug.

The program runs, but writes the wrong state.

Finally, we broke initialization by not storing the authority.

The initialize instruction still looked like it worked. The account was created. The count was set to zero.

But the next instruction failed, because the program later tried to check an authority value that had never been stored correctly.

That was probably the most useful debugging lesson in the arc.

In Solana programs, one instruction might write state and another instruction might validate that state later.

So the error does not always appear where the bug was introduced.

Sometimes you have to work backwards:

which account failed validation?
which field was wrong?
which instruction wrote that field?
what did the account actually store?

The counter example was small, but the lesson scales.

If you can understand that pattern here, you are better prepared for real programs later.

What Arc 9 taught us

Arc 9 was not really about building a counter.

The counter was just the smallest useful program for learning the shape of Anchor development.

By the end of the arc, we had seen how to:

scaffold a Solana program with Anchor
write instructions in Rust
create and store data in an account
use an accounts struct to describe what an instruction needs
protect state with an authority rule
test real transactions locally with LiteSVM
write both happy-path and failure-path tests
break the program on purpose to prove the tests were meaningful

That is a meaningful shift from the earlier arcs.

Before this, we were mostly using Solana from the outside. We were creating wallets, sending transactions, minting tokens, configuring extensions, and inspecting what existing programs did.

In Arc 9, we started writing the program logic ourselves.

The next limitation is addressability.

In this arc, the counter account used a fresh keypair address. That works for a first program, but it means the client has to remember where each user's counter lives.

Most real Solana programs need a more predictable way to find program-owned state.

That is where Program Derived Addresses come in.

So Arc 9 gives us the foundation: write a program, store state, enforce a rule, and test it properly.

The next arc builds on that by making the account address itself part of the program design.