DEV Community: Matthew Revell

100 Days of Solana is a wrap!

Matthew Revell — Fri, 31 Jul 2026 10:33:05 +0000

Over the past 100 days, we’ve gone from the basics of wallets and transactions to deploying programs on Solana devnet.

Some people completed every challenge. Others joined for a week, an arc, or whenever time allowed. However you took part, congratulations! You learned something new and built on Solana.

And if you missed the live run, you haven’t missed your chance. All 100 challenges are still available, and you can start from Day 1 whenever suits you.

What is 100 Days of Solana?

You may be curious about blockchain development but find that many tutorials assume you already understand the terminology, use cases, and other fundamentals.

100 Days of Solana was designed to provide a clearer route in: from “I’m a web or mobile developer and this looks interesting” to “I can build and deploy something real on Solana.”

Here’s how it works:

100 daily challenges
Most challenges introduce one focused idea in around 10 to 20 minutes.
Each week has a theme that introduces and reinforces a new concept.
It’s free to take part.

And the whole thing is designed so that you can still make progress if you complete just a couple or every challenge from a week.

What we covered

If you start at Day 1, here’s how the journey unfolds.

First: learn to speak Solana

Create a wallet — a cryptographic keypair that acts as your identity — and send your first transactions
Read live data directly from the network
Get to grips with Solana’s account model

Next: create digital assets

Create your own tokens and NFTs, which are built from accounts with clearly defined roles and rules
Configure features such as transfer fees, interest, and transfer restrictions
See how your Solana program enforces those rules on every transfer

Then: write your own programs

Learn the basics of Solana programs
Learn enough Rust to build with Anchor, a framework that provides some of the structure Rails or Express brings to Web2 development
Design state with program-derived addresses, or PDAs: predictable addresses calculated from known values
Call other programs in much the same way that one service calls another service’s API

After that: think like an attacker

Treat every input as hostile, because anyone on a public network can send instructions to your program
Audit your code and write tests that actively try to break it
Use property testing and fuzzing to find edge cases you might never write by hand
Reproduce a real Solana exploit, understand why it worked, and then fix the vulnerability

Finally: ship what you built

Deploy to devnet, Solana’s free staging environment
Publish your program’s interface, roughly the on-chain equivalent of an OpenAPI schema
Build a frontend that connects to a user’s wallet and asks them to approve transactions while their private keys remain under their control
Give an AI agent tightly limited access to a wallet through a deny-by-default policy layer
Bring everything together in a capstone project of your own

By Day 100, you’ll have gone from creating your first wallet to deploying your own program, with an understanding of the major layers in between.

Shout-outs

One of the best things about 100 Days of Solana was the community that formed around it.

People published hundreds of posts here on DEV, while the event Discord became a place to compare approaches, untangle tooling problems, review code, and celebrate first deployments.

If you’re starting the challenges now, those posts are a valuable companion along the way. Whatever error you’re staring at, there’s a good chance someone has already encountered it and written about what they learned.

Thank you to everyone who wrote, demoed, answered a question, or reviewed someone else’s code. You made 100 Days of Solana far better than the challenges could have been on their own.

And a special thank you to Vincent Jande, a graduate of MLH’s Solana Fellows program, who helped reivew and create content throughout the 100 days.

Continue your journey

Whether you’ve just shipped your first Solana project at the end of the 100 days or you’re about to begin day 1, there are several ways to keep going:

Solana Developer Bootcamp — a free, project-based video course from the Solana team for developers who want to go deeper
Global Hack Week — MLH’s free monthly online hackathon, where you can use your Solana skills in a new project
MLH events — find an in-person or digital hackathon and build alongside other developers

The scheduled 100 days may be over but there's always more to explore.

Happy hacking!

Arc 14 Catch-up: Agentic Solana

Matthew Revell — Wed, 29 Jul 2026 09:59:11 +0000

An AI agent with access to a wallet sounds powerful.

It also sounds like it could be risky.

A language model can misunderstand a request, choose the wrong tool, repeat an action, or confidently pursue a goal that should never have been allowed in the first place. Giving it unrestricted signing authority would turn those mistakes into transactions.

Arc 14 was about building something more useful than that.

Across Days 92–98, we gave an agent access to Solana data, then gradually introduced tools, a wallet, an MCP server, a policy engine and an autonomous workflow.

At every stage, the same boundary held:

The model could decide what it wanted to do.

Code decided what it was allowed to do.

The agent began with read-only tools

The first challenge kept the stakes low.

We built a small agent loop using Claude and a set of Solana devnet tools. The agent could answer natural-language questions such as:

How much SOL does this wallet hold?
Who owns this account?
Is this account executable?
How much data does it store?

The model never connected to Solana directly.

It did not construct arbitrary RPC requests or receive unrestricted network access. The application defined a small set of tools, described what each one did, and decided how to execute them.

Claude could inspect those descriptions and choose which tool to call, but the surrounding application remained in control.

The result still felt conversational.

We asked a question in plain English.

The agent selected a balance tool.

The application called the RPC endpoint.

The result went back to the model.

The model explained it to us.

Behind that interaction was a simple loop:

The user gives the agent a goal or question.
The model decides whether it needs a tool.
The application validates and executes the tool call.
The result goes back to the model.
The loop continues until the model can answer.

The model supplied the judgement.

The application supplied the capabilities.

Tool definitions shaped what the agent could do

Each tool had four important parts:

A description telling the model when it should be used.
An input schema defining what the model could request.
An implementation deciding what actually happened.
An output giving the model evidence for its next step.

Those details mattered.

A vague description could lead the model to choose the wrong tool.

A loose schema could allow malformed or ambiguous requests.

An implementation that trusted every argument could turn a model mistake into a system problem.

Even the read-only tools needed boundaries.

A balance tool should accept a valid Solana address.

An account-inspection tool should return useful structured metadata.

Errors should come back in a form the model could reason about without hiding the original detail from the developer.

The prompt described how we wanted the agent to behave.

The tool definitions established what it could actually ask the application to do.

Then we gave the agent a wallet

Day 93 raised the stakes.

The agent received its own devnet wallet and two new abilities:

Check its balance.
Send SOL.

That turned it from a read-only assistant into a system capable of changing on-chain state.

The wallet belonged to the application, not to the model.

Its private key remained inside the process that built and signed transactions. It was never inserted into the prompt, returned in a tool result or exposed through the model context.

The model did not need the key.

It only needed a tool that accepted a proposed recipient and amount.

The application could then decide whether to build and sign the transaction.

This separation matters because model context is not a safe place for secrets.

Prompts, tool calls, logs and responses may be stored, inspected or passed between components. A private key placed there could be leaked accidentally or repeated in generated output.

Keeping the key inside the signing layer meant the model could request an action without possessing the credential required to perform it.

The agent could ask to send 0.05 SOL to an address.

Only the application could turn that request into a signed transaction.

The transfer limit lived in code

We did not rely on the prompt to limit how much SOL the agent could send.

The transfer tool enforced a hard cap.

If the proposed amount exceeded that limit, the application rejected the request before building the transaction.

We could have told the model never to send more than 0.1 SOL. It would probably follow that instruction most of the time.

But a prompt can be misunderstood, overridden by conflicting instructions or applied inconsistently.

A code-level check behaves differently.

If the amount is too high, the transfer does not happen.

It does not matter how persuasive the request is.

It does not matter how confident the model sounds.

It does not matter whether the proposed action appears to support the wider goal.

The signing layer refuses.

That is where rules involving money, permissions and irreversible actions belong.

One transfer cap was not enough

A per-transfer limit protects against one large transaction.

It does not stop an agent from making many smaller ones.

An agent limited to 0.1 SOL per transfer could still attempt ten transfers and spend 1 SOL overall.

That showed why validation inside the transfer tool was only the beginning.

The wider system also needed to decide:

Which recipients were allowed?
How much could be sent in one transaction?
How much could be spent across the whole session?
How many tool calls could the agent make?
How long could the loop continue?
What should happen after a failed transaction?
Which actions needed to be logged?

