DEV Community: 100 Days of Solana

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

From Devnet to Mainnet: What Changes When Your Solana Program Goes Live

Vincent Jande — Fri, 10 Jul 2026 21:46:13 +0000

There's a moment in every Solana project where the work stops being about whether the program works and starts being about whether it's ready. You've tested it, the logic holds, the constraints are tight. Then you point it at mainnet, and a different set of questions shows up: questions about money, permanence, and strangers.

This post is about that transition. Not the commands, which are short and well documented, but the shift in what you're responsible for once real users can touch your code. If you've been building on devnet and you're starting to think about a live launch, this is the mental model to carry in.

Devnet was a sandbox. Mainnet is not.

Devnet is a practice field. The SOL is free, you airdrop more whenever you run low, and if you deploy something broken, the only casualty is your afternoon. That safety is the whole point of devnet: it lets you fail cheaply and often, which is exactly how you should be learning.

Mainnet removes the safety net, and three things change the moment you cross over.

The SOL is real. Deploying a program allocates an on-chain account sized to your compiled binary, and you pay rent for that space in actual SOL. Larger programs cost more. This isn't a huge sum for a typical program, but it's real money leaving a real wallet, and that alone tends to sharpen how carefully you check things before you hit deploy.

The audience is real. On devnet the only person calling your program is you. On mainnet, anyone can find your program and send it any transaction they like, the moment it's live. Everything from the security arc stops being theoretical: the accounts strangers pass in, the inputs you didn't expect, the edge cases you hoped no one would hit. Mainnet is where "every account is attacker-controlled until proven otherwise" becomes a live condition rather than a lesson.

The mistakes are visible. A bad devnet deploy disappears into the noise. A bad mainnet deploy is a public event, on a permanent ledger, in front of the users you were hoping to attract. This is a feature as much as a risk: the same permanence that raises the stakes is what lets users trust the program without trusting you personally.

None of this should scare you off. It's just the difference between a rehearsal and opening night, and the way you prepare for opening night is by knowing which decisions are reversible and which are not.

The one-way door: upgrade authority

Here's the single most important concept to understand before you launch, because it's the one decision on Solana that you genuinely cannot take back.

When you deploy a program, your wallet becomes its upgrade authority. That's the key that lets you push new versions of the program later, fixing bugs, adding features, changing logic. As long as you hold the upgrade authority, your deployed program is mutable: you can replace its code.

That power cuts both ways, and it's the central tension of shipping on Solana:

If you keep the upgrade authority, you can fix bugs after launch, which is a real safety valve. But your users have to trust that you won't push a malicious update that drains them. An upgradeable program is only as trustworthy as whoever holds its authority.

If you revoke the upgrade authority, the program becomes immutable and can never be changed again. Users get maximum trust, the code is the code, forever, but you've also given up your ability to patch a bug you discover next week. Revoking is permanent: there is no undo, no recovery, no support ticket that brings it back.

This is why teams rarely treat it as a binary. Many keep the authority early, when bugs are most likely, then move it to a multisig so no single person can push an update alone, and only consider full immutability once the program has been battle-tested and audited. The point isn't which choice is correct, it's that you make it deliberately, understanding that revocation is a door that only opens one way.

You can always check who holds a program's authority, which matters because it's also how you evaluate anyone else's program before trusting it with your funds.

Your program is now a public API

On devnet your program was a thing you called from your own test file. On mainnet it becomes infrastructure that other people's code talks to, and that reframes a few things worth previewing.

Other developers need to know how to call your program. The typed interface that describes your instructions and accounts, the IDL, becomes a public contract. Publishing it lets others generate clients and build on top of you, the same way a REST API publishes its schema. Your program stops being private code and becomes something composable.

Real users connect through wallets, not keypairs in a file. On devnet you signed with a local keypair. Real users have browser wallets, and connecting to them means speaking a shared standard so any wallet works, not just the one you happen to use. The interface between your app and a stranger's wallet is now part of your product.

