标签：#100daysofsolana

I spent the last two weeks thinking like an attacker. I wrote tests whose only job was to make my own programs fail. I ran a fuzzer across thousands of generated inputs looking for the lamport value nobody would choose by hand. And I rebuilt the missing owner check that was at the center of the $326M Wormhole exploit, in a throwaway program, in a test, so I could watch it work and then watch the one-line fix stop it cold. This checklist is what I would hand to past me on day one of that work. Run it top to bottom before any Anchor program goes to mainnet. Who this is for You are writing Solana programs in Anchor. You understand accounts, PDAs, and CPIs. You have read the Anchor docs. What you do not yet have is a systematic way to check that you have not missed the failure modes that are specific to Solana's runtime, an account model where any account can be passed into any instruction, arithmetic that wraps silently in release builds without protection, and cross-program calls that trust whatever program ID you hand them. This checklist is that systematic check. It is not a substitute for a professional audit on high-value programs. It is the thing you run before you even consider requesting one. The Wormhole anchor Before the list, the story that explains why account validation sits at the top. In February 2022, an attacker drained $326M from the Wormhole bridge. The root cause was a single deprecated function, load_instruction_at — that read a sysvar account's contents without first checking that the account was actually the real instructions sysvar. The attacker passed in a forged account they controlled. The program read it, trusted it, and authorized a mint it should have refused. The fix was a single word: switch to load_instruction_at_checked , which verifies the account's address before reading it. Every item in this checklist traces back to that same principle: never read an account's contents until you have confirmed its identity. The items below are just

This is a submission for Weekend Challenge: Passion Edition Target categories: Best use of Snowflake...

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

You already understand tokens. Extensions are just middleware for your money. If you have ever worked with Stripe, you know the pattern. You start with a simple charge: send money from point A to point B. Then you add features — subscriptions, transfer fees, metadata on invoices, compliance checks. Each feature is a separate Stripe product or API call, and wiring them together is your job. Solana's Token Extensions Program is the same idea, but at the blockchain protocol level. Instead of bolting features on top of a basic token after creation (which Solana does not allow), you declare every capability upfront, and the runtime enforces it automatically. No smart contract to write. No backend service to maintain. Just configuration flags at creation time. What is a token extension? A token extension is an optional feature you enable when you create a token mint. Under the hood, each extension reserves extra bytes in the mint's on-chain account. Those bytes store configuration — an interest rate, a fee percentage, a metadata URI — and the Solana runtime reads them during every transaction. The original SPL Token Program is simple. It stores supply, decimals, and authorities. The Token Extensions Program ( TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb ) is a superset. It stores everything the original does, plus additional data for each extension you enable. Extensions map directly to Web2 concepts Extension Web2 Analogy What It Does Transfer Fees Payment processor fee Deducts a % on every transfer Interest-Bearing Savings account APY Displays time-adjusted balance Metadata Product catalog entry Stores name, symbol, URI on-chain Default Account State KYC gating All accounts start frozen; you thaw approved users Non-Transferable Professional license Tokens cannot be sold or transferred Permanent Delegate Admin revoke power Issuer can burn tokens from any holder A concrete example Here is the exact command I ran to create a token with transfer fees, interest-bearing, and m

I spent a week building a counter program in Anchor — the Rust framework for writing Solana programs. By the end I had two instructions, one authorization constraint, and a test suite I could actually trust. Here is what I built, how I tested it, and the moment I proved the tests were real. Start Here: The Accounts Struct If you come from Web2, this is the part that looks the strangest: #[derive(Accounts)] pub struct Initialize { #[account( init, payer = authority, space = 8 + Counter::INIT_SPACE, )] pub counter : Account , #[account(mut)] pub authority : Signer , pub system_program : Program , } In a Web2 backend, your handler receives a request object and talks to a database. On Solana, there is no database; there are accounts. Every account your instruction needs to read or write must be declared upfront, before the handler runs. Anchor validates them before your code ever executes. Here is what each field does: counter — the account being created. The init constraint tells Anchor to make a CPI to the System Program, allocate 8 + Counter::INIT_SPACE bytes, and fund it from authority . The 8 is for the discriminator Anchor stamps on every account so the program can later verify "this is mine." authority — the wallet signing and paying for the transaction. mut because its SOL balance is decreasing to fund the new account. system_program — required any time you create accounts. Anchor checks that the address matches the real System Program. The accounts struct is the schema. The handler is the logic. The Handlers pub fn initialize ( ctx : Context ) -> Result { let counter = & mut ctx .accounts.counter ; counter .authority = ctx .accounts.authority .key (); counter .count = 0 ; Ok (()) } ctx.accounts gives you typed access to every account declared in the struct. The handler is short because Anchor already did the hard work: allocating the account, checking the signer, paying the rent. Your code just sets the initial values. pub fn increment ( ctx : Context ) -> Resu