Those decisions belonged in a dedicated policy layer rather than being scattered through prompts and tool implementations.

MCP made the tools reusable

Day 94 moved the Solana tools into a Model Context Protocol server.

Until then, the tools had lived inside one application.

That worked, but it tied the capabilities to a particular agent implementation.

An MCP server made them reusable.

It exposed tools for tasks such as:

Reading a wallet balance.
Inspecting on-chain vault state.
Calling guarded program instructions.

Any compatible AI client could discover and use those tools through the same protocol.

The server described what was available, accepted structured requests and returned structured results.

This was similar to the role the IDL played in Arc 13.

The IDL made a Solana program discoverable to software.

MCP made agent-facing capabilities discoverable to AI clients.

The useful part was not simply that another client could call the tools.

The wallet key and safety rules stayed on the server.

A new client did not receive direct access to either.

It received the same controlled interface as every other client.

That meant we could change the model, desktop client or agent framework without rebuilding the Solana integration or moving authority into the new client.

The server remained the trust boundary

MCP made tools easier to discover and reuse.

It did not make every client trustworthy.

A compatible client could request a tool call, but the server still had to validate it.

The client might be misconfigured.

The model might choose the wrong tool.

A user might request an action outside the intended scope.

A request might contain an invalid address or an excessive amount.

The server remained responsible for:

Validating tool inputs.
Applying policy checks.
Protecting private keys.
Building and signing transactions.
Returning useful errors.
Recording what happened.

Tool results were untrusted too.

On-chain text and metadata can be written by other people. A memo, token name or decoded account field returned to the model could contain instructions intended to influence its behaviour.

The application could not treat that content as trusted guidance merely because it came back from a tool.

Even if hostile data changed the model’s reasoning, the same policy rules still controlled what could be signed. A poisoned response could affect what the model proposed, but it could not expand the allowlist, raise the spending cap or reset the session budget.

That carried forward the security lesson from Arc 12.

Untrusted input is not limited to transaction accounts. It also includes the data an agent reads and brings into its context.

We built a deny-by-default policy engine

Day 95 turned the simple transfer cap into a proper policy layer.

A proposed transfer was denied unless it passed every rule.

The policy checked:

Whether the recipient was a valid Solana address.
Whether the recipient appeared on an allowlist.
Whether the amount stayed below the per-transfer cap.
Whether the total session spend remained within budget.

The application tracked cumulative spend outside the model context.

The agent did not get to remember, reset or reinterpret its own remaining budget. The policy engine calculated that from application-owned session state.

This was a deny-by-default design.

The system did not search for a reason to reject the transfer.

It required the transfer to satisfy every condition for approval.

If any check failed, the transaction was not signed.

A missing allowlist entry resulted in denial.

A malformed address resulted in denial.

An amount above the cap resulted in denial.

An exhausted session budget resulted in denial.

Unexpected input did not fall through into execution.

It stopped.

Intent and permission were separate questions

The model’s job was to reason about the goal.

The policy engine’s job was to decide whether a proposed action fitted the rules.

The agent might correctly calculate that a wallet was short by 0.4 SOL.

That did not mean it had permission to transfer 0.4 SOL.

The amount might exceed the per-transfer cap.

The destination might not be allowlisted.

The remaining session budget might be only 0.2 SOL.

The correct outcome could therefore be a refusal even when the model’s reasoning was sound.

That was an important property of the system.

Its safety did not depend on the model making the right security decision every time.

The model could be mistaken, overconfident, manipulated by the user or influenced by hostile tool output.

The policy should produce the same result for the same proposed action and the same session state.

Model behaviour was variable.

Policy behaviour was meant to be predictable.

Denials were normal system behaviour

A rejected action was not necessarily an error.

Sometimes it was the system working exactly as designed.

If the agent proposed sending funds to an address outside the allowlist, the policy engine denied the request and returned the reason.

The agent could then decide what to do next.

It might tell the user that the action was not permitted.

It might ask for a different recipient.

It might propose a smaller transfer.

It might conclude that the goal could not be completed under the current limits.

This was better than treating every denial as an exception that crashed the workflow.

The policy result became information the agent could reason over.

Approved actions could proceed to signing.

Denied actions came back with a structured explanation.

The agent could adapt to that decision, but it could not override it.

The autonomous workflow brought everything together

Day 96 combined the agent loop, wallet tools and policy engine in a goal-driven workflow.

The example goal was to make sure a savings wallet held at least a specified amount of SOL.

The agent needed to:

Check the savings wallet balance.
Compare it with the target.
Calculate any shortfall.
Check the funding wallet.
Propose a transfer.
Pass the proposal through policy.
Submit an approved transaction.
Verify the new balance.
Record what happened.

This was more than one tool call followed by an answer.

The agent had to inspect the current state, decide whether action was needed, act within its limits and then check the result.

That final verification mattered.

A transaction signature shows that a transaction was submitted.

It does not by itself prove that the intended goal was reached.

The agent read the on-chain state again and compared it with the target.

That closed the loop:

Observe.

Reason.

Act.

Verify.

Normal, constrained and impossible scenarios behaved differently

We tested the workflow under several conditions.

In the normal case, the target wallet was below its minimum balance, the funding wallet had enough SOL, and the required transfer passed policy.

The agent calculated the shortfall, requested the transfer and verified the new balance.

In a constrained case, the goal was achievable only within the transfer cap and remaining session budget.

The agent had to work within those limits rather than simply choosing the most direct action.

In an impossible case, the policy or available funds made the target unreachable.

The recipient might not be allowlisted.

The shortfall might exceed the session budget.

The funding wallet might not contain enough SOL.

The agent could reason correctly and still be unable to complete the goal.

That was not a failure of the system.

The correct behaviour was to stop, explain the constraint and preserve the policy boundary.

“Unable to proceed” is sometimes the right result.

Turn limits prevented endless loops

An agent loop needs a stopping condition.

Without one, the model could continue calling tools, retrying failed actions or revisiting the same reasoning indefinitely.

Arc 14 included explicit turn limits so the application could stop the workflow after a fixed number of steps.

That protected against accidental loops and limited the amount of time, tokens and network activity one request could consume.

A turn limit is a simple control, but it addresses a real feature of agent systems.

The model decided what to do next.

The application decided how long it was allowed to keep deciding.

Other systems might also use time limits, tool-call limits or approval gates for particular actions.

The exact control can vary.

The important part is that the agent cannot grant itself unlimited time or unlimited attempts.

Structured logs made the workflow inspectable

Autonomous behaviour is hard to trust when all we can see is the final answer.

The workflow therefore wrote structured logs for each important step.

Those logs could record:

The goal the agent received.
Which tool it selected.
The arguments it proposed.
The relevant policy decision.
Why an action was approved or denied.
The transaction signature.
The result of the verification step.
The final outcome.

This created a trace of how the system moved from the original goal to the result.

The logs were useful for debugging, but their value went further.

They showed whether the agent had interpreted the goal correctly.

They revealed whether the policy engine had applied the expected rule.

They made repeated actions visible.

They provided evidence that a successful workflow had verified its work.

They also made denials easier to explain.

Without logs, we might know only that the transfer did not happen.

With logs, we could see that the recipient was not on the allowlist or that the remaining budget was too low.

Autonomous systems need this kind of evidence.

A final response is not enough.

Documentation forced us to describe the boundary

Day 97 moved from building the system to explaining it.

We wrote a public technical walkthrough covering:

The agent loop.
The available tools.
The MCP server.
The wallet boundary.
The policy engine.
The tool contracts.
The overall architecture.
Logs from a real run.

The most important distinction was between variable and invariant behaviour.

The model’s reasoning was variable.

It might choose different tools, phrase its explanation differently or take another path towards the same goal.

The policy layer was invariant.

The same proposed action and session state should produce the same approval decision regardless of how the model explained its intention.

That made the architecture easier to understand.

The agent was not safe because the model had been instructed to behave.

It was safe because the model could reach the signing capability only through code that enforced fixed rules.

