DEV Community: Matthew Revell

Arc 11 Catch-Up: Composing Solana Programs with CPIs

Matthew Revell — Thu, 16 Jul 2026 12:46:25 +0000

Arc 11 covered Days 71–77 of Epoch 3, and it was all about Cross-Program Invocations.

In Arc 9, we wrote our first Solana program.

In Arc 10, we gave that program a more useful state model with Program Derived Addresses.

But our programs were still mostly working alone.

They could read and update their own accounts, enforce their own constraints, and respond to instructions sent by a client. They could not directly change state owned by another program or bypass the rules that program enforced.

That is an important part of Solana’s security model.

The System Program owns the rules for creating accounts and transferring lamports.

Token-2022 owns the rules for mints, token accounts, supply, and mint authorities.

If our program needs one of those capabilities, it calls the program that owns the operation.

That call is a Cross-Program Invocation, or CPI.

The Web2 comparison is a service-to-service API call. One service sends a request through another service’s public interface, and the receiving service applies its own rules.

A CPI works in a similar way, with one important difference: the outer and inner instructions execute as part of the same Solana transaction. If the inner call fails, the state changes made by the outer instruction are rolled back too.

That combination of clear program boundaries and atomic execution is what makes Solana programs composable.

Our first CPI called the System Program

The arc began with the smallest useful CPI we could build.

Our Anchor program accepted a sender, a recipient, and an amount of SOL to transfer.

But the program did not edit the sender’s balance directly.

Instead, it called the System Program’s transfer instruction.

That distinction matters.

Accounts on Solana are owned by programs, and the owner program controls how their data may be changed. Our program could not simply reproduce the effect of a System Program transfer by adjusting balances itself.

It had to ask the System Program to perform the operation.

Every CPI needs three things:

the program being called
the accounts that program expects
the authority required to approve the action

For the SOL transfer, the called program was the System Program.

The required accounts were the sender and recipient.

The authority came from the sender, who had signed the original transaction.

Our program assembled those pieces and made the inner call. The System Program then applied its own rules and either accepted or rejected the transfer.

That gave us the basic CPI model we used throughout the arc.

The caller requests an operation.

The callee validates the request.

The callee remains responsible for the state it owns.

Signer authority can flow into an inner call

The sender in that first exercise was a normal wallet signer.

The wallet signed the outer transaction sent by the client. When our program called the System Program, that signer privilege was also available to the inner instruction.

The CPI did not invent new authority.

It passed along authority that already existed in the transaction.

The same applies to writable accounts. A program cannot make an account writable during a CPI if the original transaction supplied it as read-only.

That gives us an important boundary:

A CPI cannot arbitrarily escalate account privileges.

Writable access must already have been granted by the transaction. Signer authority must come either from an existing signer or from a PDA controlled by the calling program.

That second form of authority became the major step forward later in the arc.

Token-2022 followed the same pattern

The next exercise moved from transferring SOL to minting tokens.

Our program called Token-2022’s mint_to instruction to increase a mint’s supply and deposit the new tokens into a destination token account.

The accounts were different, but the CPI model stayed the same.

The call needed:

the Token-2022 program
the mint
the destination token account
the mint authority

The mint authority was still a regular wallet signer, so its signature flowed from the outer transaction into the Token-2022 instruction.

Token-2022 then applied its own rules.

It checked that the mint and destination accounts were valid, that the supplied authority matched the mint’s recorded authority, and that the authority had signed.

Our program did not need to recreate any token logic.

It only needed to assemble a valid request.

That is the larger value of learning the CPI pattern.

Once we understand the combination of program, accounts, and authority, existing Solana programs become building blocks we can call from our own code.

The System Program already knows how to transfer SOL.

Token-2022 already knows how to manage token supply.

Our program can use those capabilities while each called program keeps control of its own rules.

A CPI still crosses a real program boundary

Anchor’s CPI helpers can make the interaction look similar to calling a local function.

But the called program does not simply trust the caller.

It receives an instruction, examines the supplied accounts, checks their privileges and relationships, and runs its own logic.

The caller decides what it wants to request.

The callee decides whether that request is valid.

For the System Program, that means enforcing the rules for lamport transfers.

For Token-2022, it means enforcing the rules for mints and token accounts.

For another Anchor program, it means applying that program’s account constraints and instruction logic.

The inner program is therefore more than a shared code library.

It is a separate on-chain authority with its own state and security boundary.

That is what makes composition useful. Programs can depend on one another without surrendering control of the accounts they own.

PDA signing gave the program its own authority

The first two CPIs used wallet signers.

That gave us a useful baseline: the user signed the outer transaction, and the inner program recognised the same authority.

The next challenge introduced a different situation.

We built a per-user SOL vault at a PDA.

Each user had a predictable vault address derived from the program’s seeds.

Depositing into the vault was straightforward. The user controlled the source account and signed the transaction, so that authority could flow into the inner transfer.

Withdrawing from the vault raised a harder question.

The vault was a PDA.

It had no private key and could not sign a transaction in the way a wallet could.

The answer was a PDA-signed CPI.

When the program made the inner call, it supplied the original seeds and canonical bump used to derive the vault.

The Solana runtime combined those values with the calling program’s ID and derived the address again.

If the result matched the vault account, the runtime treated that PDA as a signer for the inner invocation.

The program never obtained or stored a private key for the PDA.

It proved authority by reproducing the derivation that created the address.

That is the core of PDA signing.

A program can control an on-chain account or asset through a deterministic address, then authorise actions for it only when its own instruction logic allows those actions.

Signer seeds are not secrets

The phrase “signer seeds” can make the seeds sound like passwords.

They are not.

Anyone can inspect the program and see the seed scheme. The bump may also be visible in account data or derived again by a client.

That does not let another user or program impersonate the PDA.

The program ID is part of the derivation.

Another program could use the same seed values, but its own program ID would produce a different address.

The runtime only grants signer privilege when the seeds, bump, calling program ID, and account address all match.

The security comes from that relationship, along with the program logic that controls when the signer seeds are used.

This gives a program its own deterministic on-chain identity without introducing another private key that someone has to create, protect, and rotate.

A PDA can hold SOL, control a token mint, own a token account, or act as an authority for another program.

The program decides when that authority may be exercised.

Programs can call other custom programs

The first exercises called established Solana programs.

Day 74 took the next step: one custom Anchor program called another.

The first program owned a tally account and exposed an instruction that incremented it.

The second program invoked that instruction through a CPI.

The client sent a transaction to the caller program. The caller then invoked the counter program, which updated the account it owned.

The client never called the counter instruction directly, but the tally still increased.

That demonstrated an important boundary.

The caller program could not edit the counter program’s account itself.

It had to request the update through the counter program’s public instruction.

The counter program remained responsible for validating the accounts and deciding whether the update was allowed.

That is how larger on-chain systems can be assembled from smaller programs.

One program can provide a focused capability.

Another can use that capability as part of a wider workflow.

The callee remains in control of its state, while the caller gains access to its public behaviour.

The IDL becomes a contract between programs

To call another Anchor program, the caller needs to understand its public interface.

It needs to know:

the program ID
the available instructions
the arguments those instructions accept
the accounts they require
the account and data types they expose

Anchor describes that interface in an IDL.

The caller can use the callee’s IDL to generate typed CPI bindings. It does not need to copy or compile the callee’s source code into its own program.

That is similar to using an API specification to call another service.

The caller depends on the published contract rather than the internal implementation.

The callee can refactor its code while keeping callers compatible, provided that its external instruction and account interface remains stable.

But changes to that interface can break integrations.

Renaming an instruction, changing its arguments, adding required accounts, or altering an account layout may affect programs and clients that already depend on it.

Once other programs compose with ours, the IDL is no longer only a development convenience.

It becomes part of the interface other software expects us to preserve.

The whole call stack remains atomic

A CPI does not create a separate transaction.

The inner instruction executes as part of the transaction that called the outer program.

Consider an instruction that:

Updates one of its own accounts.
Calls Token-2022 to mint tokens.
Updates another account after the mint succeeds.

If Token-2022 rejects the mint, the entire transaction fails.

The state update performed before the CPI does not remain on-chain.

There is no partially completed result where the caller records that the operation succeeded but the token mint did not change.

Everything succeeds together or everything is rolled back.

Anyone who has written compensation logic or reconciliation jobs for distributed workflows will recognise why that matters.

It allows a Solana program to combine operations across several programs without having to repair state when one step in the middle fails.

It also means that an error deep in a chain of CPIs can cause every preceding change in the transaction to be reverted.

Breaking CPIs showed where integrations fail

Once the working paths were in place, we deliberately broke them.

We tested three common categories of failure:

incorrect PDA signer seeds or bump
missing or incorrect accounts
the wrong program ID

Each failure exposed a different part of the contract between caller and callee.

Wrong signer seeds

For a PDA-signed CPI, the runtime derives the PDA again using the supplied seeds, bump, and calling program ID.

If any of those inputs are wrong, the result does not match the account expected to sign.

The inner instruction then sees that its required authority is missing.

A one-byte difference is enough to break the derivation.

When debugging, the key question is:

Do these exact seeds and this bump derive the exact PDA being supplied as the authority?

If they do not, the runtime cannot grant signer privilege.

Wrong accounts

Every instruction expects a particular set of accounts.

Those accounts may need to be:

writable
signers
owned by a particular program
derived from particular seeds
linked through a stored relationship
associated with a particular mint or authority

Passing the wrong account often produces an Anchor constraint error.

Those errors can identify both the account and the validation that failed.

The callee’s accounts struct is therefore more than setup code.

It is the contract the caller must satisfy.

When a CPI fails, comparing the supplied accounts against that contract is often the fastest route to the cause.

Wrong program ID

The caller must also invoke the correct program.

Typed program accounts help protect this boundary. Anchor can validate the supplied program account before attempting the CPI and reject an unexpected ID during account validation.

With a loosely typed program account, that protection may not exist.

The runtime can invoke the program it was given, even when the instruction data was intended for someone else.

The error then comes from the unintended program trying to interpret an instruction it does not recognise.

This is one reason typed accounts are valuable.

They turn a confusing downstream failure into a clearer validation failure at the program boundary.

Transaction logs reveal the call stack

CPI debugging becomes easier when we stop looking only at the final error code.

The transaction logs show the sequence of execution:

the outer program begins
it reaches the CPI
the inner program is invoked
the inner program validates its accounts
an instruction succeeds or fails
the result propagates back through the call stack

That sequence tells us which program was running when the failure occurred.

Most CPI bugs come from one of two places:

The caller assembled the request incorrectly.
The callee enforced a rule that the supplied request did not satisfy.

Useful questions include:

Which program produced the error?
Which inner instruction was being called?
Did the caller provide every required account?
Were the signer and writable privileges correct?
Did the signer seeds derive the expected PDA?
Did Anchor identify a failed constraint?
Was the intended program actually invoked?

A CPI failure is usually the on-chain equivalent of an API request that did not match the receiving service’s contract.

The logs help us find the point where that mismatch occurred.

Writing the explanation forced us to choose the important part

The final two days moved from implementation to communication.

CPIs include enough moving parts that it is tempting to explain all of them at once:

program ownership
nested instructions
account privileges
wallet signers
PDA signing
IDLs
atomicity
transaction logs

That can produce an explanation that is technically complete but hard to follow.

The challenge instead asked us to choose one clear thesis.

One possible framing was:

A CPI is a function call with a guest list.

The called instruction needs the right program, the right accounts, and the right authority.

Another focused on the major conceptual jump:

Signer seeds are how a program proves control of its PDA.

The seeds are not secret credentials. They let the runtime reconstruct the PDA under the calling program’s ID and grant it signer privilege for one inner invocation.

The public explanation needed:

one clear mental model
one small example
the three ingredients of a CPI
one real error encountered during the week
evidence from the working program

That evidence might be passing test output, a GitHub repository, a concise implementation excerpt, or a devnet transaction.

As in the previous arcs, publishing the work was part of the learning process.

Explaining where authority comes from, which program owns the operation, and why a broken CPI fails reveals gaps that successful tests alone may not expose.

What Arc 11 taught us

Arc 11 moved us from isolated programs to composed systems.

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

call the System Program from an Anchor instruction
transfer SOL through a CPI
call Token-2022 to mint tokens
supply the program, accounts, and authority required by a callee
pass wallet signer authority into an inner instruction
understand the limits on signer and writable privileges
authorise an inner call with a PDA
control on-chain assets without storing a private key
call one custom Anchor program from another
use an IDL as the contract between programs
treat instruction and account changes as compatibility decisions
break CPIs with incorrect seeds, accounts, and program IDs
read transaction logs as a record of the program call stack
explain program composition through a clear, concrete example

The enduring lesson is that Solana programs are interoperable pieces of infrastructure.

A program that needs to transfer SOL can call the System Program.

A program that needs to mint tokens can call Token-2022.

A program that needs behaviour exposed by another custom program can call that program through its public instruction interface.