Users see errors you didn't write. When a transaction fails on mainnet, the user doesn't see your clean require! message, they might see a raw RPC error, a rejected signature, an insufficient-funds failure. Part of shipping is catching those and turning them into something a human can understand, so a failed transaction is a clear message rather than a scary wall of text. The difference between a program and a product is often just this layer of care.

The mindset to carry in

The whole shift can be summed up in one sentence: on devnet you were proving the program works, and on mainnet you're taking responsibility for it in the world.

That responsibility is mostly about knowing which decisions are reversible. Deploying is reversible, you can upgrade, redeploy, or close and reclaim your SOL while you hold the authority. Revoking the upgrade authority is not reversible. Neither is the ledger's memory of a launch. So the craft of shipping is sequencing: do the reversible things freely, approach the irreversible ones slowly, and never let a permanent decision be the one you made in a hurry.

A short version of what "ready" looks like:

Your program does what it should, and refuses what it shouldn't, because mainnet is where the second half gets tested by strangers.
You've decided, on purpose, what happens to your upgrade authority, and when.
The people who'll build on or use your program can actually reach it: a published interface, a wallet connection, and errors that make sense.
You know which of your launch steps you can undo and which you can't.

Deployment feels like the finish line, but it's better to think of it as the handoff, the moment your program stops being yours alone and starts being something the world can use. Everything up to now was making it correct. Shipping is making it ready.

Going further

The Solana program deployment docs cover the actual commands for deploying, transferring the upgrade authority, and making a program immutable, including how to check who currently holds authority over any program. The program deployment overview explains the upgrade mechanism itself: buffer accounts, the program data account, and what setting the authority to None does. For the client side, Codama's client generation docs walk through turning a program's IDL into a typed client others can build with.

If you're doing 100 Days of Solana, the next arc walks this exact path end to end: promoting a program to mainnet, handling the upgrade-authority decision, publishing a client, wiring up a wallet, and launching with on-chain proof. Reading this first means the stakes will already make sense when you get there. Not joined yet? It's not too late to build alongside everyone: mlh.link/solana-100.

Account Security on Solana, Made Simple

Vincent Jande — Fri, 03 Jul 2026 20:21:08 +0000

When you write a normal backend, you mostly trust your own database. A row you wrote is a row you can read back, and the data is what you put there. Solana works differently, and the difference is the single most important thing to understand about writing safe programs.

On Solana, your program is handed a list of accounts with every instruction, and any of those accounts can be anything the caller wants. The caller picks them. An account is just an address, a balance, some bytes, and a field saying which program owns it, and a caller is free to hand your program an account they built themselves, filled with whatever bytes serve them. Your program has no trusted edge. Every account is attacker-controlled until your code proves otherwise.

That sounds alarming, but it collapses into something manageable. Most account security on Solana comes down to two questions you ask about every account in every instruction. Learn to ask them and a whole class of expensive bugs stops being mysterious.

The shift: from "what did I mean" to "what did I forget to forbid"

When you're building a feature, you think about the happy path: a user calls this, the program does that, everyone's content. Security asks a different question. Not "what did I intend this to do," but "what did I forget to forbid." Those are not the same question, and the gap between them is where exploits live.

A useful way to hold it: when you write a program, you imagine the user you designed for. An attacker is every user you didn't. They will pass the account you didn't expect, sign with a key you didn't intend, and send the number you assumed no one would. Your job is to make the program say no to all of them, out loud, before it touches anything.

The good news is you don't need to imagine every attack. Two questions cover most of the ground.

Question one: who owns this account?

If your program reads data off an account and trusts it, the program needs to know which program owns that account.

Here's why it matters. Say your program has a Config account that stores an admin's public key, and your withdraw logic reads config.admin to decide who's allowed. If you read those bytes without checking who owns the account, an attacker can create their own account, write a Config into it that names themselves as admin, and hand it to your program. The bytes deserialize perfectly. The struct says what they want it to say. Your check passes, and they walk out with the funds.

The defense is an owner check: confirm the account is owned by the program that's supposed to own it. A real Config your program created is owned by your program. The attacker's forgery is owned by the System Program (or whatever they chose), so an owner check rejects it on sight.