The documentation needed to show exactly where that boundary lived.

Tool contracts mattered as much as prompts

A public walkthrough of an agent system can easily become a long explanation of prompting.

Prompts mattered, but they were only one part of this arc.

The stronger material was in the tool contracts and policy rules.

Which fields did a transfer request require?

Which validation happened before policy?

Which policy result came back after denial?

Where did the private key live?

Where was cumulative session spend stored?

Which component built the transaction?

How did the workflow confirm success?

How were tool calls and policy decisions logged?

How was untrusted tool output kept from bypassing the signing rules?

Those details explained what the system could actually guarantee.

A prompt described intended behaviour.

A tool contract defined the action the model could request.

The policy engine defined which requests could proceed.

The signer controlled what reached the network.

The logs showed what occurred.

That was the full safety story.

The final demo showed both action and refusal

Day 98 turned the workflow into a short recorded demonstration.

The demo began with a natural-language goal.

The agent inspected balances, selected tools, proposed an action and passed it through policy.

An approved transaction appeared on devnet and could be verified on-chain.

But the demo also needed to show a denial.

That was just as important as the successful transfer.

A system that can move funds is easy to demonstrate.

A system that can refuse an unsafe or disallowed request is more convincing.

The denial showed that the policy engine remained in control even when the model proposed the action.

The most useful demo therefore included:

The original goal.
The agent’s tool calls.
The policy decision.
The transaction signature for an approved action.
The resulting on-chain state.
A request rejected by policy.
The reason for the rejection.

This made the boundaries visible rather than asking the audience to trust that they existed somewhere in the code.

What Arc 14 taught us

Arc 14 was not about handing an AI model a wallet and hoping for the best.

It was about building an agent inside a system that retained control.

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

Build an agent loop around clearly defined Solana tools.
Keep network access and private keys outside the model context.
Treat tool results and on-chain data as untrusted input.
Enforce transfer limits, allowlists and budgets in application code.
Package reusable Solana capabilities in an MCP server.
Apply the same safety rules across different AI clients.
Run a workflow that observed, acted and verified.
Track session state outside the model.
Limit agent turns and record structured execution logs.
Demonstrate both approved and denied actions.

The central lesson was that autonomy and authority are not the same thing.

The model can decide which tool might help.

It can interpret a goal.

It can calculate a shortfall.

It can propose a transfer.

It can explain a denial.

But it does not hold the private key.

It does not decide which recipients are permitted.

It does not set its own spending cap.

It does not remember or reset its own session budget.

It does not override the policy engine.

The model reasons.

The code holds the authority.

Revisit the Arc 14 challenges

Day 92: Build a read-only Solana agent that answers questions through defined tools

Day 93: Give the agent a devnet wallet while keeping its key and spending limits in code

Day 94: Package the Solana tools as a reusable MCP server

Day 95: Build a deny-by-default policy engine with allowlists and budgets

Day 96: Run and verify an autonomous wallet-management workflow

Day 97: Document the agent architecture, tool contracts, policy rules and run logs

Day 98: Record a public demo showing both a successful action and a policy denial

Arc 13 Catch-up: Deployment

Matthew Revell — Tue, 28 Jul 2026 15:51:19 +0000

A program can pass every local test and still be a long way from ready for real users.

It needs to be deployed to the right network, with sensible controls over who can change it. Other developers need a reliable way to call it. Users need a frontend that can connect to their wallet and submit transactions. When those transactions fail, the app needs to explain what happened.

Arc 13 covered that last stretch.

Across Days 85–91, we deployed a program to mainnet-beta, secured its upgrade authority, published its interface, generated a typed client, built a wallet-connected frontend and improved the way it handled transaction failures.

Then we made the launch public, with an on-chain address anyone could verify.

Deployment changed the stakes

Until Day 85, most of our work had taken place locally or on devnet.

Those environments gave us room to experiment. We could redeploy, replace accounts, request test SOL and recover from mistakes without putting real assets at risk.

Mainnet-beta is different.

The program becomes public infrastructure. Clients may begin depending on its address and interface. Users can send transactions involving real assets. Any authority left attached to the program now controls production code.

Mainnet deployment also costs real SOL. The deployment wallet needs enough to create and fund the on-chain program account, with the amount depending on the size of the program.

The first challenge was therefore about more than learning another command.

We built the program, configured the CLI for mainnet-beta, funded the deployment wallet and deployed the program to the live network.

Once it was there, we verified the program ID through Explorer rather than assuming that a successful command meant everything was correct.

That verification matters.

A frontend configured with the wrong address may call an older deployment or fail entirely. Documentation pointing to the wrong program creates the same problem for every developer who follows it.

The deployed address is the identity that clients and users will rely on.

By the end of the challenge, we had something we had not had before: a public program running on mainnet-beta at an address anyone could inspect.

Mainnet deployment was an operational decision

The Web2 comparison throughout the arc was moving a service from staging to production.

That comparison holds up because deployment changes who can rely on the software and what a mistake can cost.

A staging service can usually be reset.

A broken development build can be replaced without affecting users.

A public interface may already have clients depending on its exact behaviour.

The deployment command is only one part of that transition.

We also need to know:

Which wallet paid for the deployment?
Who can replace the program code?
Is the live program ID recorded correctly?
Can another developer discover the interface?
How will users submit transactions?
What will they see when something fails?
Is there verifiable evidence of what was deployed?

Those questions made Arc 13 feel less like another coding arc and more like the beginning of operating software.

The upgrade authority was a production credential

When a Solana program is deployed, its upgrade authority initially belongs to the deployment wallet.

That authority can replace the executable code while keeping the same program ID.

This is useful during active development. Bugs can be fixed and new functionality added without forcing every client to move to another address.

It is also a significant amount of power.

Anyone who controls the upgrade authority can change what the program does.

That makes it closer to a production credential than a normal development key.

On Day 86, we inspected the authority attached to our program, transferred it to another key and then transferred it back.

The exercise made the relationship concrete.

The program might be visible at a public address, but whoever holds the upgrade authority can still replace the code behind that address.

Leaving it attached to a personal wallet creates a single point of failure.

The key could be lost or exposed.

Its owner could become unavailable.

A mistaken command could transfer authority to the wrong address.

For a real production program, the safer approach is usually to place upgrade authority behind a multisig such as Squads.

An upgrade can then require approval from several authorised people rather than depending on one private key.

That also gives the team a clearer release process.

Who proposed the upgrade?

Who reviewed it?

How many approvals are required?

Which build is being deployed?

A multisig does not guarantee that an upgrade is correct, but it reduces the chance that one compromised wallet or accidental action can change the program.

We could also remove the upgrade authority

The other option was to make the program immutable.

Removing the upgrade authority with --final permanently prevents the program from being upgraded.

That can be a strong guarantee for users. The code they inspected cannot later be replaced by an authority holder.

But the decision cannot be reversed.

If a vulnerability appears, the program cannot be patched at its existing address. A replacement would need to be deployed, and clients and users would need to move to it.

That makes immutability a governance and operational decision rather than a final bit of deployment housekeeping.

Before removing the authority, a team needs confidence in the code, the tests, the interface and the plan for handling future problems.

For most actively developed programs, moving the authority to a well-managed multisig is a more practical first step.

Immutability may come later, once the inability to change the program is a feature rather than a liability.

A program ID was not enough

Deploying the program made it available, but it did not make it easy to use.

A program address tells us where the code lives.

It does not tell another developer:

Which instructions the program exposes.
Which arguments those instructions accept.
Which accounts each instruction requires.
Which accounts must sign.
Which accounts must be writable.
How program-owned account data is structured.
Which errors the program may return.

Without that information, integrating with the program would mean reading its source code or manually reconstructing its instructions and account layouts.

Day 87 was about publishing the interface.

We rebuilt the Anchor program, published its IDL and fetched it back from the network.

The IDL describes the program’s public surface in a machine-readable form.

The Web2 comparison is an OpenAPI schema.

An API may be reachable at a URL, but developers still need to know its routes, parameters, request bodies and responses.