Each callee keeps control of its accounts and applies its own authorisation rules.

The caller gains the capability without copying the implementation or bypassing the program that owns the state.

That is what CPIs make possible:

Solana programs can combine trusted on-chain capabilities into one atomic transaction.

Revisit the Arc 11 challenges

Day 71: Call the System Program from your own program to transfer SOL
Day 72: Use a CPI to mint tokens through Token-2022
Day 73: Build a PDA-controlled SOL vault and sign a CPI with seeds
Day 74: Call one custom Anchor program from another through its IDL
Day 75: Break working CPIs and debug signer, account, and program errors
Day 76: Write a clear public explanation of how Cross-Program Invocations work
Day 77: Share your composed program with code, tests, and on-chain evidence

Arc 10 Catch-Up: Designing Solana State with PDAs

Matthew Revell — Thu, 16 Jul 2026 11:18:42 +0000

Arc 10 covered Days 64–70 of Epoch 3, and it was all about Program Derived Addresses.

Arc 9 gave us our first Solana program.

We built a counter, stored its state in an account, restricted updates to the correct authority, and used LiteSVM to prove those rules worked.

But the counter account had a limitation.

It used a randomly generated keypair for its address.

That is manageable in a small exercise. The client creates the account, keeps hold of its public key, and passes that address back whenever it wants to increment the counter.

It becomes awkward once we want one counter per user.

Where do we store all those addresses? How does a user find their counter from another device? How does the program know that the account it received is the correct counter for that wallet?

Arc 10 answered those questions with Program Derived Addresses, or PDAs.

A PDA gives a Solana program a predictable way to create and locate state. Its address comes from the program ID and a set of seeds chosen by the program. For our counter, that meant deriving an address from the word counter and the user's public key.

The same inputs always produce the same address. Different users produce different addresses.

That makes PDA design part of both the program's state model and its security model.

A PDA gives program state a predictable address

Before Arc 10, our client created the counter account using a fresh keypair.

That gave the account a unique address, but there was no relationship between the address and what the account represented.

The address did not tell us:

which program used the account
which user owned the counter
whether it was the correct counter for a particular instruction
how to find it again without saving the address somewhere

PDAs solve this by deriving an address from known inputs.

In JavaScript, we can derive one using findProgramAddressSync:

const [counterPda, bump] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter")],
  programId
);

The inputs here are:

the program ID
the seed counter
a bump value found during derivation

Given those same inputs, we get the same PDA every time.

That is the first important property: determinism.

We can close the script, run it again tomorrow, and derive the same address without storing it in a database or configuration file.

The second important property is that every byte matters.

Changing the seed from counter to alice produces a completely different address:

const [alicePda] = PublicKey.findProgramAddressSync(
  [Buffer.from("alice")],
  programId
);

Changing it again to bob produces another:

const [bobPda] = PublicKey.findProgramAddressSync(
  [Buffer.from("bob")],
  programId
);

Restoring the original seed gives us the original PDA again.

That small experiment made the model tangible.

A PDA is a deterministic address calculated from program-specific inputs.

A PDA has no private key

There is another important difference between a PDA and an ordinary wallet address.

A normal Solana keypair contains a public key and a private key. The private key can sign transactions on behalf of the public key.

A PDA is deliberately derived so that it falls outside the ed25519 curve used for Solana keypairs.

That means there is no corresponding private key.

Nobody can generate a secret key for the PDA and sign as it directly.

Instead, the program associated with the PDA can authorise actions for it by supplying the same seeds and bump used to derive it.

This is especially useful when a program needs to control assets or call another program through a Cross-Program Invocation. The PDA can act as an authority without requiring someone to store and protect another private key.

We did not need all of that capability for our counter, but the underlying rule matters:

The program controls the derivation logic, and the derivation logic determines which address the program recognises.

A PDA is an address before it is an account

One easy mistake is to talk about deriving a PDA as though we have created an account.

We have not.

Derivation only calculates an address.

We can derive a PDA that has never held any data, lamports, tokens, or executable code. Until an instruction creates an account at that address, there is nothing there to fetch.

That gives us two separate steps:

Derive the address.
Initialise an account at that address.

Anchor helps us combine those steps when the account is first created.

But the distinction is useful when debugging.

If we derive the correct PDA and getAccountInfo returns null, that does not necessarily mean the derivation failed. It may simply mean the account has not been initialised yet.

Adding the user creates one counter per wallet

The fixed seed [b"counter"] gives us one address for the entire program.

That could be useful for a global account, but it cannot give every user their own counter.

To do that, we added the user's public key to the seed list:

seeds = [b"counter", user.key().as_ref()]

Now the PDA depends on both:

the fixed namespace counter
the public key of the user

Wallet A gets an address derived from:

"counter" + wallet A public key

Wallet B gets an address derived from:

"counter" + wallet B public key

Because the public keys differ, the resulting PDAs differ.

That gives us a predictable one-counter-per-wallet model.

The client does not need to create a random keypair for the counter.

It does not need to store the counter address in local storage.

It does not need to query a registry to discover which account belongs to the user.

It can derive the address again whenever it needs it.

In Web2 terms, it is similar to locating a row using a known composite key. The program defines the namespace, the wallet identifies the user, and the combination identifies the state.

Anchor can create the account at the derived address

We expressed that seed scheme inside our Anchor accounts struct:

#[derive(Accounts)]
pub struct InitializeCounter<'info> {
    #[account(
        init,
        payer = user,
        space = 8 + Counter::INIT_SPACE,
        seeds = [b"counter", user.key().as_ref()],
        bump
    )]
    pub counter: Account<'info, Counter>,

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

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

Several constraints work together here.

init tells Anchor to create the account.

payer = user says the user will fund the account's rent-exempt lamport deposit.

space = 8 + Counter::INIT_SPACE allocates enough storage for the account.

seeds declares how the PDA should be derived.

bump tells Anchor to find and use the canonical bump for that derivation.

The space value deserves a moment of attention. With InitSpace, Anchor calculates the size of the account's fields for us, but the allocation still needs an extra eight bytes for Anchor's account discriminator. The discriminator identifies which Anchor account type the data belongs to, and it helps prevent one account type from being deserialised as another simply because its bytes happen to have a compatible shape. Getting this wrong can stop the account from initialising or leave too little space for its data.

The account itself stores the user, the count, and the bump:

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

The initialisation handler can then populate those fields:

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

    counter.user = ctx.accounts.user.key();
    counter.count = 0;
    counter.bump = ctx.bumps.counter;

    Ok(())
}

Anchor has already checked the account address and created the account before this handler runs.

The handler only needs to write the initial state.

That follows the same pattern we saw in Arc 9:

the accounts struct describes the required accounts and validates them
the handler performs the instruction's state change

The bump completes the derivation

The bump can feel mysterious when we first encounter it.

Solana needs PDAs to be off the ed25519 curve so that no private key exists for them.

The derivation process starts with the program ID and the seeds, then tries bump values until it finds an address that satisfies that requirement.

findProgramAddressSync returns both results:

const [counterPda, bump] = PublicKey.findProgramAddressSync(
  [
    Buffer.from("counter"),
    user.publicKey.toBuffer(),
  ],
  programId
);

Anchor normally handles this search for us.

When we write a bare bump during initialisation, Anchor runs the search, finds the canonical bump, and makes it available through ctx.bumps.counter so we can store it in the account.

That stored value is why later instructions use a different form:

bump = counter.bump

This tells Anchor: do not run the search again. Take the stored bump, perform a single derivation with it, and check the result against the supplied account.

The search loop costs compute units, and it would otherwise run on every instruction that touches the account. Storing the bump once at initialisation and reusing it turns that repeated search into a single calculation.

So the bump is part of how Solana finds a valid off-curve address, and storing it is a small optimisation the program pays for once and benefits from on every subsequent instruction.

Seeds are validation rules

At first, PDAs can look like an address-generation convenience.

They save the client from keeping track of random account addresses.

That is useful, but it is only half of the story.

The same seeds also let Anchor verify that an instruction received the correct account.

Our increment instruction used the counter's PDA constraints again:

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(
        mut,
        seeds = [b"counter", user.key().as_ref()],
        bump = counter.bump,
        has_one = user
    )]
    pub counter: Account<'info, Counter>,

    pub user: Signer<'info>,
}

Before the handler runs, Anchor can:

Read the user's public key.
Combine it with the counter seed.
Re-derive the expected PDA.
Compare that address with the supplied counter account.
Check that the account's stored user field matches the signer.

If any of those checks fail, the transaction is rejected before the instruction changes state.

Strictly speaking, the seed constraint alone already binds this counter to the signer, because the signer's public key is part of the derivation. The has_one = user check overlaps with it here, acting as defence in depth. Where has_one really earns its keep is when the seeds do not include the related key, and the stored relationship is the only thing tying the account to a signer. We will see that shortly with the config account.

Either way, the program does not need to repeat address checks inside every handler.

The account constraints declare the invariant once:

This instruction accepts the counter derived for this user, and that counter must record the same user internally.

The handler can then remain focused on the state change:

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(())
}

The seed constraint proves we received the expected address.

The has_one constraint proves the account data records the expected relationship.

Together, they protect the counter from substitution.

A spoofing attempt showed the security boundary

We tested those constraints by deliberately passing the wrong account.

Wallet A had its own counter PDA.

Wallet B had a different counter PDA.

Then Wallet A called increment while supplying Wallet B's counter account.

Without PDA validation, the program might have accepted any account with the right data shape.

With the seed constraint in place, Anchor derived the counter address expected for Wallet A and compared it with the supplied address.

They did not match.

The instruction failed before the handler executed.

That test made the security role of PDAs much clearer.

The PDA is not secure merely because its address looks unusual. The protection comes from the program declaring the correct derivation and validating that derivation whenever the account is used.

Global state needs a different seed scheme

The per-user counter gave each wallet its own state.

Real applications often need another category of state: information that applies to the whole program.

For that, we added a configuration PDA:

seeds = [b"config"]

Because this derivation does not include a user public key, every caller derives the same address.

That makes it suitable for singleton state.

Our config account stored fields such as:

#[account]
#[derive(InitSpace)]
pub struct Config {
    pub admin: Pubkey,
    pub paused: bool,
    pub total_counters: u64,
    pub bump: u8,
}

Now the program had two kinds of state:

one global configuration account
one counter account per user

The config account could hold program-wide policy.

The counter account could hold user-specific data.

The two can also meet in a single instruction. Our initialize_counter handler incremented config.total_counters alongside creating the user's counter, so one transaction touched both the global account and the per-user account. That pattern, one instruction updating global and scoped state together, appears constantly in real programs.

A program might have:

one global marketplace configuration
one position per trader
one vault per token mint
one profile per wallet
one pool account per asset pair

The seed scheme tells us which state is shared and which state is scoped to a particular entity.

Constraints let us express relationships and business rules

As the program gained more state, Anchor constraints became its main validation language.

For example:

#[account(
    seeds = [b"config"],
    bump = config.bump,
    has_one = admin
)]
pub config: Account<'info, Config>,

pub admin: Signer<'info>,

Here, has_one = admin checks that the public key stored in config.admin matches the signer passed as admin.

Notice that the config seeds contain no user key, so the derivation alone cannot tell us who is allowed to administer the account. The stored admin field is the only link, and has_one is what enforces it. This is the case where has_one is doing essential work rather than doubling up on the seed check.

If the counter accounts are rows keyed by user ID, the config account is the settings table: one row, program-wide, with a recorded owner. And has_one behaves much like a foreign-key check, verifying that a stored reference actually points at the account the instruction received. The difference from a Web2 database is that these checks execute on-chain, as part of every transaction.

We could also enforce the pause rule directly on the account. To do that, the increment instruction's accounts struct gains the config account alongside the counter:

#[account(
    seeds = [b"config"],
    bump = config.bump,
    constraint = !config.paused
)]
pub config: Account<'info, Config>,

Because the config account is now part of the instruction's required accounts, its constraints run during account validation, and an increment fails while the program is paused.

The handler does not need to contain a separate conditional:

if config.paused {
    return err!(CounterError::ProgramPaused);
}

That does not mean every business rule belongs in an account constraint. Some rules are clearer inside the handler.

But Arc 10 showed how much of the program's structure can be expressed declaratively:

seeds identifies the expected PDA
bump completes its derivation
has_one checks a stored relationship
constraint applies a custom condition
mut marks accounts whose state may change
Signer proves that the required wallet authorised the transaction

These constraints run before the handler.

The instruction only reaches its state-changing logic after the required accounts and relationships have been validated.

Singleton initialisation needs an explicit governance decision

Our exercise allowed the first caller of init_config to become the administrator.

That kept the initialisation code approachable and let us focus on PDAs and constraints.

It should not be copied into a production program without considering the consequences.

If anyone can initialise the singleton config account, then whoever reaches it first may become the program administrator.

A production deployment should define who is allowed to perform that initial setup.

Depending on the program, that authority might be:

a known deployment wallet
the program's upgrade authority
a multisig
an existing governance account
another PDA with its own initialisation rules

The correct design depends on how the program will be governed.

The important lesson is that a singleton PDA gives us one canonical address. It does not decide who should be allowed to create or control the account at that address.

That decision still belongs to the program.

Closing an account completes the state lifecycle

Creating an account costs lamports.

The payer deposits enough lamports to make the account rent-exempt, and those lamports remain attached to the account while it exists.

When the state is no longer needed, the program can close the account and return those lamports.

We added a close_counter instruction using Anchor's close constraint:

#[derive(Accounts)]
pub struct CloseCounter<'info> {
    #[account(
        mut,
        seeds = [b"counter", user.key().as_ref()],
        bump = counter.bump,
        has_one = user,
        close = user
    )]
    pub counter: Account<'info, Counter>,

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

The familiar constraints still protect the account.

seeds and bump verify that this is the user's canonical counter PDA.

has_one = user checks the ownership relationship stored inside the account.

close = user tells Anchor where to send the account's remaining lamports.

The handler itself can be empty:

pub fn close_counter(
    _ctx: Context<CloseCounter>
) -> Result<()> {
    Ok(())
}

Once the instruction completes, Anchor:

transfers the account's lamports to the user
invalidates the account data
leaves no live account at that PDA

We can still derive the same address later because the derivation inputs have not changed.

But fetching the account will show that it no longer exists.

That makes closing a PDA-backed account feel different from deleting a row in a normal database. We are releasing on-chain storage and returning its refundable deposit.

It also shows the full lifecycle of program state:

Derive the address.
Initialise the account.
Read and mutate its data.
Enforce who may use it.
Close it when it is no longer needed.
Recover the lamports that funded it.

Seed design defines the state namespace

The experimentation day made us change the seeds and observe the consequences.

First, we derived counters for two users using:

[b"counter", user.key().as_ref()]

The two wallets produced two different addresses.

That is the behaviour we wanted.

Then we removed the user public key and derived both counters from:

[b"counter"]

Both wallets now produced the same address.

There was no cryptographic collision. The derivation worked exactly as designed.

The problem was our design.

We had asked the program for one global counter address, then tried to use it as though every user had their own.

Only the first account could be initialised there. The second user would attempt to initialise an address that was already occupied.

This is one of the most important lessons from the arc.

Seed design determines the namespace of the program's state.

Including a user public key creates user-scoped state.

Including a mint creates mint-scoped state.

Including two asset addresses could create one account per pair.

Using only a fixed seed creates a singleton.

The program will follow the scheme exactly, even when the scheme does not match the application we intended to build.

Almost identical seeds are still different seeds

We also tried small changes to the seed bytes:

counter
counters
Counter
counter\0

Each produced a different PDA.

Those values may look related to a person, but the derivation process does not interpret their meaning.

It only sees bytes.

That means:

uppercase and lowercase values differ
singular and plural values differ
invisible terminators or extra bytes matter
changing seed order changes the result
changing the program ID changes the result

This makes seed conventions worth planning.

Once a program is deployed and accounts have been created, changing a seed can make the new version derive different addresses from the accounts that already exist.

The old state is still on-chain, but the updated program may no longer look for it at the same address.

So seeds should be treated as part of the program's persistent interface, rather than temporary labels we can rename without consequences.

Writing the explanation exposed the gaps

The last two days moved away from program code.

First, we wrote a long-form explanation of PDAs.

That meant describing:

why random account keypairs become inconvenient
how seeds and program IDs produce deterministic addresses
what the bump does
why PDAs have no private keys
why deriving an address does not create an account
how Anchor validates PDA constraints
how seed design affects ownership and account scope
how PDA-backed accounts can be closed

Then we turned that explanation into a shorter social post or thread.

The public version needed a useful example and some evidence from the work: code, test output, terminal output, or an Explorer screenshot.

That final step matters because PDAs can feel clear while we are following an exercise and become much harder to explain without the scaffolding.

Writing the model in plain language forces us to answer the questions that code alone can hide.

Why is the address predictable?

Why can nobody hold its private key?

Why does adding a wallet public key produce one account per user?

Why does a seed constraint prevent account substitution?

Why does the address remain derivable after the account is closed?

If we cannot answer those questions clearly, we probably need another pass through the experiment.

What Arc 10 taught us

Arc 10 turned account addresses into part of the program design.

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

derive a PDA from a program ID, seeds, and a bump
verify that the same inputs always produce the same address
create one state account per user
initialise an Anchor account at a PDA
distinguish a derived address from an initialised account
use seeds and bump to validate an account
store the bump once and reuse it to save compute
use has_one to bind stored state to a signer
combine global configuration with per-user state
enforce a pause rule before the handler runs
close an account and reclaim its lamports
test account-substitution attempts
observe how incomplete seed schemes create logical address conflicts
explain PDA design in public

The counter still performed the same basic job as it did in Arc 9.

It initialised a number, stored an owner, and allowed that number to be incremented.

But the surrounding design became much more useful.

Each wallet could find its counter without saving a random address.

The program could prove that the supplied counter belonged in that user's namespace.

Global policy lived at one predictable config address.

User state lived at a different predictable address for every wallet.

And when the state was no longer needed, the user could close it and recover the lamports used to create it.

That is the lasting lesson from Arc 10.

PDA design is state-model design.

The seeds decide what state exists, how many instances can exist, what each instance belongs to, and how the program can locate and validate it later.

Revisit the Arc 10 challenges

Day 64: Derive your first Program Derived Address and see how seeds change the result
Day 65: Replace random counter keypairs with one predictable PDA per user
Day 66: Add a global configuration PDA and enforce admin and pause rules
Day 67: Close a user's counter and return its rent-exempt lamports
Day 68: Break the seed scheme and test whether account spoofing succeeds
Day 69: Write a long-form explanation of how PDAs shape program state
Day 70: Turn your PDA explanation into a public post with evidence from your work

Welcome to Epoch 4: Shipping and Exploring

Matthew Revell — Mon, 13 Jul 2026 13:34:40 +0000

Arc 13 of 100 Days of Solana starts today and it opens Epoch 4: Ship and Explore.

Every tutorial has the same ending. The program builds, the tests pass, it runs on devnet, and the article stops. Which is a strange place to stop, because that's exactly where a Web2 developer would say the interesting part begins: the production deploy.

Arc 13 is seven days on that part.

Mainnet is not just another cluster

On devnet, everything is free and nothing is permanent. Airdropped SOL, throwaway deploys, program addresses nobody will ever call. It's staging, and it behaves like staging.

Mainnet-beta changes four things at once. The deploy costs real SOL — program accounts are rent-exempt, and for a non-trivial Anchor program that's a real (if modest) amount of money. The program address becomes public infrastructure: anyone can find it, read it, and call it. Whoever holds the upgrade authority can replace the program's code entirely, which makes that keypair equivalent to root credentials on a production box. And there's no access control at the network level — strangers can send transactions to your program the moment it lands.

None of this is scary if you've run production systems before. It's the same discipline — deploy intentionally, control who holds the keys, publish a contract for integrators, handle failure states in front of users — wearing different names.

The Rosetta Stone

If you know the Web2 column, Arc 13 teaches you the Solana column:

Web2	Solana
Staging → production	Devnet → mainnet-beta
Release artifact	`anchor build` output (the `.so` file)
Production deploy rights	Upgrade authority
Branch protection / required reviewers	Multisig upgrade authority
OpenAPI / GraphQL schema	IDL
Generated typed SDK	Codama client
"Sign in with Google"	Wallet Standard
Public changelog / release page	Explorer link

The one that surprises most people is the IDL. Solana programs don't self-describe the way a REST API with an OpenAPI spec does — unless you publish the IDL, at which point other developers can generate typed clients, inspect your instructions, and integrate without reading your source. Publishing it is the difference between a deployed program and a usable one.

The seven days

Day 85 — Deploy an Anchor program to mainnet-beta. The staging-to-production promotion, done deliberately rather than by accident.
Day 86 — Decide who is allowed to upgrade the program. Keep the authority, transfer it to a multisig, or burn it entirely — each is a real product decision with real trade-offs.
Day 87 — Publish the IDL and generate a typed client, so other developers can call the program without guessing at byte layouts.
Day 88 — Connect a wallet from the frontend and send a transaction. This is where a human finally meets the program.
Day 89 — Write useful messages for failed transactions. Wallet errors are production UX, not an edge case to be polished later.
Day 90 — Write a production launch checklist. The artifact future-you actually needs at 11pm before the next deploy.
Day 91 — Launch publicly, with an explorer link. A deploy isn't done until someone else can verify it.

What you'll have at the end

A program on mainnet-beta, a frontend that talks to it, and a public launch post backed by a verifiable on-chain receipt. Not "I completed a course" — "here's my program ID, go look."

That receipt matters more than it might seem. In Web2, a side project claim is just a claim unless it's deployed somewhere. On Solana, the explorer link is proof: the deploy transaction, the upgrade authority, the program's activity, all publicly inspectable. It's the strongest possible artifact for a portfolio or a launch post.

Joining

Interested but not started yet? No problem. You can learn the fundamentals at your own pace with our previous 84 challenges!

Start here: https://mlh.link/solana-100

Epoch 2 content creator challenge

Matthew Revell — Fri, 26 Jun 2026 11:22:47 +0000

In Epoch 2 of 100 Days of Solana, we moved from getting to grips with the fundamentals to creating our own on-chain assets.

That gave us a lot to work with: tokens, mints, metadata, authorities, extensions, and the choices developers make when they create an asset on Solana.

And this challenge is all about seeing those ideas explained clearly for developers coming from Web2.

The prize categories

For the Epoch 2 Content Challenge, we’re awarding prizes in two categories:

Best DEV post
Best YouTube video

To enter, you’ll need to have completed at least five Epoch 2 challenges. Missed a few? No problem. You can catch up now and still take part.

Your post or video should use something from Epoch 2 to help Web2 developers understand Solana. That might mean explaining tokens through a Web2 comparison, showing how NFT metadata works, walking through a Token-2022 extension, or using something you built during the challenges to make an unfamiliar idea easier to grasp.

This shouldn’t just be a diary of what you completed. The goal is to create something useful for developers who are Solana-curious but mostly coming from a Web2 background.

There are a couple of other rules, too:

Your entry will also need to reach at least 50 views.
Entries must be submitted by the end of Sunday, July 5.

When your post or video is live, submit it using this form.

We'll announce the winners on DEV the week after the challenge closes!

Arc 9 Catch-Up: Writing Your First Solana Program

Matthew Revell — Wed, 24 Jun 2026 12:49:27 +0000

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.

Revisit the Arc 9 challenges

Learn Solana the Fast Way

Matthew Revell — Mon, 22 Jun 2026 11:32:02 +0000

As a web or mobile developer, Web3 can seem harder to get to grips with than it really is.

Part of the problem is the vocabulary. Wallets, accounts, mints, programs, signers, authorities, transactions. It can sound as though everything you already know has been replaced by a completely different model.

But many Solana concepts have useful parallels with traditional development.

A transaction is not exactly an API request. A program is not exactly a backend service. A token mint is not exactly a database table. But those comparisons are close enough to give you a way in.

Once you have those bridges, Solana starts to feel less like a wall of jargon and more like another development environment with its own rules, constraints, and patterns.

That is the fast way to learn it: build small things, connect each new idea to something familiar, and let the mental model grow from there.

In this post, we’ll use familiar Web2 ideas as bridges into the Solana model:

Identity and authentication → wallets, keypairs, and signatures
API calls and commands → transactions and instructions
Database records and stored state → accounts
Asset definitions and balances → tokens, mints, and token accounts
Media files and metadata records → NFT metadata
Middleware and business rules → Token-2022 extensions
Backend logic and tests → programs and Anchor

For each one, we’ll explain the Web2 idea first, map it to the Solana concept, then point you to a small challenge where you can try it yourself.

You can read this as a quick map of Solana, but it works better if you pick one section and do the linked challenge.

Each challenge is part of 100 Days of Solana. Sign up, complete the task, and submit your work so your progress counts.

The goal is not to recreate the whole curriculum in one post.

The goal is to give you enough practical understanding that Solana starts to make sense.

1. Identity and authentication: wallets, keypairs, and signatures

In a traditional web or mobile app, identity usually starts with a user account.

Someone signs up with an email address, a password, a social login, or a passkey. Your application stores a user record, manages sessions, and decides what that user is allowed to do.

Solana starts from a different place.

Your wallet is not a user account in the usual Web2 sense. It is a cryptographic identity. More specifically, it is controlled by a keypair: a public key that acts like an address, and a private key that proves you are allowed to sign actions for that address.

The closest Web2 parallel is probably SSH keys or API keys.

If you have used SSH keys with GitHub, the idea is familiar: your public key identifies you, and your private key lets you prove that you are really the person allowed to act as that identity.

On Solana, that proof happens through signatures.