Every Solana program eventually hits the same question: where do I put my data, and how do I find it again later? Programs are stateless, so a program's data lives in separate accounts, each at an address. The moment you store something, you owe an answer to a problem databases tend to hide from you: what address does this live at, and how does the program find it again tomorrow? Program Derived Addresses are Solana's answer. The name scares people off, but the idea is mostly "an address you compute instead of remember, that only your program can control." The problem, in code Say each user gets a counter account. The normal way to make an account is to generate a fresh keypair and store data at its public key: import { Keypair } from " @solana/web3.js " ; const counter = Keypair . generate (); // counter.publicKey is something random, e.g. 7Hx4...9fT // create the account at that address, write count = 0 It works. But the address is random, so nothing connects this user to that address . Tomorrow, when the user comes back to increment, how does your program find their counter? You're forced to keep a lookup table somewhere: // the mapping you now have to store and never lose const counters = { " 9fYL...user1 " : " 7Hx4...9fT " , " B2k9...user2 " : " Qz1p...4dR " , // ...times ten thousand users }; Lose that table, lose the data, even though the accounts are right there on chain. You're storing files in a warehouse and writing the shelf number on a sticky note. The fix: compute the address from what you already know What if the address were a function of the user instead of random? Give a function the word "counter" and the user's public key, and it hands back a fixed address. Same inputs, same address, every time. No table. That's a PDA. PDAs are 32-byte addresses derived deterministically from a program ID and a set of seeds. The seeds are the meaningful inputs you pick (here, "counter" + the user's key). With @solana/web3.js , the library Anchor's client uses: im

If you have made it this far in 100 Days of Solana, you have been working in JavaScript and on the command line. You have been calling RPC methods, building instructions, signing transactions, and reading and writing account data in JavaScript, and most recently minting and sending tokens and NFTs from the CLI. Either way, you have been driving Solana with tools that let you assign a value and move on with your life. Soon the ground shifts. You are going to open a file called lib.rs , and it is going to be Rust, and for a day or two it is going to feel like you forgot how to program. That feeling is normal, it is temporary, and it is not a sign you are in the wrong place. Here is the thing nobody says out loud: you do not need to learn all of Rust to write Solana programs. Rust is a big language with a steep reputation, but the slice of it that shows up in an Anchor program is small and repetitive. You will see the same handful of patterns on almost every line. Learn those patterns and the wall turns back into a floor. This post is that handful. Not a Rust course, just the parts you need to read your first Anchor program and understand what every line is doing. Next week we start Arc 9, the Anchor introduction, where this all becomes real. This week is about making the language stop being scary before you get there. Why it feels like a wall JavaScript is dynamically typed and garbage collected. You write const x = 5 , you never tell anyone it is a number, and when you are done with it the runtime quietly cleans up. The language trusts you and sorts out the consequences at runtime, which is why a typo surfaces as undefined is not a function three minutes into a demo. Rust is the opposite philosophy. It is compiled and statically typed, so every value has a type the compiler knows about before the program ever runs, and it has no garbage collector, so it tracks who is responsible for every piece of memory through a system called ownership. The trade is blunt: Rust mak

Before this week, NFTs on Solana weren't new to me. I've previously worked with Programmable NFTs ( pNFTs ) and even built projects that integrate them. However, most of my experience was centered around the Metaplex ecosystem, so I tended to think about NFTs through that lens. What surprised me during this learning arc was discovering how much can be built directly with Token Extensions. By creating NFTs from the token level upward, I gained a much deeper understanding of the underlying primitives that make digital assets work on Solana. The Mental Model: What Is an NFT on Solana? As developers, we often interact with NFTs through SDKs , frameworks , and marketplace tooling. Those abstractions are useful, but they can hide what's actually happening on-chain. This week helped me simplify the model: An * NFT * is fundamentally a token mint configured with: A supply of one Zero decimals Metadata describing the asset Optional relationships to collections or groups Using Token Extensions, many of these capabilities can be attached directly to the token itself rather than relying on additional programs or infrastructure. That shift in perspective was one of the biggest takeaways from this challenge. What I Built Over the course of this arc, I created an NFT on Solana Devnet using Token Extensions and explored several capabilities that I had never implemented directly before. The process included: Creating a mint configured as an NFT Adding metadata using the Metadata Extension Minting a single token Creating a collection using the Group Extension Associating the NFT with the collection through the Member Extension Auditing the account structure and extension data on-chain Updating metadata after the NFT had already been created One of the most valuable parts of the exercise was inspecting the accounts directly instead of relying solely on SDK abstractions. For example: spl-token initialize-metadata \ <NFT_MINT> \ "My First NFT" \ "MNFT" \ https://example.com/metadata.jso