An IDL plays a similar role for an Anchor program.

It turns a program address into an interface that tools and developers can understand.

The IDL became a contract

Publishing the IDL did more than save another developer from reading our source code.

It made the program interface explicit.

That matters once frontends, scripts and other programs begin depending on it.

Changing an instruction name can break generated clients.

Changing its arguments can break serialisation.

Adding a required account can make existing transactions incomplete.

Changing an account layout can make stored state unreadable to older clients.

During local development, those changes are easy to treat as implementation details.

After deployment, they become compatibility decisions.

The IDL records the interface that other software expects.

That does not mean the interface can never change. It means changes need to be considered, versioned and communicated like changes to any other public API.

Codama turned the interface into a typed client

Once we had the IDL, we used Codama to generate a TypeScript client.

Without a generated client, calling a program can involve a lot of manual work.

The developer needs to serialise the instruction arguments correctly, provide accounts in the expected order and interpret account data using the right layout.

A typed client moves much of that work into generated code.

Instruction names, account requirements and data types become available through normal TypeScript tooling.

Editors can offer autocomplete.

The compiler can catch some incorrect arguments before a transaction is submitted.

Developers do not need to guess how an account should be decoded or how an instruction should be assembled.

Generated clients do not remove every integration error. A correctly constructed transaction can still fail because the signer lacks authority, an account contains unexpected state or the network has moved on since the transaction was prepared.

They do remove a large class of avoidable interface mistakes.

The deployed program gave us an address.

The IDL described the interface behind it.

Codama turned that description into code another application could use.

We took the wallet flow back to devnet

The next challenge moved from program integration to user interaction.

For this exercise, we returned to devnet.

That let us build and test the browser wallet flow with test SOL before applying the same pattern to a production application. It also reinforced an important operational point: the network, RPC endpoint and program address need to be treated as configuration rather than buried throughout the frontend.

Using the official Solana dApp template, we built a React app that could:

Discover compatible wallets installed in the browser.
Ask the user to connect one.
Display the connected wallet’s devnet address.
Fetch and show its devnet balance.
Build and send a small SOL transfer.

None of those operations was new on its own.

We had generated keys.

We had read balances.

We had built transactions.

We had submitted transfers.

The difference was that the authority now came from a user’s wallet through a browser interface.

The app prepared the transaction, but it did not hold the user’s private key.

The wallet showed the request and asked the user to approve it.

Only then could the transaction be signed and sent.

That is the interaction model users expect from a Solana application.

Wallet Standard avoided wallet-specific integrations

A frontend could integrate separately with Phantom, Solflare, Backpack and every other wallet it wants to support.

That would create a growing collection of wallet-specific code and assumptions.

Wallet Standard gives browser wallets a shared interface.

Instead of hardcoding a list of supported products, the application discovers compatible wallets available in the user’s browser.

A wallet can advertise its capabilities through that common interface. The application can then connect, request signatures and submit transactions without building a separate integration for every wallet.

That makes the frontend easier to maintain and gives users more choice.

A user should not have to install the one wallet the developer happened to choose.

The application should work with wallets that support the standard.

Connecting a wallet did not mean controlling it

The frontend work also reinforced an important boundary.

A connected wallet has not handed its private key to the application.

The connection gives the app access to public information, such as the selected address, and a way to request approved actions.

The wallet remains responsible for signing.

When the user sends a transfer, the app builds the transaction and presents it to the wallet.

The wallet shows the request.

The user approves or rejects it.

The wallet signs only after approval.

This separation matters for security and user trust.

The app can guide the interaction, but the wallet controls the authority.

It also means that a transaction can fail before it reaches the network.

The user can reject the request.

The wallet can disconnect.

The signing window can close.

The application needs to handle those outcomes just as carefully as an on-chain error.

Transaction failures needed better explanations

The first version of a wallet flow often handles success and treats every failure in the same way.

Something went wrong.

Try again.

That is not enough for a production application.

A user who rejected a signing request does not need to be told that the network failed.

A user with insufficient funds needs a different next step from someone whose transaction expired.

A disconnected wallet should be reconnected rather than asked to repeat the same transaction immediately.

Day 89 introduced a reusable error-classification layer around wallet transactions.

It distinguished between cases such as:

The user cancelling the wallet request.
The transaction’s blockhash expiring.
The wallet lacking enough SOL.
The wallet disconnecting.
An unknown wallet, RPC or program failure.

The original error still went to the developer console.

That preserved the detail needed for debugging.

The user saw a shorter explanation and, where possible, a useful next step.

The application needed both views.

The developer needed the logs, RPC response and program error.

The user needed to know what happened and what they could do about it.

Different failures needed different responses

Some failures happen inside the wallet interaction.

The user declines to sign.

The wallet is locked.

The selected account changes.

The connection disappears.

Others happen while preparing or sending the transaction.

The balance is too low.

The recent blockhash has expired.

The RPC endpoint cannot be reached.

The network rejects the transaction.

Another group comes from the program itself.

An account fails an Anchor constraint.

The signer lacks authority.

The requested state transition is not allowed.

Checked arithmetic returns an error.

These failures may all surface from the same transaction flow, but they do not mean the same thing.

Classifying them makes the app easier to use and easier to support.

It also prevents misleading advice.

Telling someone to reconnect will not fix an insufficient balance.

Telling them to retry will not help when they deliberately cancelled the request.

Telling them only that the transaction failed gives them nothing useful at all.

The pieces had to work together

Day 90 continued the production-readiness work ahead of launch.

By this point, the program was deployed, its interface could be published, a typed client could call it, and a browser wallet could approve transactions.

The remaining concern was whether those pieces agreed with one another.

The frontend needed to point to the intended cluster.

The client needed to match the deployed interface.

The program ID needed to be correct for the selected environment.

Wallet and transaction state needed to remain clear when users connected, disconnected or encountered an error.

That was the wider lesson of the arc.

Deployment was not one command at the end of development.

It was the work required to make the program operable, integrable and usable.

The launch post made the deployment verifiable

The final day asked us to make the launch public.

We wrote a post explaining what we had built and linked to the deployed program in Explorer.

That link gave the announcement verifiable proof.

Readers did not have to take our word for it that the program was live.

They could inspect the address and confirm that the executable program account existed on mainnet-beta.

A useful launch post could also include:

What the program does.
Why we built it.
The mainnet program address.
A link to the source code.
Instructions for trying the application.
A screenshot or short demonstration.
An invitation to test it, contribute or ask questions.

The aim was not to produce a grand launch campaign.

It was to mark the point at which the work became available to other people.

That changes the nature of the project.

Before launch, the code mainly needs to make sense to its author.

After launch, users need to understand what it does.

Developers need to understand how to integrate with it.

Contributors need to understand how to work on it.

Operators need to understand how it can be upgraded and supported.

Publishing the work begins that conversation.

What Arc 13 taught us

Arc 13 moved us from building a Solana program to operating one.

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

Deploy a program to mainnet-beta and verify its live address.
Treat deployment as an operational decision with real costs.
Inspect, transfer and secure upgrade authority.
Understand the trade-off between upgradeability and immutability.
Publish an Anchor IDL and generate a typed TypeScript client.
Connect a React application to browser wallets through Wallet Standard.
Keep private keys inside the wallet while requesting approved transactions.
Classify transaction failures and give users useful next steps.
Keep network, program and client configuration aligned.
Publish a launch backed by verifiable on-chain evidence.

The main lesson was that deployment does not finish when the program reaches mainnet.

A production program needs clear ownership.

Its upgrade authority needs to be protected.

Its interface needs to be discoverable.

Clients need a reliable way to call it.

Users need a safe way to approve transactions.

Failures need to be understandable.

The address in Explorer proves that the program is live.

Everything around that address determines whether anyone can use it with confidence.

Revisit the Arc 13 challenges

Day 85: Deploy your program to mainnet-beta and verify its live address

Day 86: Inspect and secure your program’s upgrade authority

Day 87: Publish the IDL and generate a typed TypeScript client

Day 88: Build and test a wallet-connected React frontend on devnet