When you send a transaction, your wallet signs it. That signature tells the network: “The holder of this private key authorized this action.”

That is why wallets matter so much. They are not just where tokens live. They are how users approve actions.

Try it

Create your devnet wallet

You’ll create a wallet, request devnet SOL, and check your balance.

The point is not to understand every detail of wallet security yet. The point is to make the first idea concrete:

A Solana wallet is an identity that can sign actions.

When you’re done, submit your result through 100 Days of Solana.

2. API calls and commands: transactions and instructions

In Web2, when your frontend wants something to happen, it usually sends an API request.

That request might create a user, submit a payment, update a profile, or trigger some backend logic.

Solana transactions are not the same as API requests, but the comparison is useful.

A transaction is a signed message sent to the network. Inside that transaction are one or more instructions. Each instruction tells a Solana program what work to perform.

So the rough mapping is:

the transaction is the package being submitted
the instruction is the command inside it
the program is the code that runs
the accounts are the state the program reads or writes
the signer is the identity authorizing the action

This is why Solana transactions can feel strange at first. They are not just “send money from A to B”. They can contain several instructions that run together.

For example, a transaction might create an account and then initialize it. Or it might approve an action and then perform a transfer. If one required part fails, the whole transaction fails.

That gives Solana transactions an important property: they can represent a complete unit of work.

Try it

Send and inspect a devnet transaction

You’ll send a real transaction on devnet, inspect what happened, and connect the abstract idea of “instructions” to something you can actually see.

The key idea is:

A transaction is not just movement of data. It is a signed bundle of instructions.

Submit your completed challenge so your progress is visible.

3. Database records and stored state: accounts

In Web2, you are used to applications storing state in databases.

A user has a row. An order has a row. A payment has a row. Your backend reads and writes that data when something happens.

Solana also stores state, but the model is different.

State lives in accounts.

That word can be confusing because “account” sounds like “user account”. On Solana, an account is more general than that. It is a place where data can live.

An account might hold SOL. It might hold token data. It might store configuration for a program. It might represent part of your application’s state.

A useful Web2 comparison is a database record, but with an important difference: Solana programs do not secretly reach into their own private database. The accounts a program needs are passed into the transaction.

That means the transaction says not only what you want to do, but also which pieces of state the program is allowed to read or write.

This is one of the biggest shifts in the Solana mental model.

You are not calling a backend endpoint that then queries whatever it wants from a database. You are sending an instruction to a program and explicitly providing the accounts involved.

Try it

Inspect a Solana account

You’ll look at a real account and identify its address, owner, and data.

The point is to stop thinking of “account” as only meaning “user account” and start thinking of it as:

A place where on-chain state lives.

4. Asset definitions and balances: tokens, mints, and token accounts

In Web2, if you were building a system with credits, points, tickets, or balances, you might start with a few database tables.

One table might define the asset:

name
symbol
decimal precision
total supply rules

Another table might track balances:

user ID
asset ID
amount

Solana tokens use a similar separation, but the terms are different.

A mint defines the token.

A token account holds a balance of that token for a particular owner.

That distinction matters.

The mint is not your personal balance. It is the source of truth for the token itself: its identity, decimals, supply, and authorities.

A token account is where an owner’s balance of that specific token lives.

So if Alice and Bob both hold the same token, they do not share one balance field on the mint. They each have token accounts connected to that mint.

This is one of the fastest ways to make Solana feel less abstract. Once you create a mint, mint supply, create token accounts, and transfer tokens, you have used several of Solana’s core ideas together.

Try it

This idea takes two short challenges to see end to end.

First, create your first token. You’ll create a mint, create a token account, and mint supply into it.

Then put it to work. You’ll create a token with built-in transfer rules, send it between wallets, and watch the mint and token accounts update.

As you do it, keep this model in mind:

The mint defines the asset. Token accounts hold balances.

When you submit this one, you have more than a screenshot. You have proof that you understand one of Solana’s core building blocks.

5. Media files and metadata records: NFT metadata

In Web2, you rarely store everything directly in one database field.

If you are building a product catalogue, a media app, or a user profile system, you often split things up:

the database stores IDs, names, references, and structured fields
media files live in object storage or a CDN
the frontend combines those pieces into something users can see

NFTs use a similar split.

The token itself gives you the scarce asset: usually a mint with supply of one and zero decimals. But that alone does not tell a wallet what to display.

For that, you need metadata.

Metadata gives clients human-readable information such as:

name
symbol
description
image
attributes
collection information

Some of that information may live on-chain. Some may point to off-chain JSON or media files. The exact mechanics vary depending on the token standard and tooling, but the broad idea is familiar:

The on-chain asset provides ownership and identity. Metadata helps apps understand what the asset represents.

That is why NFTs are worth learning even if you are not especially interested in NFT markets. They teach you how Solana combines ownership, metadata, clients, and off-chain content.

Try it

Add metadata to an asset

You’ll connect an on-chain asset to human-readable metadata and see how wallets know what to display.

Look for the split between:

what lives on-chain
what points off-chain
what the wallet or client chooses to show

The goal is to understand this:

A token becomes meaningful to users when apps can connect it to metadata.

6. Middleware and business rules: Token-2022 extensions

In Web2, business rules usually live in your application.

If you want to charge a fee on every payment, you write that logic in your backend. If you want to prevent a user from transferring something, you add a rule to your application. If you want a balance to grow over time, you might run a scheduled job or calculate the value when the user views it.

That model works, but it depends on your application being the place where the rule is enforced.

Token-2022 changes that.

With Token-2022, some behaviors can be configured directly on the token mint itself. The rule is not just wrapped around the asset by your app. It becomes part of how the asset works.

For example, a token can be configured to:

charge a fee when it transfers
accrue interest in the displayed UI amount
refuse to transfer at all
require additional checks before movement

The Web2 bridge is middleware, but with an important twist.

In a web app, middleware sits in the request path. It runs because traffic passes through your server.

With Token-2022, the middleware-like behavior is inside the asset. The token program enforces it whenever the token is used.

A wallet cannot simply forget to apply the fee. A marketplace cannot route around the rule by calling a different endpoint. The behavior is configured on-chain and enforced by the token program.

Try it

Create a fee-bearing token

You’ll configure a Token-2022 mint with a transfer fee, send the token, and see that the rule is enforced by the token program rather than by application code.

As you work through it, answer three questions:

where is the fee configured?
what happens when the token is transferred?
who enforces the rule?

The key idea is:

Token-2022 lets you put certain business rules into the asset itself, not just into the app around it.

Submit this one if you want a good “aha” moment from the challenge. It is one of the clearest examples of Solana doing something differently from a traditional app stack.

7. Backend logic and tests: programs and Anchor

In Web2, your backend is where application logic usually lives.

It validates input, checks permissions, updates state, triggers side effects, and returns results. You might write tests to prove that the logic works and that failure cases are handled correctly.

On Solana, that logic lives in programs.

A program is deployed code that runs on-chain. Users and clients interact with it by sending transactions containing instructions.

Anchor is a framework that makes it easier to write Solana programs in Rust.

The rough Web2 bridge is backend logic deployed to a shared runtime. That comparison is not perfect, because Solana programs work with explicitly provided accounts rather than a private database connection. But it is close enough to help you begin.

With Anchor, you define:

the instructions your program supports
the accounts each instruction expects
the rules those accounts must satisfy
the handler logic that runs
tests that prove the behavior works

A simple counter program is a good starting point. It teaches the basic flow without too much business logic:

initialize a counter account
increment the counter
test that the value changed
test that invalid actions fail

That is where the Solana model starts to come together. Wallets sign transactions. Transactions contain instructions. Instructions call programs. Programs read and write accounts.

Try it

This one builds up over two short challenges.

First, build and test an Anchor counter program. You’ll scaffold the program, initialize a counter, increment it, and write tests that prove your on-chain logic behaves the way you expect.

Then make the tests earn their keep. You’ll add failure tests, then deliberately break the program and confirm the test suite catches it.

The goal is to understand this:

A Solana program is where your application logic runs, and Anchor gives you a practical structure for writing and testing it.

This is a strong challenge to submit because it shows real progress: you are no longer only using Solana from the outside. You are starting to write logic that runs on-chain.

Keep going with 100 Days of Solana

You do not need to understand all of Solana before you start building.

In fact, trying to learn everything upfront is usually the slowest path.

The faster route is to build small things that make each concept real:

create a wallet
send a transaction
inspect an account
mint a token
add metadata
try a Token-2022 extension
run an Anchor program

Each one gives you a piece of the model.

The challenges above are taken from 100 Days of Solana, a practical challenge series for developers who want to learn Solana by building.

Sounds good? Great, get started and learn Solana today >

Arc 8 Catch-Up: Middleware Inside the Token

Matthew Revell — Mon, 15 Jun 2026 15:16:14 +0000

Arc 8 of 100 Days of Solana was about Token-2022.

That might sound odd at first, because Token-2022 had already shown up in the previous arcs.

Arc 6 used token extensions to explore fees, interest, frozen accounts, and revocable credentials. Arc 7 used Token Extensions to build NFTs from the same token primitives.

Arc 8 made the model explicit.

The whole arc hangs off one idea:

Token extensions are like middleware that lives inside the asset.

For Web2 developers, that is the shift worth noticing.

In a normal app, rules usually sit around the asset. You write backend code. You add middleware. You call a payment processor. You run a cron job. You trust every integration to go through the right path.

With Token-2022, some of those rules can live on the mint itself.

That changes the shape of the system.

A token is no longer just a balance that moves between accounts. It can be a balance with transfer fees, interest display, transfer restrictions, or other behavior attached.

The middleware is not next to the token.

It is part of the token.

Token rules should not depend on every app remembering them

Most Web2 developers have built systems where rules sit outside the thing being moved.

A marketplace might charge a platform fee.

A fintech app might show yield.

A loyalty system might prevent points from being transferred.

A membership product might issue a badge that cannot be sold.

Usually, the rule lives somewhere in your application.

You might write:

calculateFee()
applyInterest()
rejectTransfer()
checkMembershipStatus()

That works as long as every relevant path uses the same logic.

But that is the weak point.

One backend service might apply the fee. Another script might forget it. An integration partner might call the wrong endpoint. An admin tool might bypass the normal flow. A scheduled job might fail. A frontend might display one thing while the ledger stores another.

Token-2022 takes a different approach.

When the extension is configured on the mint, the Token-2022 program enforces the behavior consistently. Every wallet, CLI, dApp, and program that interacts with the token has to deal with the same rule.

That is why the middleware analogy is useful, but only if you take it one step further.

This is not middleware sitting in your app stack.

It is middleware baked into the asset.

Transfer fees are enforced by the mint

Arc 8 started with a fee-bearing token.

The exercise was simple: create a mint under the Token-2022 program, add a transfer fee configuration, mint some supply, and inspect the result.

The important part was not the percentage.

It was where the rule lived.

The transfer fee was not a line of backend code. It was not a webhook. It was not a checkout rule. It was not a convention that wallets were expected to follow voluntarily.

The fee configuration lived on the mint.

That means the token itself carried the rule:

When this token moves, apply this fee.

For Web2 developers, the contrast is familiar.

If you charge a fee through Stripe, you usually build fee logic around the payment flow. You decide how much to collect, when to collect it, how to reconcile it, and which integrations are allowed to move value.

With Token-2022, the fee rule is part of the asset’s behavior. The transfer goes through the token program, and the token program applies the rule.

That is a meaningful difference.

You are not trusting every app to remember the fee. You are configuring a token that cannot move without the fee logic being considered.

That is the first big Arc 8 lesson:

The rule travels with the token.

The fee lifecycle is transfer, withhold, withdraw

Creating a fee-bearing mint is only the first part.

Arc 8 then put the token in motion and followed the fee lifecycle end to end:

transfer → withhold → withdraw

That lifecycle matters because transfer fees do not behave like a normal payment processor settlement flow.

When a fee-bearing token is transferred, the recipient does not simply receive the full amount and then send a fee somewhere else.

Instead, the fee is withheld in the recipient’s token account.

For example, with a 1% transfer fee, a transfer of 1,000 tokens gives the recipient 990 spendable tokens. The remaining 10 are recorded as withheld tokens on the recipient’s token account.

Those withheld tokens are not spendable by the recipient. They sit there until the withdraw authority collects them.

That is a very different mental model from a Web2 marketplace fee.

In a normal app, you might have a payment ledger, a treasury balance, a settlement job, a reconciliation process, and a dashboard showing fees owed.

Here, the withheld amount is visible in the token account itself. The fee authority can later withdraw it using the Token-2022 program.

The important thing is what you did not build.

No custom program.

No payment processor flow.

No webhook.

No cron job.

No separate fee table.

The protocol enforced the fee and stored the withheld amount.

That is the kind of concrete behavior that makes Token-2022 easier to understand. It is not an abstract extension system. It is a rule you can observe on devnet.

Composability means extensions share the same mint

Arc 8 then combined transfer fees with interest-bearing behavior.