I spent 7 days learning Solana token extensions. Here's what clicked, what surprised me, and the code you need to build tokens that can't be traded but can be revoked. The Problem (In Web2 Terms) Imagine you work in HR. You issue an employee a digital badge proving they're a certified security officer. Here's what you'd want: The badge stays in their wallet — they can't trade or sell it Only they can use it If they leave the company or fail a compliance check, you can revoke it silently without their permission The badge metadata (name, symbol, type) is on-chain and permanent You could build this with centralized databases and APIs. On Solana, it's just three extensions on a token mint . What Are Token Extensions? Solana's Token-2022 program lets you attach additional behaviors to any mint at creation time. Think of them like middleware for tokens. Before extensions, every token was the same — a mint with supply and decimals, token accounts holding balances, and transfer instructions. Extensions let you add rules on top : Extension What It Does Use Case Transfer Fee Charge a percentage on every transfer Protocol revenue, marketplace commissions Non-Transferable Make tokens unmovable after minting Soulbound badges, credentials, memberships Permanent Delegate Let the issuer burn tokens from anyone Revocable credentials, subscriptions with expiry Metadata Store name, symbol, URI on-chain Self-describing tokens, no external API needed Default Account State Freeze all new accounts by default Compliance gates, KYC verification The critical rule: extensions must be declared at mint creation . You cannot add them later. This forces you to think about your token's full lifecycle before deploying — which is good design discipline. The Journey: Three Combinations That Matter Over the past week I built three different token types. Here's what I learned from each. Day 34: Transfer Fees (The Marketplace Token) A token that charges 1% on every transfer, withheld automatically and

How combining Non-Transferable and Permanent Delegate extensions changed my understanding of digital ownership on Solana. Imagine earning a high rank in an online game. You can use it. You can benefit from it. Other players can see it. But you cannot transfer that rank to someone else. If you break the game's rules, the game company can revoke it. And if the game gets acquired by another company, authority over that rank can be handed over to a new administrator. That was the closest mental model I found for understanding one of the most interesting things I built this week on Solana: a credential token using Token-2022 extensions. What are Token Extensions? One thing I've learned during this phase of the challenge is that Token-2022 is not just about creating tokens. It allows you to define behaviors directly at the token level through extensions. Instead of relying on application logic to enforce rules, the token program itself can enforce them. For this experiment, I combined two extensions: Non-Transferable — prevents ownership from being transferred to another wallet. Permanent Delegate — gives a designated authority the ability to manage the token even after it has been issued. Individually, those are useful. Together, they create something that behaves less like a currency and more like a credential. The Transfer That Was Supposed to Fail After creating the token, I tried transferring it. spl-token transfer Gn5PZzwDENvpQESaFwgVqzCUFba5sSka59iLtjFTYNvz 1 $THIRD_PARTY \ --owner ~/recipient-wallet.json \ --fee-payer ~/.config/solana/id.json \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --fund-recipient --allow-unfunded-recipient The result: Recipient: ErYcpQYcpdoaaiufrB3MqQE2QaVEhoACZGcssppszPpY Recipient Token Account: 8CvyoKt11UbkWYRVXey6UKK2gqQcvVvbh9Lv3crzo8C3 Funding ATA: 8Cvyokt11UbkWYRVXey6UKK2qqQcvVvbh9LV3crz0803 Status: ❌ Transaction failed during simulation Error: Transfer is disabled for this mint (Token-2022 restriction) What I liked a

If you have been following the 100 Days of Solana challenges, you have already worked with tokens. You created mints, set up token accounts, transferred SOL, and explored token extensions. But there is a distinction that comes up constantly in web3, and understanding it properly will change how you think about everything you build going forward. Fungible and non-fungible tokens. You have probably heard these terms before, especially NFTs. But what do they actually mean on Solana, and how does the same token system handle two very different concepts? What makes something fungible Fungible just means interchangeable. One unit is identical to another unit. If I have 10 USDC and you have 10 USDC, ours are exactly the same. It does not matter which specific USDC tokens I hold because they are all worth the same and behave the same way. We could swap them and nothing changes. This is how most things you are used to work. A dollar bill is fungible. A liter of petrol is fungible. One unit of SOL is the same as any other unit of SOL. When you built token transfers in the challenges, you were working with fungible tokens. You did not need to care about which specific tokens moved, just how many. Fungible tokens are used for currencies, stablecoins, utility tokens, governance tokens, loyalty points, in-game currencies, and anything where the quantity matters more than the individual unit. What makes something non-fungible Non-fungible means unique. Each token is different from every other token, even if they come from the same collection. If I have NFT #42 from a collection and you have NFT #87, those are not interchangeable. They might have different images, different properties, different rarity, or different utility. Think of it like event tickets. Two tickets to the same concert are not the same if one is front row and the other is in the back. They came from the same event, but each one is distinct. Non-fungible tokens are used for digital art, collectibles, membership pa