This exact gap, an account trusted without verifying what it was, is behind some of the largest losses in Solana's history. It isn't exotic cryptography. It's a missing question.

Question two: did the authority actually sign?

The second question is about permission. If an account decides whether an action is allowed, an account named authority or admin or owner, the program has to confirm that account actually signed the transaction.

The trap here is subtle and worth slowing down for. It's tempting to check authority by comparing public keys: "does the admin field on this account equal the admin pubkey I expect?" But a public key is public. Anyone can put anyone's pubkey in a transaction. Comparing pubkeys only proves that someone knew a public key, which is no proof at all, since they're visible on chain to everyone.

What you actually need to know is that the holder of the matching private key approved this transaction. That's what a signature proves and a pubkey comparison doesn't. So the rule is: an authority must sign, not just match. Checking the pubkey without checking the signature is the precise mistake behind one of the most famous bridge exploits, where the program compared an account but never confirmed it had signed.

How Anchor answers both questions for you

If you're using Anchor, the reassuring part is that the account types answer these questions automatically. You often get the checks for free, as long as you reach for the right type.

Account<'info, T> answers the owner question. When you type an account as Account<'info, Config>, Anchor verifies the account is owned by your program and that its first eight bytes match the Config type's discriminator, before your handler runs. The forged account from question one never makes it through.

Signer<'info> answers the signer question. Typing an account as Signer<'info> makes Anchor confirm it actually signed the transaction. No pubkey-comparison trap, because you're checking the signature itself.

#[derive(Accounts)]
pub struct Withdraw<'info> {
    // owner + discriminator checked automatically
    pub config: Account<'info, Config>,
    // signature checked automatically
    pub authority: Signer<'info>,
}

The danger lives in the escape hatch. When you reach for UncheckedAccount<'info> or AccountInfo<'info>, Anchor checks nothing: no owner, no signer, no type. Sometimes you need that, but every time you use it you've quietly promised to do the validation by hand. Anchor even makes you write a /// CHECK: comment above it to acknowledge the promise. The bugs tend to be the moments someone reached for an unchecked account to make something compile, then forgot they'd taken on that promise.

So a lot of Anchor security is simply: use the typed account instead of the raw one, and let the framework ask the two questions for you.

Binding accounts together: the constraints

The types answer "is this a real account my program owns" and "did this account sign." One question they can't answer on their own is whether two accounts belong together. Does this config belong to this authority? For that, Anchor gives you constraints that live right on the account.

#[derive(Accounts)]
pub struct Withdraw<'info> {
    pub authority: Signer<'info>,
    #[account(
        mut,
        has_one = authority,
    )]
    pub config: Account<'info, Config>,
}

has_one = authority checks that the authority field stored inside config equals the authority account that signed. It binds the on-chain record to the live signer, so a valid signer can't operate on a config that isn't theirs. There are more of these (seeds/bump to confirm a PDA, address to pin an exact key, constraint for any boolean you like), but they all share one idea: declare the rule next to the account, and the runtime enforces it before your handler runs. A rule on the struct can't be forgotten in a refactor the way a check buried in handler logic can.

The mental model to carry in

Here's the whole thing in one frame. A Web2 API often validates once at the edge and trusts the request afterward. A Solana program has no edge. Every account on every instruction is untrusted input, every time. Security is the practice of declaring your assumptions in a place the runtime checks them, so the program refuses bad input by construction rather than by you remembering to write an if.

When you read an instruction with that lens, the checklist is short:

For every account whose data you trust, ask: is its owner verified? (Account<'info, T> does this.)
For every account that authorizes an action, ask: did it actually sign? (Signer<'info> does this.)
For accounts that must belong together, ask: are they bound? (has_one, seeds, constraint.)
For every UncheckedAccount, ask: did I really mean to skip all of that, and did I validate it by hand?

That's most of account security, and none of it is clever. It's a posture: assume nothing the caller hands you is what it claims, and make the program prove each piece before it acts.

Going further

The Anchor account types reference documents exactly what each type checks, and the account constraints reference lists has_one, seeds, address, constraint, and the rest. For the attack patterns these defend against, coral-xyz/sealevel-attacks pairs a deliberately vulnerable program with its Anchor fix for each common exploit class, owner checks, signer checks, account substitution, and more. It's the clearest way to see each mistake and its correction side by side.

If you're doing 100 Days of Solana, the next arc turns this posture into practice: you'll audit a program for these exact gaps, close them with constraints, and write tests that prove the locks hold. Reading this first means the two questions will already feel like second nature. Not joined yet? It's not too late to build alongside everyone: mlh.link/solana-100.

Cross-Program Invocations: How One Solana Program Calls Another

Vincent Jande — Fri, 26 Jun 2026 16:00:33 +0000

Last time we ended on a promise. A Program Derived Address has no private key, so no human can sign for it, yet a program still needs to move tokens out of a vault it owns or release funds from an escrow. The mechanism that makes that work is the Cross-Program Invocation, and it's what this post is about.

CPIs are also the feature that makes Solana composable. A program on its own is a closed box. A program that can call other programs can build on everything already deployed: the System Program to create accounts and move SOL, the Token Program to mint and transfer tokens, any other program someone has shipped. If you've ever wondered how a single Anchor instruction manages to transfer tokens when your program clearly doesn't contain transfer logic, the answer is a CPI into the Token Program.

The problem: your program can't do everything itself

Say your program runs a vault that holds SOL for a user, and later releases it under some condition. To move SOL between system-owned accounts, the transfer has to be performed by the System Program, since that's the program that owns those accounts and your program can only debit lamports from accounts it owns directly. So when the source is a system-owned account, your program needs a way to call the System Program mid-instruction.

That's one wall. There's a second one as soon as the account being moved from is a PDA your program controls: authorizing the action requires a signature for an address that has no private key. CPIs solve the first wall, letting your program invoke another program's instruction. PDA signing, layered on top, solves the second. The same pattern shows up constantly with tokens, where your program's PDA is the authority over a token account and has to authorize a transfer through the Token Program, which is the example we'll build below.

The idea: one instruction calls another program's instruction

A Cross-Program Invocation is one program calling an instruction on another program during its own execution. The calling program (the caller) builds an instruction aimed at the callee program, hands it the accounts that instruction needs, and invokes it. The callee runs to completion, then control returns to the caller, which continues where it left off.

The key thing to hold onto is that this is the same kind of instruction a normal client would send from outside. You are assembling a target program ID, an account list, and instruction data, exactly what a transaction contains, except your program is the one issuing it instead of a wallet. The runtime treats it as a nested call within the same transaction.

There's a depth limit worth knowing: CPIs can only nest so far. Program A can call B, B can call C, and so on, but the runtime caps how deep the chain goes to keep execution bounded. The current limit is 5 levels (raised to 9 under a newer runtime change, SIMD-0268), and you'll rarely come close in practice.

invoke and invoke_signed: the two functions

At the native level, Solana gives you two functions for making a CPI.

invoke is for calls where the signatures you need are already present on the transaction. The privileges of the accounts passed into your program extend to the program you call, so if a user signed the outer transaction, that signature carries through to the CPI. This is what you use to act on a normal user-owned account, like asking the System Program to transfer SOL the user already authorized.

pub fn invoke(
    instruction: &Instruction,
    account_infos: &[AccountInfo<'_>],
) -> ProgramResult

invoke_signed is for when your program needs a PDA to sign. Since the PDA has no private key, you instead pass the seeds (plus the bump) used to derive it. The runtime re-derives the address from those seeds and your program's ID, and if it matches an account in the call, it treats that account as having signed.

pub fn invoke_signed(
    instruction: &Instruction,
    account_infos: &[AccountInfo<'_>],
    signers_seeds: &[&[&[u8]]],
) -> ProgramResult

A detail that demystifies the whole thing: invoke is just invoke_signed with an empty seeds array. They run through the same path; the only difference is whether you supply signer seeds.

pub fn invoke(instruction: &Instruction, account_infos: &[AccountInfo]) -> ProgramResult {
    invoke_signed(instruction, account_infos, &[])
}

The part that matters most: PDA signing is not cryptographic

This is the conceptual center of the post, so it's worth slowing down.

When a normal account signs a transaction, a private key produces a cryptographic signature. A PDA has no private key, so nothing like that can happen. Instead, PDA signing is a runtime construct. You hand invoke_signed the seeds, the runtime re-derives the PDA from those seeds and the calling program's ID, and if the derived address matches an account in the call, the runtime marks that account as signed for the duration of the CPI.

No signature is ever computed. The "signature" is the runtime agreeing that because your program supplied the correct seeds, and those seeds plus your program ID derive to this exact address, your program is allowed to authorize actions on it. This is the cash-out of everything from the PDA post: the address is derived from your program, so only your program can present the seeds that unlock it. The absence of a private key isn't a gap that PDA signing patches over. It's the whole reason the scheme is secure, because no external party can ever produce these credentials.

How it looks in Anchor

Anchor wraps the raw functions in a CpiContext, which bundles the program you're calling with the accounts that instruction needs. You build the context, then call the typed helper for the instruction.

A plain CPI, transferring SOL via the System Program using the user's own signature. Here Transfer is the System Program's transfer, which takes just from and to:

use anchor_lang::system_program::{transfer, Transfer};

let cpi_context = CpiContext::new(
    ctx.accounts.system_program.to_account_info(),
    Transfer {
        from: ctx.accounts.sender.to_account_info(),
        to: ctx.accounts.recipient.to_account_info(),
    },
);
transfer(cpi_context, amount)?;

A signed CPI, where a PDA is the authority. This one transfers SPL tokens through the Token Program, so the Transfer here is the token program's version, which also takes an authority, the account that must sign. That authority is our PDA, and new_with_signer plus the seeds is how the PDA signs:

use anchor_spl::token::{transfer, Transfer};

let bump = ctx.accounts.vault.bump;
let seeds: &[&[&[u8]]] = &[&[b"vault", authority_key.as_ref(), &[bump]]];

let cpi_context = CpiContext::new_with_signer(
    ctx.accounts.token_program.to_account_info(),
    Transfer {
        from: ctx.accounts.vault_token_account.to_account_info(),
        to: ctx.accounts.recipient_token_account.to_account_info(),
        authority: ctx.accounts.vault.to_account_info(),
    },
    seeds,
);
transfer(cpi_context, amount)?;

Read the difference in plain terms. CpiContext::new says "make this call using the signatures already on the transaction." CpiContext::new_with_signer says "make this call, and also present these seeds so the runtime will let my PDA sign." The seeds you pass are the same ones you'd use to derive the PDA, with the bump as the final element.

If you're calling another Anchor program rather than a built-in one, you add it as a dependency with the cpi feature, which generates typed instruction builders for it. That's a setup detail the lessons will walk through; the mental model is the same either way.

A few things that trip people up

Forgetting an account the callee needs. A CPI passes accounts to the callee, and the callee validates them just like any instruction. If the inner instruction needs the System Program or a token program account, it has to be in your account list and in your #[derive(Accounts)] struct. A missing account shows up as a failure inside the CPI, not in your own logic.
Wrong seeds in invoke_signed. If the seeds you pass don't re-derive to the PDA the callee expects as a signer, the runtime won't mark it signed and the call fails. The seeds, their order, and the bump all have to match the derivation exactly, the same discipline as the PDA constraints.
Reaching for invoke_signed when invoke would do. If the authority is a normal user who already signed the transaction, you don't need signer seeds. Signing with a PDA is only for accounts your program controls that have no key of their own.
Confusing "who signs" with "who owns." A program can sign for a PDA derived from its own ID. It can't sign for arbitrary accounts just because they're passed in. The seeds prove the PDA belongs to the calling program, which is what authorizes the signature.

TL;DR

A CPI is one program calling another program's instruction mid-execution, which is what makes Solana composable.
You build a target instruction, accounts, and data, much like a client would, and your program issues it.
invoke uses signatures already on the transaction; invoke_signed lets a PDA sign by supplying its seeds.
PDA signing isn't cryptographic: the runtime re-derives the PDA from the seeds and your program ID and marks it signed if it matches.
In Anchor, CpiContext::new is a plain CPI and CpiContext::new_with_signer adds the PDA seeds.
CPIs nest only so deep: the stack limit is 5 levels (9 under SIMD-0268).

Going further

The Solana CPI documentation covers both functions, privilege extension, and the execution flow in detail, and the quick-start CPI tutorial builds a vault that signs with a PDA end to end. For the native signature, the invoke_signed reference on docs.rs spells out exactly how the runtime treats PDA signing.

If you're doing 100 Days of Solana, the next arc puts this to work, and since you already understand PDAs, the signing half should click rather than mystify. Not joined yet? It's not too late to build alongside everyone: 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 >

Understanding Program Derived Addresses: The Solana Address That Has No Private Key

Vincent Jande — Fri, 19 Jun 2026 12:23:35 +0000

Every Solana program eventually hits the same question: where do I put my data, and how do I find it again later?

Programs are stateless, so a program's data lives in separate accounts, each at an address. The moment you store something, you owe an answer to a problem databases tend to hide from you: what address does this live at, and how does the program find it again tomorrow? Program Derived Addresses are Solana's answer. The name scares people off, but the idea is mostly "an address you compute instead of remember, that only your program can control."

The problem, in code

Say each user gets a counter account. The normal way to make an account is to generate a fresh keypair and store data at its public key:

import { Keypair } from "@solana/web3.js";

const counter = Keypair.generate();
// counter.publicKey is something random, e.g. 7Hx4...9fT
// create the account at that address, write count = 0

It works. But the address is random, so nothing connects this user to that address. Tomorrow, when the user comes back to increment, how does your program find their counter? You're forced to keep a lookup table somewhere:

// the mapping you now have to store and never lose
const counters = {
  "9fYL...user1": "7Hx4...9fT",
  "B2k9...user2": "Qz1p...4dR",
  // ...times ten thousand users
};

Lose that table, lose the data, even though the accounts are right there on chain. You're storing files in a warehouse and writing the shelf number on a sticky note.

The fix: compute the address from what you already know

What if the address were a function of the user instead of random? Give a function the word "counter" and the user's public key, and it hands back a fixed address. Same inputs, same address, every time. No table.

That's a PDA. PDAs are 32-byte addresses derived deterministically from a program ID and a set of seeds. The seeds are the meaningful inputs you pick (here, "counter" + the user's key). With @solana/web3.js, the library Anchor's client uses:

import { PublicKey } from "@solana/web3.js";

const [counterPda, bump] = PublicKey.findProgramAddressSync(
  [
    Buffer.from("counter"),      // a label
    userPublicKey.toBuffer(),    // the user's pubkey
  ],
  MY_PROGRAM_ID,
);
// counterPda is the SAME every time for this user. No mapping needed.

The mapping table is gone: any time you need a user's counter, you re-derive it, and the address itself encodes who it belongs to. With Anchor you'll often skip the explicit call entirely and let the client derive PDAs from the IDL, but under the hood this is what runs.

The twist: it has no private key

Normal addresses are public keys sitting on the Ed25519 elliptic curve, and every point on that curve has a matching private key. That private key is what signs transactions. But we just hashed a counter address into existence without making a keypair, so who holds its private key?

If the hash happened to land on the curve, some stranger might, which would let outsiders sign for your program's accounts. So Solana guarantees a PDA sits off the curve, meaning no private key exists for it. That is the title: an address with no private key. It is the whole point, because it means only the program that derived it can control it.

The bump, in one example

A given set of seeds plus the program ID produces a valid off-curve address only about half the time, so the derivation includes one more input: a single byte called the bump. The search starts at 255 and counts down, hashing the seeds, the program ID, and the current bump together on each attempt until the result lands off the curve:

hash(seeds + program_id + 255) -> on curve?  try 254
hash(seeds + program_id + 254) -> on curve?  try 253
hash(seeds + program_id + 253) -> off curve! use this.  bump = 253

The bump is part of the hash from the very first attempt at 255, not something added only after a bump-less hash fails. The first value that lands off-curve, the highest one that works, is the canonical bump. findProgramAddressSync returns it as the second value, the bump above. You'll want to use the canonical bump rather than any other valid one, because the same seeds can produce different valid addresses under different bumps, and accepting any of them would let an attacker slip a counterfeit account past your checks.

In Anchor: derivation becomes a constraint

On the program side, Anchor does the derivation and the check for you. Creating the counter (storing the bump for later):

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = authority,
        space = 8 + Counter::INIT_SPACE,
        seeds = [b"counter", authority.key().as_ref()],
        bump,                                  // Anchor finds the canonical bump
    )]
    pub counter: Account<'info, Counter>,
    #[account(mut)]
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>,
}