This is where the middleware analogy becomes more powerful.

A token can have more than one rule.

The mint can say:

Charge a fee when tokens move.
Display balances with interest over time.

Those behaviors are different, but they can coexist on the same mint.

That matters because Web2 developers often expect separate systems for separate behaviors.

A fee might belong to a payments service.

Interest might belong to a financial calculation service.

Metadata might belong to an asset database.

Restrictions might belong to an access control system.

Token-2022 lets those behaviors be configured as extensions on one mint.

The technical reason is that extensions are stored as structured data on the account. The mint has enough space allocated for the extensions, and the Token-2022 program knows how to read and enforce them.

But the product lesson is simpler:

A token can be configured with multiple behaviors at once.

The fee and interest example also made an important distinction clear.

The transfer fee works on the raw token amount. It moves real token units and withholds part of the transfer.

Interest-bearing behavior affects the displayed amount. It does not continuously mint new tokens in the background. The raw balance does not change every second. The UI amount is computed from the stored amount, rate, and elapsed time.

That is why the two features can coexist cleanly.

The fee changes what happens during transfer.

The interest extension changes how the balance is interpreted when read.

Those are different layers of behavior on the same asset.

Interest is a view, not a background job

The interest-bearing extension is one of the easiest places for Web2 instincts to mislead you.

In a conventional app, if a balance grows, you usually assume something wrote a new value somewhere.

A scheduled job updated the balance.

A database row changed.

A ledger entry was added.

A batch process applied interest overnight.

Token-2022 does not need to work that way.

With the interest-bearing extension, the raw token amount stays the same unless an actual token instruction changes it. What changes is the displayed amount.

The program can calculate the UI amount based on the interest rate and time elapsed.

That is why Arc 8 deliberately used a high rate on devnet. At realistic rates, the change over a short challenge window would be too small to notice. A dramatic rate makes the model visible.

The lesson is not “high yield tokens are good.”

The lesson is:

Display can be computed from state without constantly rewriting state.

For Web2 developers, that is a useful mental shift.

The token account stores raw units. The extension changes how those units are displayed. If you assume “displayed balance increased” means “new tokens were minted,” you will misunderstand what the program is doing.

Arc 8 forced that distinction into the open.

Reading mint configuration is part of building

One of the most useful Arc 8 exercises was not creating another mint.

It was auditing the mints already created.

That matters because Token-2022 configuration is public state. You can inspect a mint and see which extensions it uses. You can read the fee configuration. You can see whether interest-bearing behavior exists. You can check whether a token is non-transferable.

That is the Solana version of inspecting a production schema.

In Web2, the rules of a system are often scattered across:

application code
database migrations
environment variables
payment processor settings
admin dashboards
scheduled jobs
private documentation

On Solana, much of the token’s behavior is visible in the mint account.

That does not mean the whole application is transparent. But it does mean the token’s configuration can be read by anyone.

That is part of the Token-2022 pitch.

The behavior is public.

The configuration is verifiable.

The rules cannot be silently swapped inside a private backend.

That is also why auditing matters.

You should not just create a mint and trust that you typed the command correctly. You should read it back. Check the extensions. Check the authorities. Check the raw configuration. Explain what each extension does in plain English.

That last part is important.

If you cannot describe the behavior without looking it up, you probably do not understand the asset yet.

Non-transferable tokens are useful because they fail

Arc 8 ended the build sequence with a token that refuses to move.

That might sound strange because tokens usually imply transferability. Money moves. Points move. Assets move.

But not every token-like thing should be transferable.

A course certificate should not be sellable.

A membership badge might need to stay with the person who earned it.

A compliance credential might need to remain attached to one wallet.

A proof-of-attendance token might lose meaning if it can be traded.

The non-transferable extension lets the mint encode that rule.

The challenge deliberately tried to break it. Create the token. Mint it. Create a recipient account. Attempt a transfer.

The transfer fails.

That failure is the feature.

In a Web2 app, you might prevent transferability through an API check:

if token.non_transferable:
    reject transfer

But that depends on every path using the same API.

With Token-2022, the token program itself rejects the transfer. The rule is part of the mint’s behavior, and any client interacting with the program has to respect it.

That makes non-transferable tokens different from fees and interest.

Fees and interest are still money-like features. They affect value movement and balance display.

Non-transferability changes the category of the asset. The token starts to look less like currency and more like identity, membership, status, or proof.

Same mint model. Same token accounts. Same CLI.

Different product meaning.

That is why the failed transfer matters so much. It proves the extension is not just descriptive metadata. It changes what the token can do.

Token-2022 is configuration, but not casual configuration

A tempting takeaway from Arc 8 would be:

Token-2022 lets you add features with flags.

That is true, but incomplete.

The better takeaway is:

Token-2022 lets you design token behavior through mint configuration.

That distinction matters.

Extensions feel easy because they can be created from the CLI. But they are not throwaway settings. They shape what the asset is, who can use it, and how every integration will experience it.

A fee-bearing token is different from a normal token.

An interest-bearing token is different from a normal token.

A non-transferable token is very different from a normal token.

Once those behaviors are on the mint, they are part of the asset’s design.

That brings Arc 8 back to the product questions underneath the technical work:

Should every transfer charge a fee?
Who can withdraw withheld fees?
Should balances display with interest?
Should this asset be transferable at all?
Which authorities control the rules?
Will wallets and integrations understand these extensions?

Those are not just CLI questions.

They are product, governance, and integration questions.

Token-2022 gives you reusable building blocks, but you still have to choose the right ones.

Writing turns extensions into patterns

Arc 8 ended by turning the week into a public post and social thread.

That fits the arc well because Token-2022 is easy to explain badly.

You can list extensions all day:

transfer fees
interest-bearing
non-transferable
default account state
permanent delegate
confidential transfers
memo transfer

But a list is not a mental model.

A useful post needs to show the pattern.

For Arc 8, the pattern was a trilogy:

A token that charges a fee.
A token that charges a fee and displays interest.
A token that refuses to move.

That is much more memorable than “I tried some Token-2022 extensions.”

It shows the range of what extensions can do.

One changes transfer economics.

One composes transfer economics with display behavior.

One changes whether transfer is allowed at all.

That is the story.

The best write-up would include what actually happened on devnet: the fee being withheld, the interest-adjusted UI amount changing without a transaction, and the failed transfer error from the non-transferable token.

Those details matter because they prove the learning.

Not:

“I learned Token-2022.”

More like:

“I created a token that charged a transfer fee, watched the fee sit as a withheld amount on the recipient account, stacked interest on the same mint, then built a token that refused to transfer at all.”

That is useful developer storytelling.

What Arc 8 sets up

Strip Arc 8 back to its core and the main ideas are clear:

Token-2022 lets token behavior live on the mint. Transfer fees are enforced by the token program. Fees follow a visible lifecycle: transfer, withhold, withdraw. Interest-bearing behavior changes displayed amounts without constantly rewriting raw balances. Extensions can compose on the same mint. Mint configuration is public and inspectable. Non-transferable tokens show that extensions are not only about money; they can turn tokens into identity, credential, or membership objects.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

Arc 7 showed that NFTs are built from the same token primitives.

Arc 8 pulled the model together: Token-2022 is the extension system that makes many of those behaviors possible without custom on-chain programs.

From here, the question becomes more practical:

How do you choose the right token behavior for the product you are building?

That is the mindset to carry forward.

Use this post as the map, revisit the Arc 8 challenges when you want the hands-on version, and remember the central lesson: with Token-2022, the rule does not sit beside the asset. The rule can live inside the asset.

Arc 7 Catch-Up: Building NFTs from First Principles

Matthew Revell — Mon, 15 Jun 2026 14:28:59 +0000

Arc 7 of 100 Days of Solana was about building NFTs from first principles.

Instead of starting with marketplaces, profile pictures, or NFT culture, the arc stripped the model back to the underlying token mechanics: supply, decimals, mint authority, metadata, collections, and provenance.

After Arc 6, we already knew that Token-2022 can turn tokens into programmable objects with rules: interest, fees, frozen accounts, credentials, revocation, and metadata.

Arc 7 took that model into NFTs.

But the useful surprise was that NFTs are not a completely separate world.

The whole arc hangs off one idea:

A Solana NFT is built from the same token primitives you already know.

For Web2 developers, that is the shift worth noticing.

An NFT is not magic. It is not “a JPEG on the blockchain.” It is not a special category of database record maintained by some mysterious NFT system.

At its simplest, an NFT is a token mint with:

supply locked at one
zero decimals
mint authority disabled
metadata attached
optional collection membership

That is the foundation Arc 7 built up, one layer at a time.

NFTs are not separate from tokens

Arc 7 started by stripping the NFT model down to its smallest useful form.

Before metadata, images, attributes, marketplaces, or collections, an NFT is just a token that cannot be split and cannot be duplicated.

That means two choices matter immediately:

decimals = 0
supply = 1

Zero decimals means the token cannot be divided into fractions. You cannot own 0.5 of it.

Supply of one means there is only one unit.

But supply of one is not enough by itself. If the mint authority still exists, someone could mint another unit later.

So the final step is to disable the mint authority.

That is the moment the token becomes meaningfully non-fungible. The network can see that the supply is one, the decimals are zero, and no authority remains that can create a second copy.

For Web2 developers, a useful comparison is a unique database row with a primary key.

But the analogy only goes so far.

In a normal database, the application owner can usually edit the row, clone it, delete it, or change the surrounding rules. On Solana, once the mint authority is disabled, the supply constraint is enforced by the token program.

The uniqueness is not a UI convention. It is not a marketplace promise. It is part of the token state.

Metadata turns a token into something recognizable

The first NFT in Arc 7 was intentionally plain.

It had no name, no image, no creator story, no attributes, and no collection. It was non-fungible, but not especially meaningful to a human.

That is where metadata comes in.

Arc 7 used Token-2022 metadata to give the NFT a name, symbol, and URI. The URI pointed to an off-chain JSON file containing richer information such as the description, image, and attributes.

That gives us a two-layer model:

On-chain:
mint, supply, decimals, authority, name, symbol, URI

Off-chain:
image, description, attributes, richer display data

That split matters.

The expensive, consensus-critical parts live on-chain. The heavier display information usually lives off-chain. Wallets and explorers follow the pointer: read the mint, get the URI, fetch the JSON, render the asset.

For Web2 developers, this is familiar once you stop treating the NFT as mysterious.

The on-chain metadata is like the core record. The URI is like a foreign key or external reference. The JSON is like the richer document the UI uses to render the page.

The important difference is that the ownership, supply, and core metadata live on a shared network rather than inside one application database.

Arc 7 also made an important historical point. In older Solana NFT workflows, metadata often lived in a separate Metaplex Token Metadata account next to the mint. In this arc, Token Extensions put metadata directly on the mint account itself.

That is why the exercise was useful. It showed the foundation before introducing convenience tooling.

An NFT collection is an on-chain relationship

Once the arc had created a single NFT, the next step was collections.

In Web2 terms, this is easy to understand.

A product belongs to a catalog.
A ticket belongs to an event.
A badge belongs to an award program.
A collectible belongs to a set.

In a database, you might model that with a foreign key:

nft.collection_id = collection.id

Arc 7 built the Solana equivalent using Token-2022 group and member extensions.

Strictly speaking, there are four related pieces:

GroupPointer, which points a collection mint at the account that stores group data
TokenGroup, which stores the group data itself
GroupMemberPointer, which points an NFT mint at the account that stores member data
TokenGroupMember, which stores the member’s group address and member number

In the arc, those pointers point back to the mint accounts themselves, so the group and member data live directly on the relevant mints.

That is why it is fair to talk about a collection mint and member mints, but the underlying model is a little more precise than “one group extension and one member extension.”

The collection mint represents the group. Each member NFT stores membership data that links it to that group.

The important part is that this relationship is not just a label in a marketplace database. It is data stored on-chain and readable by wallets, explorers, and programs.

The arc’s useful mental model was simple:

collection mint = the group
member mint = the individual NFT
member data = the link back to the group

That is the NFT version of a foreign key relationship.

But there is an extra trust step. A pointer by itself is not proof. A malicious mint can point at something it should not. So a client should not stop at “this member says it belongs to this collection.”

It needs to resolve the pointer and verify that the relationship is internally consistent.

That means checking that the member identifies the collection, and that the account being pointed to actually identifies the mint back.

And the creation step matters too. Initializing a group member is not just something any random token creator can do unilaterally. The collection’s authority has to authorize membership.

That is the stronger provenance claim: the collection relationship is not just stored on-chain; it is created through an authorized on-chain action.

As with Arc 6, the schema decisions matter. A mint must be created with the right extensions. You cannot casually retrofit yesterday’s NFT into a collection if it was not created with the member structure it needs.

That constraint can feel annoying, but it is also part of what makes the structure verifiable.

Provenance is something you can inspect

One of the most valuable Arc 7 exercises was not creating another asset.

It was auditing the collection.

