DEV Community: 100 Days of Solana

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

Turning Solana Skills Into a Web3 Career

Vincent Jande — Tue, 28 Jul 2026 18:05:35 +0000

There is a gap between being able to do technical work and being hired to do it. The first is a question of skill, and if you have spent months writing Anchor programs, deriving PDAs, making cross-program calls, and hardening code against real exploit classes, you have crossed that line already. The second is a question of evidence, and it is the part most self-taught developers underestimate.

The reason is structural. Hiring managers and recruiters make decisions with very little information. They cannot inspect what you know, so they rely on proxies: a portfolio they can open, a profile they can read, a message that arrives in their inbox. A developer with moderate skill and excellent evidence will get interviews that a stronger developer with no visible work never hears about. This is not a comment on fairness, it is simply how the process works, and understanding it changes what you do next.

This post covers two things: the roles that Solana development actually opens up, and the specific work of making your skills legible to the people who hire for them.

Where these skills lead

Solana engineering is not a single job. The work divides into a handful of directions that reward different temperaments, and job titles in this space are used loosely, so each path below includes the titles you are likely to see on a posting.

Smart contract and protocol engineering. Writing the on-chain programs themselves: designing account structures, writing instruction handlers, and implementing the logic that moves value. Protocols, DeFi teams, and infrastructure projects hire for this, and it rewards depth in Rust and Anchor more than breadth. An emerging specialization within it is agent-facing work, where software holds a wallet and transacts autonomously within limits a program enforces, and the people who understand both agent design and on-chain authorization are still few. Postings for this work usually read as Smart Contract Engineer, Protocol Engineer, Rust Engineer, or Blockchain Engineer.

Web3 full-stack engineering. This covers the distance between a deployed program and the person using it: connecting frontends to programs, integrating wallets, and building the payment and consumer flows people actually touch. Teams often find the role harder to fill than pure protocol work, because it asks for someone comfortable on both sides of the boundary, and most candidates are strong on only one. The emphasis shifts toward reliability and user experience, since the people using these products are not developers and will not tolerate a confusing failure. Roles appear as Full-Stack Engineer, dApp Developer, Frontend Engineer, or Product Engineer.

Security engineering and auditing. Reviewing programs for the vulnerability classes that account for most on-chain losses: owner and signer checks, arithmetic safety, account substitution, and authority confusion. These categories are learnable in a way that many security specialisms are not, and demand is steady because every protocol holding significant value needs review. Bug bounty work is the same skill applied independently, and it is worth knowing as an entry point, because a valid finding is valid regardless of who submits it, which lets you build a reputation before anyone has hired you. Titles here include Smart Contract Auditor, Security Engineer, and Security Researcher.

Infrastructure and developer tooling. Running the validators and RPC services applications depend on, indexing chain data into something teams can query, and building the libraries and clients other developers use. This is closer to systems and data engineering than to program development, and it suits people who were more interested in how the network runs than in what gets deployed to it. Open source contributions here are unusually visible to employers. This work is posted as Infrastructure Engineer, Platform Engineer, Data Engineer, or Site Reliability Engineer.

Trading systems and on-chain automation. Programmatic strategies that read chain state and act on it: market making, arbitrage, liquidation bots, and related searcher work. It rewards on-chain knowledge combined with disciplined off-chain engineering, and it is one of the few areas where independent results can substitute convincingly for employment history, because performance is measurable. Look for Quantitative Developer, Trading Systems Engineer, or Quant Engineer.

Developer relations and technical education. Writing documentation and tutorials, running workshops, and supporting developers building on a protocol. It requires genuine technical depth alongside the ability to explain things clearly, and teams value it because adoption depends on it. If you found that you enjoyed explaining what you were learning, that is a relevant signal. The common titles are Developer Advocate, Developer Relations Engineer, and Technical Writer.

Employment is also not the only route. Ecosystem foundations fund independent builders through grants, hackathons run frequently and pay meaningfully, and some developers move directly from learning into building something of their own. That path is less predictable than a salary, but it compounds into exactly the portfolio that makes you employable if you later decide you want a role.

These categories overlap more than the headings suggest. Auditors write programs to test their assumptions, tooling authors need protocol depth, and the strongest builders think adversarially about their own code. The useful takeaway is that the foundation you have built supports any of these directions, and you do not have to choose one permanently in order to start moving toward it.

Evidence: building a portfolio that does the work

Once you know which direction interests you, the question becomes how to demonstrate it. The most effective format is a portfolio at a single URL, and the emphasis on the URL is deliberate. A collection of repositories scattered across a GitHub profile requires the reader to do investigative work, and they will not. One link that opens onto organized, described work removes that friction entirely.

A few principles make the difference between a portfolio that gets read and one that does not.

Prioritize things that run. A program deployed to mainnet or devnet, presented with a link to its page on an explorer, carries more weight than source code alone, because deployment is proof that the work reached completion. Placing the explorer link beside the repository lets a reviewer confirm in seconds what would otherwise take them ten minutes.