Then later, validating it on every other instruction:

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(
        mut,
        seeds = [b"counter", authority.key().as_ref()],
        bump = counter.bump,                   // reuse the stored bump
    )]
    pub counter: Account<'info, Counter>,
    pub authority: Signer<'info>,
}

Read the seeds line as a rule: this account's address must derive from "counter" and this authority's key. When the instruction runs, Anchor re-derives the address and checks that the passed-in account matches. Pass a different account and it's rejected before your code runs. The address is the proof, so there's no mapping left to tamper with. (Store the bump in your Counter struct at init: pub bump: u8.)

The difference between the two structs is the whole lifecycle: init creates the account at the derived address the first time and lets Anchor search for the canonical bump, while the plain seeds + bump = counter.bump form validates an account that already exists, reusing the stored bump so it doesn't pay to re-search.

Four things that trip people up

Seed mismatch between client and program. The seeds, their order, and their byte encoding need to match on both sides. Buffer.from("counter") in the client has to line up with b"counter" in the program, in the same position. One reordered or mistyped seed derives a different address, and the constraint rejects it. A lot of "my PDA doesn't match" bugs come down to this.
Not storing the bump. If you don't save the canonical bump at init, every later instruction has to re-derive it by searching, which burns compute for no reason. Store it once in the account and reuse it with bump = counter.bump.
Treating the rejection as a bug. When you pass the wrong account and the seeds constraint throws, that's the security model working, not a failure. The point is that only the correctly derived address gets accepted.
Deriving without the canonical bump. Other bump values can produce valid but different addresses from the same seeds. Sticking with the canonical one, which is what Anchor's bare bump and findProgramAddressSync give you by default, keeps client and program in agreement.