That matters because NFT language often gets vague. Provenance, authenticity, ownership, rarity, official collections — these terms can become marketing fog very quickly.

Arc 7 made the idea concrete.

You inspect the collection mint.
You inspect the member NFT.
You check the member data.
You verify that the collection relationship resolves correctly.

That last step matters.

A one-way check is not enough. It is not sufficient to say:

This NFT points to collection C.

A safer check is closer to:

This NFT points to member data.
That member data names this NFT mint.
That member data names collection C.
The group data for collection C names collection C.
The membership was created under the collection’s authority.

That is what makes the relationship more than vibes.

The collection claim is not true merely because a website says so. It is not true merely because a field contains a familiar collection address. It is true when the on-chain relationship resolves correctly and the collection authority has authorized that membership.

For Web2 developers, this is like checking that a foreign key resolves correctly and that the row was created by a service with permission to write to that table.

The difference is that the database is public, shared, and inspectable by anyone.

That is a big part of the NFT value proposition when you remove the hype.

The asset can carry enough information for independent verification, but only if clients verify the relationship properly. Pointers are useful because they let accounts reference each other. They are dangerous if treated as proof on their own.

That is also why the CLI work matters.

It is tempting to think of NFTs through wallets, marketplaces, and images. But the more useful developer habit is to read the underlying state.

What is the supply?
What are the decimals?
Is the mint authority disabled?
Is metadata present?
What URI is stored?
Is there group member data?
Does it name the expected collection?
Does the pointed-to data name this mint back?
Was the membership authorized by the collection authority?

That is how NFTs stop feeling like magic.

Mutability is a design choice

Arc 7 then moved from creation to mutation.

Because the creator still held the metadata update authority, they could rename the NFT, add a custom field, remove that field, or point the URI at a new JSON file.

That is an important lesson because “on-chain” does not always mean “unchangeable.”

Some parts of the NFT were locked. The supply was one. The decimals were zero. The mint authority had been disabled.

But the metadata could still change while the update authority existed.

That is not automatically good or bad. It is a design choice.

A game asset might need metadata updates as it levels up.
A ticket might need status changes.
A credential might need expiry data.
A dynamic collectible might intentionally evolve over time.

But for other assets, mutability might undermine trust.

If someone buys an NFT because of its image, description, or attributes, they care about whether those things can change later. If a collection promises permanence, the update authority becomes part of the trust model.

Arc 7 also showed a practical split between on-chain and off-chain updates.

Changing the on-chain name or URI can happen quickly. Changing the image behind the URI depends on off-chain hosting and caching. Wallets and explorers may continue showing an old image for a while, even after the metadata has changed.

That is a useful reminder: NFTs are not purely on-chain objects.

They are hybrids.

The token, ownership, supply, and metadata pointer can live on-chain. The image and richer media often live somewhere else.

So the storage decision matters. A temporary GitHub Gist is fine for devnet learning. A serious project needs to think harder about durable storage: Arweave is designed for pay-once permanent storage, while IPFS content remains available only while someone continues to pin or serve it.

NFTs are records with ownership, display, and history

The practical Web2 bridge for Arc 7 was not “NFTs are images.”

A better bridge is:

NFTs are unique records with ownership, display metadata, and provenance.

That framing is much more useful.

A normal application might have unique records everywhere:

event tickets
certificates
software licenses
game items
collectible cards
access passes
membership badges
digital art editions
proof-of-attendance records

In Web2, those records usually live inside one company’s database. Ownership and transfer rules are whatever that application says they are.

On Solana, the unique record can be represented as a token mint. Ownership can be held by a wallet. Supply can be locked. Metadata can be attached. Collection membership can be verified.

That does not mean every unique record should be an NFT.

It does mean the NFT model is easier to reason about once you stop starting with the JPEG.

Start with the record.

Then ask:

Should this record be unique?
Should ownership be visible?
Should it be transferable?
Should it belong to a collection?
Should its metadata be mutable?
Should the media be permanent?
Who should hold the update authority?

Those are product questions, not just blockchain questions.

That is the thread connecting Arc 7 back to Arc 6.

Token design is product design. NFT design is product design too.

Writing forces the model to become simple

Arc 7 ended, like the earlier arcs, by writing and sharing.

That matters because NFTs are surrounded by baggage. People bring assumptions from marketplaces, profile pictures, speculation, scams, and culture wars.

A useful developer write-up has to cut through that.

The best post from this arc would not start with “NFTs are back” or “NFTs are dead.” It would explain what was actually built:

I created a token with supply 1 and zero decimals.
I disabled the mint authority.
I added metadata.
I pointed the metadata at a JSON file.
I created a collection mint.
I linked member NFTs to the collection.
I inspected the on-chain relationship.

That is enough.

The point is not to defend NFTs as a category. The point is to understand the technical model.

A good write-up might focus on one concrete surprise:

an NFT is just a token mint with specific constraints
metadata can live directly on the mint with Token Extensions
collection membership can be verified on-chain
provenance is an authorized relationship, not just a marketplace claim
metadata can be mutable if the update authority remains active
off-chain media is only as durable as the place it is hosted

That kind of explanation is useful because it gives the next Web2 developer a handle on the system.

Not hype.

A model.

What Arc 7 sets up

Strip Arc 7 back to its core and the main ideas are clear:

A Solana NFT is built from token primitives. Non-fungibility comes from zero decimals, supply of one, and disabled mint authority. Metadata makes the asset recognizable. Off-chain JSON gives wallets and explorers richer display information. Collections are on-chain relationships between group and member data. Provenance is stronger than a pointer: the member relationship must be authorized by the collection authority and verified in both directions so pointer spoofing does not masquerade as legitimacy. Metadata mutability depends on who controls the update authority.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

Arc 7 showed that NFTs are not a separate technology stack. They are the same token model, shaped into unique digital assets with metadata and provenance.

From here, the question becomes more practical:

How do these assets interact with real programs, wallets, apps, and users?

That is where the next arc can take the model beyond minting and inspection, and into more realistic application behavior.

Use this post as the map, revisit the Arc 7 challenges when you want the hands-on version, and carry the NFT mental model into what comes next.

Arc 6 Catch-Up: Designing Tokens That Enforce Rules

Matthew Revell — Mon, 15 Jun 2026 13:46:26 +0000

Arc 6 of 100 Days of Solana was about designing tokens that enforce rules.

Arc 5 introduced the basics: mints, token accounts, metadata, transfer fees, and non-transferable tokens. Arc 6 pushed that further by asking a more interesting question:

What if the token could carry more of the product logic itself?

That was the real theme of the week.

Using Token-2022 on devnet, we explored interest-bearing tokens, multi-extension mints, frozen accounts, revocable credentials, and the trade-offs that come with adding more behavior to an asset.

The whole arc hangs off one idea:

Token extensions let you compose asset behavior without writing your own on-chain program.

For Web2 developers, that is the shift worth noticing.

In a normal app, rules like interest, fees, access control, and revocation usually live in backend services, database jobs, middleware, or admin tooling.

With Token-2022, some of those rules can live in the token itself.

Extensions are asset features, not app features

Most Web2 products have some kind of internal value system.

A fintech app might offer yield. A marketplace might charge transaction fees. A learning platform might issue certificates. A SaaS product might gate access based on plan status. A compliance-heavy product might freeze or restrict accounts.

Normally, those rules live in the application.

Your backend calculates interest. Your payments layer applies fees. Your database stores membership status. Your admin dashboard revokes credentials. Your API checks whether a user is allowed to transfer, redeem, or access something.

Token extensions move some of that logic into shared token infrastructure.

That does not mean every app should become a token app. It means that, when a token is the right primitive, the rules do not have to be reinvented from scratch. You can use audited, reusable building blocks that every client and integration has to respect.

That is the big idea behind Token-2022.

The token is no longer just a number in a balance bucket. It can have behavior.

Interest-bearing tokens make display different from storage

Arc 6 started with the interest-bearing extension.

The exercise looked simple: create a token with a 5% interest rate, mint 1,000 tokens, then compare the raw balance with the displayed amount.

The surprising part is that the ledger balance does not keep changing in the background.

There is no cron job waking up every minute to update every account. There is no backend service recalculating balances and writing new rows. The token stores the rate and timing information. Readers calculate the interest-adjusted display amount when they need it.

In Web2 terms, it is like a savings account APY where the displayed balance can grow without the underlying ledger entry being rewritten constantly.

That is a subtle but important distinction.

The raw on-chain amount is still the raw amount. The interest-bearing extension changes how that amount is interpreted.

That is why the arc deliberately made the rate dramatic later. At 5%, the difference is easy to miss. At 150%, you can watch the displayed amount climb much faster and see the model more clearly.

The lesson was not “make wild APY tokens.” The lesson was:

Some token behavior is computed by readers, not stored as repeated balance updates.

That is a useful mental model to carry into more advanced token work.

Extensions can be composed

The next step was combining multiple extensions in one mint.

Arc 6 created a token with three behaviors:

metadata, so the token had a name, symbol, and URI
transfer fees, so transfers automatically withheld a percentage
interest, so displayed balances could grow over time

This is where Token-2022 starts to feel different from the original SPL Token Program.

You are not just creating a token and then building everything else around it. You are deciding which behaviors the token itself should support.

In Web2 terms, this is closer to designing the schema and rules for a financial product before launch. You decide what the product is allowed to do, what fields it needs, which authorities exist, and which operations should be enforced by the platform.

The important catch is that extensions are configured up front.

You cannot casually bolt them on later after the mint already exists. That makes token design feel more like database schema design or API contract design than UI configuration.

You should think before you mint.

The other lesson was that extensions operate independently. Transfer fee logic and interest logic can both exist on the same token, but they are not the same feature. One affects what happens during transfer. The other affects how balances are displayed over time.

Composability is powerful, but it does not remove the need to understand each part.

Access control can live at the token level

Arc 6 also introduced the default frozen account state.

That sounds abstract, but the product pattern is familiar.

Some assets should not be freely usable by default. Stablecoins, security tokens, regulated assets, compliance-gated products, and permissioned marketplaces all need some version of:

This account exists, but it is not allowed to move yet.

In Web2, that rule might live in your backend:

if user.kyc_status !== "approved":
    reject transfer

With a default-frozen Token-2022 mint, new token accounts start frozen. Transfers and mints fail until the right authority thaws the account.

That is a very different trust model.

You are not relying on every frontend, integration, script, or API route to remember the compliance check. The token program enforces the state. If the account is frozen, the transfer does not go through.

That was the core lesson of the frozen-account exercise: the failure is useful. It proves the rule is enforced below the application layer.

The pattern is not “add KYC UI.” The pattern is “make unauthorized movement impossible at the token level.”

Credentials need different rules from currencies

Arc 6 then moved from financial rules to identity and credentials.

The revocable credential token combined two extensions:

non-transferable, so the holder could not sell or transfer the credential
permanent delegate, so the issuer could burn it from the holder’s account if it needed to be revoked

That combination is a good example of why token design is not one-size-fits-all.

A currency wants liquidity. A marketplace asset may want fees. A certificate wants the opposite of transferability. Its value depends on being attached to the right holder.

A bootcamp certificate, professional license, compliance credential, or membership badge is only meaningful if the person who earned it is the person holding it.

So non-transferability makes sense.

But credentials also need revocation. A license can expire. A badge can be issued by mistake. A qualification can be withdrawn. A membership can be canceled.

That is where permanent delegate fits. It gives an authority the ability to burn from a holder’s account without needing that holder to sign the burn transaction.

That may sound harsh until you map it to Web2.

If your company issues a certificate, you probably expect the issuer to be able to revoke it. The difference is that, on Solana, that power is expressed through token behavior rather than a private database update.

This is where Arc 6 became less about “tokens as money” and more about “tokens as stateful credentials.”

Reading configurations matters as much as creating them

One of the most useful parts of the arc was not creating a new token at all.

It was inspecting the tokens we had already made.

Arc 6 asked us to compare the mints from the week and read their configurations back out: interest rate authority, transfer fee settings, metadata, freeze authority, default account state, data size, and rent-exempt cost.

That matters because on-chain configuration is not something you should treat as write-only.

If you are building seriously, you need to be able to answer:

Which extensions does this mint use?
Who controls the authorities?
Can those authorities change?
How large is the account?
How much rent-exempt balance does it need?
What rules will every holder be subject to?

That is the token equivalent of inspecting a production database schema or reviewing cloud infrastructure before launch.

You do not just create it and hope. You read it back. You compare it. You verify what the chain actually stores.

Arc 6 also made one trade-off visible: extensions are not free. More extensions mean more account data, and more account data means higher rent-exempt cost.

That is not necessarily a problem. It is just part of the design.

Token design is product design

The throughline of Arc 6 was judgment.

Interest-bearing tokens, transfer fees, frozen accounts, non-transferable credentials, and permanent delegates are all useful, but not universally useful.

Each one answers a different product question:

Should the displayed balance grow over time?
Should each transfer withhold a fee?
Should new accounts start locked?
Should this asset be transferable?
Should the issuer be able to revoke it?