Include your writing. If you have published explanations of what you built, whether tutorials, breakdowns, or notes on problems you solved, treat them as first-class portfolio items rather than afterthoughts. Technical writing demonstrates that you can communicate about your work, which is a substantial fraction of every engineering job and something most candidate portfolios fail to show.

Write for a reader in a hurry. A hiring engineer typically spends under a minute on an initial review. Each project needs a one-line description of what it does, a link to see it working, and a link to the code. Lead with your strongest work, because the first item is the one most likely to be read.

Collect it in one place. A simple personal site, even a single well-structured page, gives you one address to put on your profile, in applications, and in messages. That address is what converts a claim about your ability into something a stranger can verify.

Discoverability: a profile that works when you are not

A portfolio answers the question "is this person capable" for someone who has already found you. LinkedIn addresses the earlier problem of being found at all, since it remains where a large share of technical recruiting begins.

Your headline carries the most weight, because it appears in search results and beside every message you send. Something specific, along the lines of "Solana and Rust engineer building on-chain programs," tells a recruiter what you are in a single glance. A vague or aspirational headline wastes the most valuable line on the page.

Profile verification is worth completing. LinkedIn offers identity verification, and the resulting badge signals that you are a consistent, real person. In a field where recruiters encounter a high volume of anonymous and pseudonymous accounts, that signal quietly raises the baseline level of trust before anyone reads a word of your experience.

Beyond that, the mechanics are straightforward: make the portfolio URL visible rather than buried, and describe your experience in terms of specific artifacts, the programs you shipped, the work you completed, the writing you published. Specific descriptions consistently outperform general ones, because they give a reader something concrete to ask about.

Approaching the market directly

The step most developers skip is direct outreach, and it tends to be the highest-yield activity available to them. Applying through job boards places your application into a queue alongside hundreds of others, sorted by criteria you cannot see. Contacting a recruiter or an engineer directly puts you in a conversation.

Effective outreach is short and specific. It states who you are, what you build, links to evidence, and gives a reason you are contacting that particular person or company. The reason matters, because it distinguishes your message from bulk outreach and demonstrates that you did some research. Recruiters in a growing sector are actively searching for qualified candidates, and a message arriving with a working portfolio attached does a meaningful part of their job for them.

The two channels work best together. A strong profile makes you findable by people conducting searches, and deliberate outreach reaches the people who are not searching yet. Most early roles in this space come from one or the other, and often from the combination.

A realistic view of the market

The web3 job market is real and expanding, and it is also competitive, as any field worth entering tends to be. Learning the stack does not produce a job offer on its own; it produces the foundation and the raw material for evidence. What distinguishes the developers who find roles from those who do not is rarely raw technical ability at this stage, since candidates at similar experience levels tend to cluster closely. The difference is usually whether they made their work visible and initiated contact.

That is worth sitting with, because it reframes what remains. The demanding part, becoming someone capable of doing the work, is the part you have been doing for months. Presenting it well is a smaller, more mechanical task, and it is entirely within your control.

Where to start

If you want a concrete first move, collect what you have already built into a single page with live links, then update your headline to describe what you do now rather than what you did before. Those two changes take an afternoon and make every subsequent step more effective.

For roles, Solana's ecosystem job board lists protocol, tooling, and application positions across the network. If the security path interests you, following audit firms and bounty platforms will show you both the standard of work expected and the openings as they appear.

Whatever direction you choose, the most transferable thing you have built is not any single technical skill. It is the demonstrated ability to work at something difficult, consistently, over months. That is precisely what the work asks of you once someone is paying for it, and it is worth presenting as deliberately as everything else. #100DaysOfSolana

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

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

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

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

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

Devnet was a sandbox. Mainnet is not.

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

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

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

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

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

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

The one-way door: upgrade authority

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

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

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

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

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

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

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

Your program is now a public API

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

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

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

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

The mindset to carry in

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

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

A short version of what "ready" looks like:

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

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

Going further

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

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

Account Security on Solana, Made Simple

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

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

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

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

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

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

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

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

Question one: who owns this account?

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

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

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

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

Question two: did the authority actually sign?

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

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

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

How Anchor answers both questions for you

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

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

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

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

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

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

Binding accounts together: the constraints

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

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

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

The mental model to carry in

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

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

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

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

Going further

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

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

Cross-Program Invocations: How One Solana Program Calls Another

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

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

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

The problem: your program can't do everything itself

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

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

The idea: one instruction calls another program's instruction

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

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

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

invoke and invoke_signed: the two functions

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

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

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

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

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

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

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

The part that matters most: PDA signing is not cryptographic

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

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

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

How it looks in Anchor

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

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

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

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

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

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

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

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

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

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

A few things that trip people up

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

TL;DR

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

Going further

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

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

Epoch 2 content creator challenge

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

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

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

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

The prize categories

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

Best DEV post
Best YouTube video

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

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

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

There are a couple of other rules, too:

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

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

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