Create a Solana wallet you can actually use: persist it, reload it, and track its balance over time.
Create your own Solana identity from scratch and fund it with test SOL: your first step toward building real on-chain applications.
Now that your wallet works, look at how its balance is handled in code.
Connect to a real browser wallet, get user approval, and display a live address and balance
Turn on-chain data into a live browser experience by building a dashboard that shows any address’s balance and recent transactions.
Write-up something you’ve learned in the first week of Solana
Amplify your own and others’ 100 Days of Solana content
Read live data from Solana by fetching the balance of any address on the public devnet.
Read real on-chain activity by fetching and exploring the latest transactions for any address on Solana.
Deepen your understanding of how Solana accounts compare to Web2 databases.
Bridge the gap between testing and reality by querying a single address across devnet and mainnet to see how the same code retrieves unique balances and histories from separate networks.
Share what you’ve learned in week 2!
Share what you’ve learned this week with the world.
Learn how Solana transactions compare to HTTP requests.
Make your first SOL transfer!
Turn your one-off CLI transfer into a reusable Node.js tool with validation, balance checks, and Explorer output.
Upgrade your transfer tool from a black box to a live tracker—watch your transaction move from processed → confirmed → finalized in real time, handle failures properly, and get a verifiable on-chain receipt.
What happens when things go wrong?
Share what you’ve learned about transactions.
Get social with your transfer tool!
Every wallet, token, NFT, and smart contract on Solana is just an account with the same core structure. Today you’ll inspect them directly from the CLI and see what’s really stored on-chain.
Build your own mini Solscan from scratch and learn to decode the five core fields that define every Solana account.
Decode raw Solana account bytes into real, readable data and see what’s inside.
Explore Solana’s System Program, native programs, and sysvars to see how different account types are structured under the hood.
Use Solana Explorer to browse the live network, follow accounts and transactions, and find something interesting hidden in plain sight.
Join the Epoch 1 writing challenge with today’s writing task.
Get social with your explorer.
Create your first Solana token on devnet, mint a supply, and inspect how token mints and token accounts work on-chain.
Create a branded Token-2022 token with on-chain metadata, mint a supply, and transfer it to another wallet.
Create a Token-2022 mint that automatically withholds a transfer fee, then collect that fee from the recipient account.
Create a token that behaves less like a database record and more like a tiny product system: named, transferable, and able to collect fees automatically.
Create a Solana token that cannot be transferred, then prove the rule works by trying and failing to send it to another wallet.
Write a DEV post about what you learned in this Arc!
Share your learnings from this Arc with other develoeprs!
Build a token where every account starts locked, then selectively approve who can hold or receive it.
Before you build more tokens, learn how to inspect the Token-2022 configurations you’ve already created and compare their extensions, authorities, and on-chain costs.
Create a Solana credential that works more like a real certificate: it belongs to one wallet, cannot be passed around, and can still be revoked by the issuer.
Create the simplest possible NFT on Solana: one indivisible token, one owner, and no way to mint another.
Turn yesterday’s empty 1-of-1 token into a real, viewable NFT by adding on-chain metadata, an image, attributes, and a locked supply.
Build a real Token Extensions NFT collection by creating one group mint, minting two member NFTs, and linking them on-chain.
Inspect your Solana NFT like a database record and verify that its metadata, extensions, and collection link are really there on-chain.
Mutate your Solana NFT’s metadata on devnet and watch each on-chain change appear in Explorer as live state, not a static artifact.
Share what you’ve learned about Solana NFTs
Help other developers learn about Solana NFTs
Create a Solana token that charges a transfer fee automatically, with no custom smart contract code.
Transfer your fee-bearing Token-2022 mint, watch the protocol withhold its fee on chain, then withdraw those fees back with a single CLI command.
Stack transfer fees and interest on one Token-2022 mint to see how Solana lets a token charge when it moves and grow while it sits still.
Today you’ll inspect your Token-2022 mints like a database schema, using spl-token display to verify exactly which extensions live on chain.
spl-token display
Build a Token-2022 badge that works like a certificate of completion: once it lands in an account, it cannot be sent, sold, or moved.
Turn a week of Token-2022 experiments into a public DEV post that shows what you built, why it matters, and what each extension is for.
Spread the word about your DEV post.
Scaffold your first Solana program with Anchor and see what changes when you move from sending instructions to writing the code that receives them.
Move from “my program runs” to “my program manages state” by creating your first on-chain account and testing it locally with LiteSVM.
Build the Solana version of an authenticated update route: create a counter, let its owner increment it, and prove both calls work in one end-to-end test.
In a backend app, you would test that one user cannot modify another user’s data. Today, you do the Solana version: prove the wrong wallet cannot increment someone else’s counter.
A test suite earns trust when it fails for the right reasons. Today, you break your Anchor program on purpose and watch your tests prove they are doing real work.
Nothing exposes fuzzy understanding faster than trying to explain your own code. Today, you publish what you built, what your tests proved, and what writing it up reveals you still need to learn.
You built the counter. You tested the happy path. You proved the wrong wallet gets blocked. Today, you turn that private progress into something people can actually see, share, and remember.
On Solana, programs need a way to store state without relying on a keypair generated by the client. This challenge shows how that works: derive an address from known inputs, then prove it changes only when the inputs change.
Build per-user state on Solana: use PDAs to map each wallet to its own account, then test that two users can update their own state independently.
Today your Solana program gets guardrails: an admin, a pause switch, and tests that prove the wrong calls are rejected before state changes.
On Solana, creating state means locking up a refundable storage deposit. Today you add a close instruction that deletes a counter account, returns the SOL to its owner, and proves the account is really gone.
Today you test PDA seeds the practical way: compare per-user and global addresses, try a few near-misses, then watch Anchor reject a spoofed account.
Write up what a week of PDAs taught you, and turn your counter program into an explainer that helps Web2 developers understand deterministic Solana accounts.
Turn yesterday’s PDA writeup into a social post that helps another developer understand Solana.
Teach your Anchor program to call the System Program and send SOL with its first CPI.
Mint Token-2022 tokens from your own Anchor program instead of doing it from the command line.
Today you’ll build a vault with no private key, then make your program withdraw SOL from it anyway.
Write two Solana programs, then prove one can change state by calling the other instead of being called directly.
Break three working CPIs on purpose, then learn to read the logs well enough that the next failure gives you a direction instead of a dead end.
Turn five days of CPI practice into a short DEV post that explains the mental model you wish you had on Day 71.
Share what you’ve learned this week!
Audit your Anchor program like a production API: find which accounts prove ownership, which prove authority, and which ones an attacker could slip past you.
Yesterday you found the on-chain version of missing auth checks. Today you fix it like validation middleware: move the rules to Anchor constraints so bad accounts never reach your handler.
Happy-path tests prove your vault works for the right user; today you write the tests that prove the wrong signer, wrong account, and impossible withdrawal all get rejected for the right reason.
Your unit tests check the inputs you thought to try; today you let the test runner generate thousands more and find the edge case that breaks your program.
Today you rebuild the mistake behind the Wormhole hack: trusting an account before proving it is real.
You’ve found the bugs. Now build the checklist that stops them reaching production.
Adapt your Solana security checklist into a clear, practical thread for other developers.
You’ve tested it, attacked it, and fixed it. Now it’s time to ship it.
Take control of the key that can rewrite your Solana program by inspecting, transferring, and restoring its upgrade authority on devnet.
Publish your program’s IDL on-chain, then use it to generate a typed TypeScript client your frontend can actually work with.
Connect a real wallet to your React app, show its devnet balance, and send a transaction from the browser.
Learn how to handle common Solana transaction errors in your frontend.
Turn your wallet failure experiments into a DEV post that helps other developers write clearer, more useful transaction errors.
Publish a launch post that explains what you built and links to the live program on mainnet.
Build a read-only AI agent that turns plain-English questions into the Solana RPC calls you’d normally write yourself.
Give your AI agent a scoped wallet—then enforce a hard spending limit in code, like an IAM policy for on-chain payments.
Turn your Solana program into an API for AI agents by exposing its reads, writes and guardrails through an MCP server any compatible client can use.
Add a backend-style policy layer to your Solana agent so every transfer is checked against allowlists and spending limits before anything gets signed.
Run an autonomous Solana wallet workflow like a background worker: inspect state, act within policy, recover from failure and log every decision.