Those are not just technical choices. They are product choices.

The mistake is to start with the extension and then hunt for a use case. The better move is to start with the product rule and ask whether a Token-2022 extension already enforces it.

That is why Arc 6 was a natural follow-up to Arc 5.

Arc 5 taught the basic token lifecycle. Arc 6 taught that token behavior can be composed.

Not every app needs custom program code immediately. Sometimes the right answer is to use the token program that already exists, configure it correctly, and understand the trade-offs.

Writing and sharing made the combinations clearer

Arc 6 ended by turning the week into a public explanation.

That matters because token extensions are easy to list but harder to understand in combination.

Writing forces the useful question:

Which extension combination solves which real product problem?

Interest alone is one pattern. Fees plus metadata is another. Default frozen accounts are a compliance pattern. Non-transferable plus permanent delegate is a credential pattern.

A good write-up does not need to explain every command. It needs to explain the shape:

Here is the Web2 problem.
Here is the token extension combination.
Here is what happened on devnet.
Here is what surprised me.
Here is where this pattern might fit.

That is how learning becomes useful to someone else.

The sharing prompt continued that idea: lead with the problem, show concrete takeaways, include the link, and use the community as a conversation rather than a broadcast channel.

That is especially important in an arc like this. The value is not just “I created another token.” It is “I matched a real-world rule to a token-level feature and proved it works.”

What Arc 6 sets up

Strip Arc 6 back to its core and the main ideas are clear:

Token-2022 extensions let you add behavior to tokens without writing custom on-chain program code. Interest can affect displayed balances without constantly rewriting ledger balances. Multiple extensions can live on one mint, but they must be planned up front. Frozen accounts support access control. Non-transferable tokens plus permanent delegates support revocable credentials. Reading token configuration back from the chain is part of building responsibly.

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior.

From here, the question becomes more practical:

How do these tokens interact with real programs on-chain?

That is where the next arc goes: taking the token model beyond the CLI and into program-driven interactions.

Use this post as the map, revisit the Arc 6 challenges when you want the hands-on version, and carry the extension model into what comes next.

Arc 5 Catch-Up: Solana Token Fundamentals Explained for Web2 Developers

Matthew Revell — Mon, 08 Jun 2026 12:21:27 +0000

Arc 5 of 100 Days of Solana opened Epoch 2 by moving from foundation work into programmable assets.

Epoch 1 gave us the basics: wallets, reads, transactions, accounts, and raw on-chain data. Arc 5 put those ideas to work on one of Solana’s most important primitives: tokens.

The arc theme was Token Fundamentals. The Web2 bridge was incentive systems: reward points, marketplace credits, loyalty balances, badges, fees, and transfer rules.

The whole arc hangs off one idea:

On Solana, a token is not just a balance. It is a set of rules enforced by a shared on-chain program.

That is the big shift for Web2 developers.

In a normal app, token-like systems often live in your database and your backend logic. You design tables, write endpoints, check permissions, prevent double-spends, calculate fees, and decide which transfers are allowed.

On Solana, much of that machinery already exists in audited token programs. Arc 5 was about learning to use those programs before trying to invent your own.

Tokens are incentive systems with stronger guarantees

If you have built Web2 products, you have probably seen token-like systems already.

A marketplace might have seller credits. A learning platform might have completion badges. A game might have in-app currency. A SaaS product might track usage credits. A community might issue reputation points or membership status.

Those systems usually depend on application code.

Your backend decides who has what. Your database stores the balances. Your API enforces the rules. If you want transfer fees, you write the fee logic. If you want a badge that cannot be transferred, you add checks in your application.

That works, but the rules live in your system.

Solana changes the shape of that design. With the SPL Token Program and Token-2022, many token rules can be enforced at the program level. That means clients, scripts, and other programs have to follow the same rules.

That is what made Arc 5 interesting. We were not just creating balances. We were exploring what happens when economic rules become part of the asset itself.

A mint defines the token

The first token in Arc 5 was deliberately simple.

Using the spl-token CLI on devnet, we created a token, created an account to hold it, minted 100 units, and inspected the result.

That sounds straightforward, but it introduces the most important token distinction:

A mint defines the token. A token account holds someone’s balance of that token.

If you are coming from Web2, the mint is a little like the currency definition or product catalog entry. It says what the token is: its supply, decimals, and mint authority.

A token account is more like an individual balance bucket. It says how many of that token a particular owner holds.

That distinction matters because you do not receive tokens directly “into a wallet” in the way newcomers often imagine. For each token type, a wallet needs a token account to hold that specific token.

A wallet is more like a filing cabinet. Each token account is a folder inside it.

That is the first Solana token model to carry forward:

Mint account: what the token is.
Token account: who holds how much of it.

Once that clicks, token balances stop feeling like magic.

Token-2022 makes the token itself more expressive

Arc 5 then moved from the original SPL Token Program to Token-2022, also known as the Token Extensions Program.

That distinction matters.

The original SPL Token Program gives you the classic token basics: create a mint, create token accounts, mint supply, transfer, burn, inspect balances.

Token-2022 keeps that familiar foundation but adds extensions: metadata, transfer fees, non-transferable tokens, and other features that would otherwise require more custom infrastructure.

In Arc 5, the first Token-2022 step was a branded token.

We created a mint with metadata enabled, set decimals, and wrote a name, symbol, and URI directly onto the mint.

That is important because metadata gives a token identity. Without it, a token is mostly an address and some numbers. With it, the token becomes recognizable: name, symbol, and a pointer to more information.

For Web2 developers, this is like moving from “database row with an ID” to “product with a name, SKU, description, and image.”

The technical difference is that the identity lives with the token infrastructure, not just in an off-chain app database.

Associated Token Accounts are the default balance bucket

Arc 5 also introduced Associated Token Accounts, or ATAs.

An ATA is a deterministic token account derived from a wallet address and a mint address. In plain English:

For this wallet and this token, there is a predictable default account that holds the balance.

That is useful because it avoids the chaos of every wallet having arbitrary token accounts everywhere.

In Web2 terms, imagine if every user/product pair had a predictable balance record:

balance = getBalance(userId, tokenId)

You do not have to guess where the balance should live. You can derive it.

That is why ATAs show up constantly in Solana token work. They are the standard place to look when asking:

How much of this token does this wallet hold?

Arc 5 used ATAs early because they are not an advanced detail. They are part of the everyday token model.

Transfer fees move marketplace logic into the token program

The most commercially familiar extension in Arc 5 was transfer fees.

In a Web2 marketplace, a payment or transaction fee usually lives in backend code. Someone transfers value, your system calculates a percentage, applies a cap, updates balances, and records the fee.

With Token-2022 transfer fees, that rule can live in the token itself.

In Arc 5, we created a token with a transfer fee. When tokens moved, a percentage was withheld automatically in the recipient’s token account. The recipient could not spend those withheld tokens. The fee authority could later collect them.

That is the important part:

The fee is enforced by the token program, not by a UI convention or backend middleware.

That changes the trust model. A different client, script, or integration cannot simply “forget” to charge the fee. The rule is part of the token’s transfer behavior.

There was also a very real developer gotcha: decimals.

Transfer fee maximums are specified in base units, not display units. If your token has decimals, the number you type may not mean what you think it means. That kind of detail bites everyone eventually, and Arc 5 surfaced it early.

The broader lesson is simple: token economics are product design, but the implementation is exact. Percentages, caps, decimals, authorities, and units all matter.

Non-transferable tokens are useful because they fail

Arc 5 also explored non-transferable tokens, sometimes described as soulbound tokens.

The exercise was intentionally odd: create a non-transferable token, mint it, then try to transfer it and watch the transfer fail.

That failure was the point.

A normal token is valuable partly because it can move. A non-transferable token is valuable because it cannot.

That makes sense for things like:

verified badges
course-completion certificates
membership credentials
KYC or compliance status
reputation markers

In those cases, transferability would undermine the meaning of the token. A certificate is not useful if someone else can buy it from you. A verified badge loses value if it can be traded.

The key lesson was that the restriction is enforced by the token program.

You are not relying on your frontend to hide a transfer button. You are not relying on an API route to reject the request. The token itself cannot be transferred under the rules of the program.

But it can still be burned.

That distinction matters. Non-transferable does not mean indestructible. It means the holder cannot transfer it to someone else. Burning still lets supply be reduced or credentials be revoked, depending on how the system is designed.

The lifecycle is the skill

Arc 5 was not only about individual token features. It also reinforced a repeatable lifecycle:

create → configure → mint → transfer → collect

That pattern showed up again and again.

Create the mint. Configure its rules. Create the account that will hold the token. Mint supply. Transfer some tokens. Inspect what happened. Collect withheld fees if the extension uses them.

That repetition matters because token work can feel fiddly at first.

There are mints and token accounts. Original SPL Token and Token-2022. Display units and base units. Metadata and authorities. Transfer fees and withheld balances. Non-transferable rules and burn behavior.

The way through that complexity is not to memorize every flag. It is to recognize the lifecycle.

Once you can see where you are in the lifecycle, the commands start to make more sense.

Building in public is part of the work

Arc 5 ended, like the earlier arcs, by writing and sharing.

But this week had more to show.

By the end of the arc, we had created tokens, branded them, minted supply, applied fees, collected withheld tokens, and tested transfer restrictions. That is a proper artifact, not just a learning note.

The writing prompt asked us to explain what clicked: why Token-2022 matters, why protocol-enforced rules are different from app-level checks, and what surprised us about token design.

The sharing prompt pushed us to show one concrete moment: the first mint, metadata on Explorer, fees collected by the program, or a rejected non-transferable transfer.

That is good developer storytelling because it gives people proof.

Not “I learned tokens.”

More like:

I created a Token-2022 mint with metadata.
I transferred it.
The program withheld the fee.
Here is the Explorer screenshot.
Here is what surprised me.

That is much more useful to the next person trying to understand the same thing.

What Arc 5 sets up

Strip Arc 5 back to its core and the main ideas are clear:

A mint defines a token. Token accounts hold balances. Associated Token Accounts give wallets a predictable balance account for each token. Token-2022 adds extensions such as metadata, transfer fees, and non-transferable behavior. Those extensions move rules that often live in Web2 backend code into shared on-chain programs.

That is the real shift.

In Web2, token-like systems often depend on your app enforcing the rules.

On Solana, token programs can enforce many of those rules directly.

That is what makes tokens such a useful first step after the foundation epoch. They take identity, accounts, transactions, and state, then combine them into something you can actually design with: incentives, fees, credentials, rewards, and asset behavior.

Arc 5 opened Epoch 2 by showing that tokens are not just things you hold. They are programmable assets with rules.

Use this post as the map, revisit the Arc 5 challenges when you want the hands-on version, and carry the token model into the next arc.

Arc 4 Catch-Up: Solana’s Account Model Explained for Web2 Developer

Matthew Revell — Mon, 08 Jun 2026 12:06:13 +0000

Arc 4 of 100 Days of Solana was about the Solana account model: what state actually looks like on-chain, who can change it, and how developers read and decode it.

Arc 3 gave us the transaction model. We learned that transactions are how Solana changes state.

Arc 4 asked the next question:

Where does that state live?

On Solana, the answer is accounts.

That sounds simple, but it is one of the biggest mental model shifts in the whole foundation epoch. A Solana account is not just a wallet. It is not just a user profile. It is not just a row in a database.

On Solana, almost everything is an account: wallets, programs, token mints, token accounts, sysvars, and application state.

The whole arc hangs off one idea:

On Solana, accounts are the containers that hold state, code, ownership, and balance.

Once that clicks, the rest of Solana starts to fit together.

Accounts are where state lives

In a Web2 app, state usually lives in places you control.

User data might be in Postgres. Files might be in object storage. sessions might be in Redis. App code runs on your servers or serverless functions. Access control often lives in middleware, business logic, row-level security, or API permissions.

Solana rearranges that picture.

State lives in accounts. Programs are accounts too. Wallets are accounts. Token data is stored in accounts. Even bits of cluster state are exposed through special accounts.

That is what people mean when they say “everything is an account.”

It does not mean every account behaves the same way. A wallet account, a token mint, and an executable program account do different jobs. But they share the same basic structure, and that shared structure is what Arc 4 unpacked.

A Solana account has five core fields:

lamports: how much SOL the account holds
data: the bytes stored in the account
owner: the program allowed to modify the account’s data
executable: whether the account contains runnable program code
rentEpoch: a legacy rent-related field

That is the foundation. Different accounts become meaningful because those fields are set differently.

The owner field is the security model

For Web2 developers, the owner field is one of the most important ideas to get right.

It does not mean “the human who owns this account.”

It means:

Which program is allowed to change this account’s data?

That makes owner much closer to a low-level access-control rule than a user-facing ownership label.

In a Web2 app, you might enforce permissions in your API layer:

Can this user update this row?
Can this service write to this bucket?
Can this job mutate this record?