Day 89: Turn wallet and transaction failures into useful error messages

Day 90: Bring the deployment, client and frontend pieces together ahead of launch

Day 91: Publish the launch with verifiable on-chain proof

Arc 12 Catch-up: Advanced Testing and Security

Matthew Revell — Tue, 28 Jul 2026 15:15:46 +0000

Security bugs on Solana do not always come from obscure runtime behaviour or complicated cryptography.

Often, a program trusted the wrong account, accepted the wrong authority, or assumed that two pieces of state belonged together without proving it.

Arc 12 was about finding those assumptions before an attacker does.

Across Days 78–84, we audited our own code, tightened account validation, wrote transactions designed to break the program, used property-based testing and fuzzing to search for edge cases, and reproduced a real class of account-substitution exploit.

The rule running through the whole arc was simple:

Every account and input is untrusted until the program proves otherwise.

We began by auditing our own code

The first challenge took us back to an Anchor program we had already written.

Until now, we had mainly tested whether its instructions worked when the client supplied the right accounts. This time, we looked at each instruction from the other direction.

What prevents the client from supplying the wrong ones?

For every account in every #[derive(Accounts)] struct, we asked two questions:

Does this account have the correct owner?
If it authorises an action, has it signed the transaction?

Those checks sit underneath much of Solana program security.

An account can contain data that looks exactly as expected and still be unsafe to trust. It might be the right type of account in the wrong context, another user’s vault, or a token account tied to a different mint.

It might also be a different account containing data designed to look legitimate.

Anchor can enforce many of the checks we need.

Signer<'info> requires an account to have signed.

Account<'info, T> checks that the expected program owns the account and that its data matches the expected Anchor type.

PDA constraints verify that an account was derived from the required seeds.

Relationship constraints check that accounts belong together.

The danger appears when we step outside those protections without adding the missing validation ourselves.

There are legitimate reasons to use UncheckedAccount. It does not mean the account is automatically unsafe.

It means Anchor is not checking it for us.

Anchor even requires a /// CHECK: comment explaining why leaving the account unchecked is safe. The responsibility has visibly moved into our code.

By the end of the audit, we had a method we could apply to any instruction:

List every account.
Write down what the program assumes about it.
Find the type, constraint or code that enforces that assumption.
Flag anything the program simply takes on trust.

Security bugs often appear where the developer knows something should be true but the program never checks it.

Anchor constraints made those assumptions enforceable

The next challenge gave us an intentionally insecure vault withdrawal and asked us to fix it.

The secure version needed to establish that:

The authority had signed.
The vault belonged to our program.
The vault was the expected PDA.
The supplied authority matched the authority stored in the vault.
Any account being changed was writable.

We could perform some of those checks inside the handler. Anchor gives us a better place for most of them: the accounts struct.

The hardened instruction used:

Signer<'info> to require a signature.
Account<'info, Vault> to check ownership and account type.
seeds and bump to verify the vault PDA.
has_one = authority to connect the stored authority to the live signer.
mut to require writable access where state would change.

Anchor evaluates those constraints before the handler runs.

If the supplied accounts do not satisfy them, the instruction logic never starts.

The Web2 comparison is validation at the edge of a service. Authentication, schema validation and authorisation happen before untrusted input reaches the code that changes important state.

Anchor’s account constraints play a similar role.

They also make the security model easier to review. Someone reading the accounts struct can see which signer is required, how the PDA is derived and which accounts must be related.

Comments and client-side checks cannot provide the same protection.

A client can be replaced.

A comment can become outdated.

A runtime constraint applies to every transaction.

Then we tried to break the program

Most tests begin with the expected path.

A user deposits funds.

The balance increases.

The correct authority withdraws.

The balance decreases.

Those tests prove that the program works when everyone follows the rules. They say much less about what happens when someone deliberately breaks them.

Day 80 changed the job of the test suite.

Using LiteSVM, we wrote transactions that behaved like attacks.

We tried to withdraw with the wrong authority, substitute another account for the expected PDA, and withdraw more than the vault contained.

Each test challenged a specific security claim:

Only the recorded authority can withdraw.
Only the canonical vault PDA is accepted.
An excessive withdrawal cannot underflow the balance.

It was not enough to assert that the transaction failed.

A transaction can fail for irrelevant reasons. The setup might be wrong. An account might be missing. The instruction might never reach the validation we wanted to test.

So we checked the error too.

A wrong authority should fail with the authority error.

A substituted PDA should fail its seed constraint.

An excessive withdrawal should return the intended balance or arithmetic error.

That distinction matters.

“The attack did not work” is useful.

“The intended defence stopped the attack” is much better evidence.

This matters most for instructions that move assets, change authorities, close accounts, perform arithmetic with user-supplied values, use PDA signing or make Cross-Program Invocations.

For each one, the test suite should ask uncomfortable questions.

What happens if the wrong person signs?

What happens if nobody signs?

What happens if the account is valid but belongs to someone else?

What happens if two individually valid accounts have no valid relationship?

What happens at zero or at the maximum value?

What happens when instructions run in an order we did not expect?

The accounts struct gives us the outline of the security model.

The adversarial tests try to violate it.

Property tests searched beyond the attacks we imagined

Adversarial tests are still limited by our own ideas.

We test the wrong signer because we already know signer checks matter.

We test an excessive withdrawal because we know underflow is possible.

We test the wrong PDA because we understand account derivation.

Less obvious failures often appear in awkward values or unexpected combinations of otherwise valid actions.

Day 81 introduced property-based testing and fuzzing to search a much larger space.

A normal test begins with a specific example:

Deposit 10 into a balance of 20 and expect 30.

A property test begins with a rule:

A successful deposit must never reduce the balance.

If the deposit would overflow, the operation must return an error rather than wrap around.

Using proptest, we expressed that rule in pure Rust and let the framework generate many combinations of values.

That included values near zero, values close to the u64 limit and combinations we would be unlikely to choose by hand.

When a property failed, the tool reduced the input to a smaller counterexample.

A huge random value might reveal the bug, but a minimal failing case usually makes it easier to understand.

The focus moves away from listing examples and towards stating what must always remain true.

For a vault, useful properties might include:

A deposit never reduces the balance.
A withdrawal never increases it.
A failed instruction leaves state unchanged.
A user cannot withdraw more than the vault contains.
Only the recorded authority can withdraw.
No valid sequence of operations creates or loses funds unexpectedly.

These are invariants: rules that should survive every valid state transition.

That makes them especially useful when the bug appears only after a sequence of instructions rather than in one isolated call.

Trident extended the same idea into the Anchor program itself.

Instead of testing only pure Rust arithmetic, it generated instructions and values, exercised the program, and checked the properties we supplied.

That allowed it to explore unusual sequences of deposits and withdrawals, generated account combinations, failed transactions and boundary values.

The developer still decides which rules matter.

The fuzzer searches for a sequence that breaks them.

When it finds one, the counterexample should become a named regression test.

That gives us a useful workflow:

State an invariant.
Let the fuzzer search for a counterexample.
Understand the failure.
Fix the program.
Add the failing case to the permanent test suite.

Fuzzing finds the case.

The regression test makes sure we do not forget it.

We reproduced an account-substitution exploit

Day 82 turned the arc’s central warning into a working exploit.

We built a deliberately insecure program that read configuration data from an unchecked account.

The account looked valid.

Its data had the expected shape, and the values were where the program expected them to be.

But it was not the account the program should have trusted.

Because the instruction checked the data without properly establishing the account’s identity and ownership, it accepted a forged configuration and allowed an unauthorised result.

This reproduced the broad class of mistake seen in incidents such as Cashio and Wormhole: trusting a supplied account without proving that it was the account the program expected.

The details differed.

Cashio involved a broken chain of trust around supplied accounts.

Wormhole accepted a substituted account in place of the real Instructions sysvar, allowing the attacker to bypass signature verification.

The shared lesson is that convincing data is not enough.

The program must establish which account supplied it.

In our exercise, the fix was small.