The payoff: a program that signs for itself

No private key means no human can sign for a PDA, so how does a program move tokens out of an escrow it owns? The runtime gives the owning program a special power: the program whose ID derived the PDA can sign for it, through invoke_signed during a cross-program invocation. The program's code becomes the authority, with no key anywhere.

That's the foundation under most escrows, vaults, and lending pools on Solana: a program holding assets no human can drain, releasing them only by its own logic. We'll go deep on invoke_signed and CPIs in the next post. For now, hold the shape: the missing private key isn't a weakness, it's what lets a program act as a trustless custodian.

TL;DR

Stateless programs store data in accounts at addresses; remembering random addresses doesn't scale.
A PDA derives the address from seeds + program ID, so you recompute it instead of storing it.
It's forced off the Ed25519 curve, so no private key exists and no outsider can sign for it.
The canonical bump (counting down from 255) is the reproducible address you'll normally use.
In Anchor, seeds + bump constraints derive and validate the account for you.
The deriving program can sign for its own PDA (invoke_signed), which is what powers escrows and vaults.

Going further

The Solana PDA docs cover derivation, the canonical bump, and the off-curve guarantee, with runnable examples on the derivation page (the "Legacy" tab is the @solana/web3.js version Anchor's client uses). The Anchor PDA guide walks through the seeds and bump constraints you'll actually write, and the full account constraints reference lists every constraint in one place.

If you're doing 100 Days of Solana, the next arc puts all of this to work, and the challenges should now read like something you already understand. Not joined yet? It's not too late: mlh.link/solana-100.

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.