On Solana, the runtime enforces a stricter version of that idea. Only the owning program can modify an account’s data. If a token account is owned by the Token Program, your random application code cannot just rewrite it. If your program owns a data account, then your program defines how that data can change.

That is why the account model matters so much.

Transactions may carry the instructions, but accounts define the state those instructions act on. The owner field helps decide which program has authority over that state.

That is not middleware. It is part of the runtime.

Programs are accounts too

One of the more useful realizations in Arc 4 was that programs are not magical things floating somewhere outside the account model.

Programs are accounts.

The difference is that program accounts have executable: true. Their data contains compiled program code, and their owner is a loader program rather than the System Program.

That is a strange idea at first, but there is a useful Web2 analogy:

The code and the data are separate.

A web server might run application code, then read and write rows in a database. On Solana, a program account contains executable code, while separate data accounts hold the state that program works with.

That separation becomes crucial later.

When you write Solana programs, you are not usually storing mutable state inside the program itself. You are writing code that receives accounts, checks them, reads their data, and changes the accounts it is allowed to change.

So Arc 4 quietly set up one of the most important Solana development habits:

Think in accounts, not objects.

Your program logic is only half the story. The accounts passed into that program are the other half.

Reading an account is like opening a file

Arc 4 started with inspection.

Using the Solana CLI, we looked at a normal wallet account, the SPL Token Program, and the System Program side by side. That made the shared structure visible.

The Web2 analogy here is not perfect, but it helps:

Reading a Solana account is a bit like opening a file or inspecting a database row.

You can see its balance. You can see whether it has data. You can see who owns it. You can see whether it is executable.

But unlike a normal database row, account data often starts as raw bytes. The network can give you the bytes, but it does not automatically know how you want to interpret them.

That is where account decoding comes in.

Raw bytes are where this gets real

Arc 4 was the most “under the hood” week of Epoch 1, and the account decoding work was the reason.

At first, an account’s data field can look like base64 gibberish. That is not because it is meaningless. It is because you are looking at serialized bytes.

The challenge was to decode those bytes and prove that the same account data could be understood in three ways:

with a typed decoder from @solana-program/token
manually, byte by byte, using DataView
through the RPC’s jsonParsed encoding

That is not just busywork. It is the moment where “on-chain data” stops being abstract.

If you have ever parsed a binary file format, decoded a network packet, or mapped bytes into a struct, this is the same kind of work. The data is there. Your job is to know its layout.

Arc 4 introduced several ideas that will keep coming back:

Borsh serialization: how structured data becomes bytes
little-endian numbers: a common source of decoding bugs
base64: how RPC often returns account data
hex: useful for debugging raw bytes
base58: how Solana addresses are displayed

This was the hardest part of the arc, but it was also the most transferable.

If you can decode account data, you are no longer limited to what a block explorer chooses to show you. You can inspect state yourself.

The System Program is the account clerk

Arc 4 also took us one layer deeper into the system itself.

The System Program is one of the native programs that makes Solana work. A useful way to think about it is as the clerk that creates and labels accounts.

It can create accounts. It can assign ownership. It can allocate space. It handles basic SOL transfers.

That makes it feel a little like part of an operating system. Not your application logic, but the lower-level machinery that makes files, processes, permissions, and memory possible.

Sysvar accounts are another useful piece of that system layer. They expose read-only cluster state, such as clock or rent information, through accounts.

A rough Web2 analogy would be /proc on Linux: system information exposed as readable data.

Again, the analogy is not exact. But it helps place the idea. Solana’s account model is not only for application state. It is also how the system exposes information about itself.

Block explorers are blockchain DevTools

After decoding account data by hand, Arc 4 stepped back and looked at Explorer again.

That was useful because block explorers are not just places to paste transaction signatures. They are the debugging surface for a public blockchain.

Solana Explorer, Solscan, and similar tools are basically UI wrappers around public chain data. They show accounts, transactions, owners, program logs, balances, token data, and instruction details.

If you are used to browser DevTools, database consoles, or log dashboards, this is the role explorers play.

They help you answer questions like:

What account am I looking at?
Who owns it?
Is it executable?
What data does it hold?
Which transaction changed it?
What logs were emitted?

Reading explorers fluently is a real Solana development skill. It lets you move between your code, RPC calls, transaction signatures, and on-chain state without guessing.

Arc 4 made that explicit.

Writing helps the model settle

Arc 4 ended the same way the earlier arcs did: by writing and sharing.

That matters especially for this arc because the account model is not something you fully absorb by reading one definition. It takes a few passes.

You inspect an account. You compare it with another one. You decode bytes. You look at a program. You notice that the same five fields keep showing up. Then you try to explain it to someone else.

That is when the model starts to stick.

Writing about the account model forces useful questions:

What does owner really mean?
How is a program also an account?
Where does state live?
Why is account data raw bytes?
What does rent-exempt storage mean?

Those questions are exactly the point.

The goal is not polished certainty. The goal is a clearer map.

What Arc 4 sets up

Arc 4 closed Epoch 1 by giving us the data model underneath everything else.

Strip it back to the core ideas:

Accounts are where Solana state lives. Every account has the same basic fields. The owner field controls who can change account data. Programs are executable accounts. Application state lives in separate data accounts. Raw account data is bytes, and decoding those bytes is a core developer skill.

That brings the foundation epoch together.

Arc 1 gave us identity: keys, wallets, addresses, and devnet SOL.

Arc 2 gave us reads: RPC calls, balances, transaction history, and public blockchain data.

Arc 3 gave us writes: signed transactions, confirmation, and failure modes.

Arc 4 gave us state: accounts, ownership, executable programs, raw data, and decoding.

From here, the next step is natural.

Once you understand identity, reads, writes, and state, you are ready to build with the programs that own and modify those accounts.

Use this post as the map, revisit the Arc 4 challenges when you want the hands-on version, and carry the account model into what comes next.

Arc 2 Catch-Up: Reading Solana Like a Public Database

Matthew Revell — Mon, 08 Jun 2026 11:59:40 +0000

Arc 2 of 100 Days of Solana was about learning to read from the blockchain.

In Arc 1, we created wallets, worked with addresses, got devnet SOL, and started building the basic identity layer we need to interact with Solana. Arc 2 shifted the focus from identity to information.

What can you read from Solana? How do you ask for it? What comes back? And how is that different from fetching data from a normal Web2 API or querying a database?

The whole arc hangs off one useful mental model:

Solana is a massive public database where every table is readable and every query is free.

That is not a perfect technical description, but it is a useful starting point. If you are coming from Web2, Arc 2 is where Solana starts to feel less like an abstract blockchain and more like a data source you can inspect, query, and build interfaces around.

Reading from Solana feels familiar

Reading from Solana is the easy part to map onto Web2.

You ask for a wallet balance. You fetch recent transactions for an address. You inspect account data. The network answers.

That shape feels familiar if you have ever called a REST API, queried a database, or built a dashboard around backend data.

In Arc 2, the first read was deliberately small: use @solana/kit, connect to devnet, and call getBalance for a wallet address.

That one call teaches more than it first appears to.

There is no user session. No API key. No private dashboard. No auth header. The address is public, the balance is public, and the network can return it directly.

That is the first shift:

On Solana, public data is public by default.

For Web2 developers, that can feel backwards. In most application databases, data starts private. You expose it through APIs, auth rules, dashboards, and permissions. On Solana, a lot of the base data is already out in the open. The job of your application is often not to unlock access, but to make public data understandable and useful.

A wallet balance is just the first query

Once you can fetch a balance, the next step is obvious: fetch activity.

Arc 2 moved from getBalance to recent transaction history. Using getSignaturesForAddress, we queried the most recent transactions for an address and displayed the signature, slot, timestamp, and status.

If getBalance is like:

GET /users/:id/balance

then recent transactions feel more like:

GET /users/:id/transactions

The pattern is familiar. The data is not.

A transaction signature is not just a random ID. It is the identifier you can use to look up what happened. A slot is not quite a timestamp; it is Solana’s way of ordering batches of work over time. A block time gives you a familiar Unix timestamp when one is available.

This is where Solana starts to feel like a database with its own vocabulary.

You can query it. You can display the result. You can build UI around it. But the records you get back are blockchain records, not rows from your own application database.

That distinction matters.

You are not asking your backend, “What did this user do in my app?” You are asking the network, “What activity is visible for this address?”

A dashboard turns reads into something useful

The first two reads happened in scripts. That is a good way to learn the API, but it is not how most users experience software.

So Arc 2 moved the same read patterns into a small browser dashboard.

The dashboard took an address, fetched its balance, pulled recent transactions, and displayed the results in a simple web interface. Same Solana calls. Different surface.

That is a useful moment because it shows how normal this can feel.

You are still doing familiar frontend work: input fields, loading states, error handling, formatted output. The Solana-specific part is the data source.

A read-only dashboard is also a good early blockchain app because the risk is low. You are not signing anything. You are not moving funds. You are not changing state. You are just helping someone understand public data.

That makes Arc 2 a good bridge for Web2 developers. You can use existing frontend instincts while slowly replacing “my backend API” with “the Solana RPC endpoint.”

Accounts are not tables, but the database analogy helps

The conceptual center of Arc 2 was the comparison between Solana accounts and Web2 databases.

The database analogy helps because it gives you a place to start. Solana stores state. You can read that state. Programs interact with that state. Accounts have owners. Data has structure.

But the analogy breaks quickly.

In a normal database, you might expect tables, schemas, indexes, joins, private rows, server-side filtering, and application middleware enforcing access control.

Solana does not work like that.

On Solana, everything is an account: wallets, programs, token accounts, program-owned data. Accounts do not query each other. There are no joins. You usually assemble what you need off-chain by making RPC calls, reading account data, and interpreting the results in your app.

That is a major shift.

In Web2, the database often sits behind your application. Your server decides what to query, what to hide, what to join, and what to return.

On Solana, the data is public, the runtime enforces ownership and write rules, and your application often becomes the layer that makes raw public state usable.

That is why “Solana is a public database” is helpful, but incomplete. It is not Postgres with a blockchain logo. It is a shared state layer with different rules about visibility, ownership, storage, and writes.

Storage has a price tag

Arc 2 also introduced a detail Web2 developers do not usually think about directly: storage cost.

In most Web2 apps, storage cost is real, but abstracted. You pay a cloud bill. Your database grows. Maybe you worry about indexes, backups, or object storage. But individual records do not usually arrive with an obvious upfront storage deposit.

Solana makes storage more explicit.

Accounts need enough lamports to be rent-exempt. That deposit depends on the amount of data the account stores, and it can be returned if the account is closed.

That is a very different mental model from “just insert another row.”

It means storage is not just a backend implementation detail. It is part of the application model. If your app needs on-chain state, someone has to pay for the account space that holds it.

Arc 2 did not require us to build with that model yet, but it planted the idea early: on Solana, reading is free, but storing state is not invisible.

Devnet and mainnet are separate worlds

Arc 2 also made the network environment visible.

In Web2, developers are used to staging and production. Same code, different database. Same API shape, different base URL. Different data, different risk.

Solana has a similar idea with devnet and mainnet.

The RPC calls can look identical. The address can be the same. But the network you query changes everything.

A wallet might have devnet SOL and no mainnet SOL. It might have activity on one network and no history on the other. Devnet is not a sandboxed view of mainnet. It is a separate environment with separate data.

That is a useful Web2 bridge:

Changing networks is like pointing the same app at a different database.

The code shape stays familiar. The data source changes. The consequences change too.

Devnet is where you can experiment freely. Mainnet is where the real assets and real history live.

Writing turns learning into understanding

Arc 2 ended by stepping away from the code and asking us to explain what we had learned.

That was not filler. Writing is part of the learning loop.

When you try to explain Solana accounts, RPC calls, devnet, public data, or transaction history to someone else, you quickly find the gaps in your own understanding. The rough edges become visible. The parts that felt “sort of clear” either sharpen or fall apart.

That is valuable.

A good technical learning journey is not just:

read docs → copy code → move on

It is closer to:

try something → build something → explain it → share it → notice what still feels unclear

Arc 2 followed that pattern. We read on-chain data, turned it into a browser dashboard, compared it against Web2 databases, wrote about what clicked, and shared the work publicly.

That turns a week of exercises into something more durable.

What Arc 2 sets up

Strip Arc 2 back to its core and the main ideas are clear:

Solana data is public by default. You read it through RPC calls. Wallet balances, transaction history, programs, and data all live in accounts. Devnet and mainnet are separate environments. Reading is free, but storing state has a cost.

That gives us the bridge into Arc 3.

Once you understand how to read from Solana, the next question is obvious:

How do you change it?

On Solana, the answer is transactions.

Arc 3 picks up there: signed requests to change on-chain state, SOL transfers, transaction anatomy, confirmation, failure modes, and the write path developers use to interact with the network.

Use this post as the map, revisit the Arc 2 challenges when you want the hands-on version, and jump into Arc 3 with the read model already in place.