We replaced the unchecked configuration account with Account<'info, Config>.

Anchor then checked that the expected program owned the account and that its data matched the expected Anchor type before the handler read it.

A different account could still contain similar data.

It could no longer pass validation.

This is why ownership and identity are part of the meaning of account data on Solana.

A configuration account owned by our program is program state.

Similar data in an account controlled elsewhere is untrusted input.

Without the right checks, vulnerable code may not see the difference.

The strongest fixes were often structural

A recurring theme throughout the arc was that security fixes do not always require more handler code.

Often, the cleaner answer is to choose account types and constraints that reject the bad request before the handler runs.

Use a checked account type instead of manually reading an unchecked account.

Declare PDA seeds rather than comparing addresses later.

Use has_one to enforce an account relationship.

Use checked arithmetic rather than assuming values will remain within the expected range.

There will always be business rules that constraints cannot express, but structural protections have an important advantage: they apply regardless of which client sends the transaction.

A well-behaved frontend does not make a program secure.

Someone can always construct the transaction directly.

The program has to defend itself.

We turned the arc into a security checklist

By Day 83, we had audited an existing program, hardened its constraints, written malicious transactions, generated edge cases and reproduced an account-substitution exploit.

The next challenge was to turn that work into something we could use again.

We published a practical Solana security checklist on DEV.

It covered checks such as:

Verify the owner and type of every account whose data is read.
Require signatures for authority actions.
Validate PDAs with the intended seeds and canonical bump.
Bind related accounts with constraints such as has_one.
Validate token-account mint and authority relationships.
Use checked arithmetic.
Test overflow, underflow and rounding.
Treat unchecked accounts as high-risk inputs.
Review the accounts and programs supplied to every CPI.
Write adversarial tests for instructions that move assets or change authority.
Check that attacks fail for the expected reason.
Add property tests for important invariants.
Fuzz high-value instruction sequences.
Preserve discovered failures as regression tests.

The exact checklist will vary from one program to another.

The useful change was replacing a vague final review with a repeatable process.

Instead of asking, “Does this look secure?”, we could ask:

Where is account ownership checked?

Which authority must sign?

How is the PDA verified?

What prevents two unrelated accounts from being used together?

What happens at the arithmetic boundary?

Which test attempts an unauthorised withdrawal?

Which properties must always remain true?

Those questions are easier to answer, review and revisit.

Explaining the checks made us understand them properly

The final two days focused on communicating what we had learned.

That matters in security work because it is possible to copy a constraint without understanding the threat it addresses.

Writing the checklist forced us to connect each protection to a concrete failure.

Signer<'info> matters because including an account in a transaction does not mean its owner approved the action.

Account<'info, T> matters because valid-looking data does not prove that the right program owns the account.

seeds and bump matter because the client can supply another account unless the program verifies the expected PDA.

has_one matters because two accounts can each be valid while having no valid relationship to one another.

Checked arithmetic matters because an attacker can choose values normal users never would.

Adversarial tests matter because successful transactions do not prove that malicious ones are rejected.

Property tests and fuzzing matter because we cannot write down every possible input and sequence.

A useful security explanation should say more than which Anchor attribute to add.

It should explain the assumption, how an attacker could violate it, and how the program prevents that from happening.

Day 84 asked us to reduce the longer checklist to a short X thread or LinkedIn post.

That meant choosing the checks that mattered most and backing them up with evidence from the week: a failing attack test, the forged configuration accepted by the insecure program, the same account rejected after the fix, or a counterexample found through generated testing.

The result was more useful than a general list of security advice.

It showed that we could identify an attack, reproduce it, fix it and prove that the fix worked.

What Arc 12 taught us

Arc 12 moved us from checking whether our programs worked to testing whether they could be abused.

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

Audit instructions for missing owner, signer and relationship checks.
Use Anchor types and constraints to enforce account validation.
Write adversarial tests and check that they fail for the intended reason.
Describe important rules as properties and invariants.
Use fuzzing to find cases we would not write by hand.
Turn discovered counterexamples into permanent regression tests.
Reproduce and fix an account-substitution exploit.
Build and share a reusable security checklist.

The main lesson was that the accounts supplied to an instruction are claims made by the transaction.

This is the authority.

This is the vault.

These accounts belong together.

This data is genuine.

This amount is safe to process.

The program has to verify each claim before acting on it.

Account ownership, signer checks, PDA derivation, relationship constraints and checked arithmetic provide that verification.

The tests show whether it holds up.

Adversarial tests cover the attacks we already understand.

Property testing and fuzzing search for the cases we missed.

Reproducing an exploit shows what one unchecked assumption can allow.

A secure program does not depend on the client doing the right thing.

It assumes someone will eventually try the wrong thing and is ready to reject it.

Revisit the Arc 12 challenges

Day 78: Audit your Anchor program for missing owner and signer checks

Day 79: Harden an insecure withdrawal instruction with Anchor constraints

Day 80: Write adversarial LiteSVM tests that try to break your program

Day 81: Use property-based testing and fuzzing to find unknown edge cases

Day 82: Reproduce and fix an account-substitution exploit

Day 83: Publish a practical Solana security checklist on DEV

Day 84: Turn the checklist into a social post or thread

Arc 11 Catch-Up: Composing Solana Programs with CPIs

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

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

In Arc 9, we wrote our first Solana program.

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

But our programs were still mostly working alone.

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

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

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

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

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

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

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

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

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

Our first CPI called the System Program

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

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

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

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

That distinction matters.

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

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

Every CPI needs three things:

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

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

The required accounts were the sender and recipient.

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

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

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

The caller requests an operation.

The callee validates the request.

The callee remains responsible for the state it owns.

Signer authority can flow into an inner call

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

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

The CPI did not invent new authority.

It passed along authority that already existed in the transaction.

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

That gives us an important boundary:

A CPI cannot arbitrarily escalate account privileges.

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

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

Token-2022 followed the same pattern

The next exercise moved from transferring SOL to minting tokens.

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

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

The call needed:

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

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

Token-2022 then applied its own rules.

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

Our program did not need to recreate any token logic.

It only needed to assemble a valid request.

That is the larger value of learning the CPI pattern.

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

The System Program already knows how to transfer SOL.

Token-2022 already knows how to manage token supply.

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

A CPI still crosses a real program boundary

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

But the called program does not simply trust the caller.

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

The caller decides what it wants to request.

The callee decides whether that request is valid.

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

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

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

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

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

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

PDA signing gave the program its own authority

The first two CPIs used wallet signers.

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

The next challenge introduced a different situation.

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

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

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

Withdrawing from the vault raised a harder question.

The vault was a PDA.

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

The answer was a PDA-signed CPI.

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

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

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

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

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

That is the core of PDA signing.

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

Signer seeds are not secrets

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

They are not.

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

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

The program ID is part of the derivation.

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

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

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

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

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

The program decides when that authority may be exercised.

Programs can call other custom programs

The first exercises called established Solana programs.

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

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

The second program invoked that instruction through a CPI.

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

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

That demonstrated an important boundary.

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

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

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

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

One program can provide a focused capability.

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

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

The IDL becomes a contract between programs

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

It needs to know:

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

Anchor describes that interface in an IDL.

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

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

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

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

But changes to that interface can break integrations.

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

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

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

The whole call stack remains atomic

A CPI does not create a separate transaction.

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

Consider an instruction that:

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

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

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

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

Everything succeeds together or everything is rolled back.

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

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

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

Breaking CPIs showed where integrations fail

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

We tested three common categories of failure:

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

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

Wrong signer seeds

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

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

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

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

When debugging, the key question is:

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

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

Wrong accounts

Every instruction expects a particular set of accounts.

Those accounts may need to be:

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

Passing the wrong account often produces an Anchor constraint error.

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

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

It is the contract the caller must satisfy.

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

Wrong program ID

The caller must also invoke the correct program.

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

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

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

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

This is one reason typed accounts are valuable.

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

Transaction logs reveal the call stack

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

The transaction logs show the sequence of execution:

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

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

Most CPI bugs come from one of two places:

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

Useful questions include:

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

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

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

Writing the explanation forced us to choose the important part

The final two days moved from implementation to communication.

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

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

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

The challenge instead asked us to choose one clear thesis.

One possible framing was:

A CPI is a function call with a guest list.

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

Another focused on the major conceptual jump:

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

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

The public explanation needed:

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

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

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

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

What Arc 11 taught us

Arc 11 moved us from isolated programs to composed systems.

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

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

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

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

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

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

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

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

That is what CPIs make possible:

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

Revisit the Arc 11 challenges

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

Arc 10 Catch-Up: Designing Solana State with PDAs

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

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

Arc 9 gave us our first Solana program.

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

But the counter account had a limitation.

It used a randomly generated keypair for its address.

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

It becomes awkward once we want one counter per user.

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

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

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

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

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

A PDA gives program state a predictable address

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

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

The address did not tell us:

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

PDAs solve this by deriving an address from known inputs.

In JavaScript, we can derive one using findProgramAddressSync:

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

The inputs here are:

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

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

That is the first important property: determinism.

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

The second important property is that every byte matters.

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

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

Changing it again to bob produces another:

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

Restoring the original seed gives us the original PDA again.

That small experiment made the model tangible.

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

A PDA has no private key

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

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

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

That means there is no corresponding private key.

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

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

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

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

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

A PDA is an address before it is an account

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

We have not.

Derivation only calculates an address.

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

That gives us two separate steps:

Derive the address.
Initialise an account at that address.

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

But the distinction is useful when debugging.

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

Adding the user creates one counter per wallet

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

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

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

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

Now the PDA depends on both:

the fixed namespace counter
the public key of the user

Wallet A gets an address derived from:

"counter" + wallet A public key

Wallet B gets an address derived from:

"counter" + wallet B public key

Because the public keys differ, the resulting PDAs differ.

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

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

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

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

It can derive the address again whenever it needs it.

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

Anchor can create the account at the derived address

We expressed that seed scheme inside our Anchor accounts struct:

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

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

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

Several constraints work together here.

init tells Anchor to create the account.

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

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

seeds declares how the PDA should be derived.

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

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

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

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

The initialisation handler can then populate those fields:

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

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

    Ok(())
}

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

The handler only needs to write the initial state.

That follows the same pattern we saw in Arc 9:

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

The bump completes the derivation

The bump can feel mysterious when we first encounter it.

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

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

findProgramAddressSync returns both results:

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

Anchor normally handles this search for us.

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

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

bump = counter.bump

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

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

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

Seeds are validation rules

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

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

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

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

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

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

    pub user: Signer<'info>,
}

Before the handler runs, Anchor can:

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

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

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

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

The account constraints declare the invariant once:

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

The handler can then remain focused on the state change:

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

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

    Ok(())
}

The seed constraint proves we received the expected address.

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

Together, they protect the counter from substitution.

A spoofing attempt showed the security boundary

We tested those constraints by deliberately passing the wrong account.

Wallet A had its own counter PDA.

Wallet B had a different counter PDA.

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

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

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

They did not match.

The instruction failed before the handler executed.

That test made the security role of PDAs much clearer.

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

Global state needs a different seed scheme

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

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

For that, we added a configuration PDA:

seeds = [b"config"]

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

That makes it suitable for singleton state.

Our config account stored fields such as:

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

Now the program had two kinds of state:

one global configuration account
one counter account per user

The config account could hold program-wide policy.

The counter account could hold user-specific data.

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

A program might have:

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

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

Constraints let us express relationships and business rules

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

For example:

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

pub admin: Signer<'info>,

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

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

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

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

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

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

The handler does not need to contain a separate conditional:

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

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

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

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

These constraints run before the handler.

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

Singleton initialisation needs an explicit governance decision

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

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

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

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

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

Depending on the program, that authority might be:

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

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

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

That decision still belongs to the program.

Closing an account completes the state lifecycle

Creating an account costs lamports.

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

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

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

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

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

The familiar constraints still protect the account.

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

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

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

The handler itself can be empty:

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

Once the instruction completes, Anchor:

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

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

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

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

It also shows the full lifecycle of program state:

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

Seed design defines the state namespace

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

First, we derived counters for two users using:

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

The two wallets produced two different addresses.

That is the behaviour we wanted.

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

[b"counter"]

Both wallets now produced the same address.

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

The problem was our design.

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

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

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

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

Including a user public key creates user-scoped state.

Including a mint creates mint-scoped state.

Including two asset addresses could create one account per pair.

Using only a fixed seed creates a singleton.

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

Almost identical seeds are still different seeds

We also tried small changes to the seed bytes:

counter
counters
Counter
counter\0

Each produced a different PDA.

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

It only sees bytes.

That means:

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

This makes seed conventions worth planning.

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

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

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

Writing the explanation exposed the gaps

The last two days moved away from program code.

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

That meant describing:

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

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

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

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

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

Why is the address predictable?

Why can nobody hold its private key?

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

Why does a seed constraint prevent account substitution?

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

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

What Arc 10 taught us

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

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

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

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

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

But the surrounding design became much more useful.

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

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

Global policy lived at one predictable config address.

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

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

That is the lasting lesson from Arc 10.

PDA design is state-model design.

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

Revisit the Arc 10 challenges

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

Welcome to Epoch 4: Shipping and Exploring

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

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

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

Arc 13 is seven days on that part.

Mainnet is not just another cluster

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

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

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

The Rosetta Stone

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

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

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

The seven days

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

What you'll have at the end

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

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

Joining

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

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

Epoch 2 content creator challenge

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

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

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

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

The prize categories

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

Best DEV post
Best YouTube video

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

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

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

There are a couple of other rules, too:

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

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

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

Arc 9 Catch-Up: Writing Your First Solana Program

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

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

And we make a pretty big shift.

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

Arc 9 changes the angle.

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

The program we built was deliberately simple: a counter.

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

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

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

So, let's get into the details.

Anchor gives us a framework for Solana programs

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

The principal Solana equivalent is Anchor.

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

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

A counter is enough to learn the shape

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

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

The program starts with an initialize instruction.

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

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

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

    Ok(())
}

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

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

But there is a lot happening around that small handler.

That setup lives in the accounts struct.

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

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

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

This is one of the first big Anchor lessons.

The instruction handler tells us what the program does.

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

In this case, it says:

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

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

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

The account is the program's state

The counter data itself lives in a custom account.

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

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

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

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

The count field stores the number.

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

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

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

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

Incrementing the counter introduces authorization

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

That happens through an increment instruction.

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

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

    Ok(())
}

Again, the handler itself is easy enough to follow.

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

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

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

It is the account constraint.

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

    pub authority: Signer<'info>,
}

The key line is this:

#[account(mut, has_one = authority)]

mut says the counter account can be changed.

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

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

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

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

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

So the instruction has two parts working together:

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

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

LiteSVM makes the tests feel like normal development

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

That is where LiteSVM came in.

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

For this arc, that was exactly what we needed.

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

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

The first useful test followed the happy path:

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

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

It sends transactions to the program.

The program receives accounts.

The account data changes.

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

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

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

The happy path is not enough

At this point, the program worked.

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

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

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

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

So the next test was more interesting:

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

That test proves the authority rule is actually doing something.

The important line was still this:

#[account(mut, has_one = authority)]

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

The failure test proves the wrong wallet cannot.

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

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

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

Breaking the program proved the tests mattered

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

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

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

First, we removed the authorization rule.

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

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

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

And it did.

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

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

That is a different kind of bug.

The program runs, but writes the wrong state.

Finally, we broke initialization by not storing the authority.

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

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

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

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

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

Sometimes you have to work backwards:

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

The counter example was small, but the lesson scales.

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

What Arc 9 taught us

Arc 9 was not really about building a counter.

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

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

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

That is a meaningful shift from the earlier arcs.

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

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

The next limitation is addressability.

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

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

That is where Program Derived Addresses come in.

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

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

Revisit the Arc 9 challenges

Learn Solana the Fast Way

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

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

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

But many Solana concepts have useful parallels with traditional development.

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

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

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

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

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

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

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

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

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

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

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

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

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

Solana starts from a different place.

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

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

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

On Solana, that proof happens through signatures.

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

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

Try it

Create your devnet wallet

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

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

A Solana wallet is an identity that can sign actions.

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

2. API calls and commands: transactions and instructions

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

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

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

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

So the rough mapping is:

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

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

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

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

Try it

Send and inspect a devnet transaction

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

The key idea is:

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

Submit your completed challenge so your progress is visible.

3. Database records and stored state: accounts

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

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

Solana also stores state, but the model is different.

State lives in accounts.

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

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

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

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

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

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

Try it

Inspect a Solana account

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

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

A place where on-chain state lives.

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

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

One table might define the asset:

name
symbol
decimal precision
total supply rules

Another table might track balances:

user ID
asset ID
amount

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

A mint defines the token.

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

That distinction matters.

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

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

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

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

Try it

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

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

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

As you do it, keep this model in mind:

The mint defines the asset. Token accounts hold balances.

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

5. Media files and metadata records: NFT metadata

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

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

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

NFTs use a similar split.

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

For that, you need metadata.

Metadata gives clients human-readable information such as:

name
symbol
description
image
attributes
collection information

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

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

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

Try it

Add metadata to an asset

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

Look for the split between:

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

The goal is to understand this:

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

6. Middleware and business rules: Token-2022 extensions

In Web2, business rules usually live in your application.

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

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

Token-2022 changes that.

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

For example, a token can be configured to:

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

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

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

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

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

Try it

Create a fee-bearing token

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

As you work through it, answer three questions:

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

The key idea is:

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

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

7. Backend logic and tests: programs and Anchor

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

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

On Solana, that logic lives in programs.

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

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

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

With Anchor, you define:

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

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

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

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

Try it

This one builds up over two short challenges.

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

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

The goal is to understand this:

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

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

Keep going with 100 Days of Solana

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

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

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

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

Each one gives you a piece of the model.

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

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

Arc 8 Catch-Up: Middleware Inside the Token

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

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

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

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

Arc 8 made the model explicit.

The whole arc hangs off one idea:

Token extensions are like middleware that lives inside the asset.

For Web2 developers, that is the shift worth noticing.

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

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

That changes the shape of the system.

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

The middleware is not next to the token.

It is part of the token.

Token rules should not depend on every app remembering them

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

A marketplace might charge a platform fee.

A fintech app might show yield.

A loyalty system might prevent points from being transferred.

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

Usually, the rule lives somewhere in your application.

You might write:

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

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

But that is the weak point.

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

Token-2022 takes a different approach.

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

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

This is not middleware sitting in your app stack.

It is middleware baked into the asset.

Transfer fees are enforced by the mint

Arc 8 started with a fee-bearing token.

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

The important part was not the percentage.

It was where the rule lived.

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

The fee configuration lived on the mint.

That means the token itself carried the rule:

When this token moves, apply this fee.

For Web2 developers, the contrast is familiar.

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

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

That is a meaningful difference.

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

That is the first big Arc 8 lesson:

The rule travels with the token.

The fee lifecycle is transfer, withhold, withdraw

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

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

transfer → withhold → withdraw

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

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

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

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

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

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

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

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

The important thing is what you did not build.

No custom program.

No payment processor flow.

No webhook.

No cron job.

No separate fee table.

The protocol enforced the fee and stored the withheld amount.

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

Composability means extensions share the same mint

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

This is where the middleware analogy becomes more powerful.

A token can have more than one rule.

The mint can say:

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

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

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

A fee might belong to a payments service.

Interest might belong to a financial calculation service.

Metadata might belong to an asset database.

Restrictions might belong to an access control system.

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

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

But the product lesson is simpler:

A token can be configured with multiple behaviors at once.

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

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

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

That is why the two features can coexist cleanly.

The fee changes what happens during transfer.

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

Those are different layers of behavior on the same asset.

Interest is a view, not a background job

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

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

A scheduled job updated the balance.

A database row changed.

A ledger entry was added.

A batch process applied interest overnight.

Token-2022 does not need to work that way.

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

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

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

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

The lesson is:

Display can be computed from state without constantly rewriting state.

For Web2 developers, that is a useful mental shift.

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

Arc 8 forced that distinction into the open.

Reading mint configuration is part of building

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

It was auditing the mints already created.

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

That is the Solana version of inspecting a production schema.

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

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

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

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

That is part of the Token-2022 pitch.

The behavior is public.

The configuration is verifiable.

The rules cannot be silently swapped inside a private backend.

That is also why auditing matters.

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

That last part is important.

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

Non-transferable tokens are useful because they fail

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

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

But not every token-like thing should be transferable.

A course certificate should not be sellable.

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

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

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

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

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

The transfer fails.

That failure is the feature.

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

if token.non_transferable:
    reject transfer

But that depends on every path using the same API.

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

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

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

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

Same mint model. Same token accounts. Same CLI.

Different product meaning.

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

Token-2022 is configuration, but not casual configuration

A tempting takeaway from Arc 8 would be:

Token-2022 lets you add features with flags.

That is true, but incomplete.

The better takeaway is:

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

That distinction matters.

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

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

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

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

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

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

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

Those are not just CLI questions.

They are product, governance, and integration questions.

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

Writing turns extensions into patterns

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

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

You can list extensions all day:

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

But a list is not a mental model.

A useful post needs to show the pattern.

For Arc 8, the pattern was a trilogy:

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

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

It shows the range of what extensions can do.

One changes transfer economics.

One composes transfer economics with display behavior.

One changes whether transfer is allowed at all.

That is the story.

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

Those details matter because they prove the learning.

Not:

“I learned Token-2022.”

More like:

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

That is useful developer storytelling.

What Arc 8 sets up

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

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

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

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

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

From here, the question becomes more practical:

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

That is the mindset to carry forward.

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

Arc 7 Catch-Up: Building NFTs from First Principles

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

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

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

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

Arc 7 took that model into NFTs.

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

The whole arc hangs off one idea:

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

For Web2 developers, that is the shift worth noticing.

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

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

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

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

NFTs are not separate from tokens

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

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

That means two choices matter immediately:

decimals = 0
supply = 1

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

Supply of one means there is only one unit.

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

So the final step is to disable the mint authority.

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

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

But the analogy only goes so far.

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

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

Metadata turns a token into something recognizable

The first NFT in Arc 7 was intentionally plain.

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

That is where metadata comes in.

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

That gives us a two-layer model:

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

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

That split matters.

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

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

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

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

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

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

An NFT collection is an on-chain relationship

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

In Web2 terms, this is easy to understand.

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

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

nft.collection_id = collection.id

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

Strictly speaking, there are four related pieces:

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

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

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

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

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

The arc’s useful mental model was simple:

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

That is the NFT version of a foreign key relationship.

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

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

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

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

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

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

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

Provenance is something you can inspect

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

It was auditing the collection.

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

Arc 7 made the idea concrete.

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

That last step matters.

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

This NFT points to collection C.

A safer check is closer to:

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

That is what makes the relationship more than vibes.

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

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

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

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

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

That is also why the CLI work matters.

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

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

That is how NFTs stop feeling like magic.

Mutability is a design choice

Arc 7 then moved from creation to mutation.

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

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

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

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

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

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

But for other assets, mutability might undermine trust.

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

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

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

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

They are hybrids.

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

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

NFTs are records with ownership, display, and history

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

A better bridge is:

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

That framing is much more useful.

A normal application might have unique records everywhere:

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

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

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

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

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

Start with the record.

Then ask:

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

Those are product questions, not just blockchain questions.

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

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

Writing forces the model to become simple

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

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

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

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

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

That is enough.

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

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

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

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

Not hype.

A model.

What Arc 7 sets up

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

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

That is the real shift.

Arc 5 taught us to create and manage tokens.

Arc 6 taught us to design token behavior with extensions.

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

From here, the question becomes more practical:

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

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

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