DEV Community: Siddhant Chavan

Three Token-2022 mints in one week: fees, yield, and soul-bound #100DaysOfSolana

Siddhant Chavan — Wed, 17 Jun 2026 16:46:01 +0000

If you have never touched Solana before, here is the one thing you need to know going in: Token-2022 is the upgraded SPL token program, and extensions are how it works. Instead of writing custom smart contract logic to enforce a royalty fee or an interest rate, you flip a flag when you create the mint. The rule travels with the asset, enforced by the protocol itself, visible to every wallet and program that touches it. Think of it as middleware baked directly into the currency, not bolted on next to it.
Over the last week I shipped three distinct mints to devnet. Each one adds a different extension. Here is what I built, what I ran, and what happened.

Mint 1 — Transfer fee (Days 50–51)
Mint address: G37ZvuZ9wQRnagSDGHb985qqaTsWWxPeuZPPE951LNZ9

View on Solana Explorer
Extension: TransferFeeConfig — 100 basis points (1%), maximum fee 1,000,000 tokens
bashspl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
create-token \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 10000000 \
--decimals 6
When would you actually reach for this? Think protocol treasury skims on a stablecoin, royalties on a creator token, or a community currency that automatically funds a DAO wallet on every trade. The fee is not enforced by your API or your database — it is enforced by the validator. There is no way to route around it.
The lifecycle I tested: mint supply → transfer 1,000 tokens to a fresh wallet → check the recipient's account for the Transfer fees withheld field → withdraw those withheld fees back to my own account. The whole loop, no middleware, no webhook.

Mint 2 — Interest-bearing stacked on transfer fee (Day 52)
Mint address: F15ZkWji8PsQM7VrgnRNLUh1n8W8CQJp71TbDkSUsi2a

View on Solana Explorer
Extensions: InterestBearingConfig (5,000 bps / 50% APR) + TransferFeeConfig (100 bps, same as above)
bashspl-token create-token \
--program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
--decimals 6 \
--transfer-fee-basis-points 100 \
--transfer-fee-maximum-fee 1000000 \
--interest-rate 5000
One thing I want to be honest about here, because it confused me at first: the interest-bearing extension does not mint new supply. It adjusts the UI amount — the number your wallet shows you — based on elapsed time and the configured rate. The raw on-chain balance stays the same. I waited 30 seconds between two spl-token accounts calls and watched the displayed number tick up from 1000004.816733 to 1000007.985649 with no transactions in between. That is the extension doing the compounding math. If you are building a lending protocol or a synthetic yield token, you need to understand this distinction before you go anywhere near production.
The spl-token display output on this mint showed both extensions side by side in the same TLV blob — Interest-bearing at 5,000 bps and Transfer fees at 100 bps. Two behaviors, one create-token invocation.

Mint 3 — Non-transferable / soul-bound (Day 54)
Mint address: 7u4f9idiq865z2pYndPsPjpiQN95p4uh7fHdTgKkvWgE

View on Solana Explorer
Extension: NonTransferable
bashspl-token create-token --program-2022 --enable-non-transferable
This one is different in kind. The first two extensions are quantitative — they layer financial behaviors onto a currency primitive. Non-transferable is qualitative. It turns the same mint, the same accounts, the same CLI into an identity object. The closest Web2 analogy is a certificate of completion stapled to a profile page that no one can detach or resell.
I minted one token to myself, generated a throwaway keypair as a recipient, pre-funded their token account so the transfer could actually reach the program, then ran the transfer. Here is what came back:
Error: Client(Error { kind: RpcError(RpcResponseError {
message: "Transaction simulation failed: Error processing Instruction 0:
custom program error: 0x25" ...
logs: ["Program log: Instruction: TransferChecked",
"Program log: Transfer is disabled for this mint", ...
Transfer is disabled for this mint. The rejection came from the Token-2022 program itself, not from my application layer. In Web2 you might enforce this with a database constraint or an API check — but anyone who talks to the database around your application can break that rule. Here the rule lives on the asset, inside the program, inside the validator. There is no around.
Running spl-token display on the mint confirmed it: the Extensions block shows Non-transferable with nothing else needed.

What surprised me
I expected extensions to feel like configuration knobs bolted onto a normal token. They do not. They feel like the token is the configuration. The non-transferable experiment especially landed differently than I expected — seeing the validator reject a transfer at the protocol level, not at the app layer, is the moment the mental model clicks. The error message is the feature.
If I were building something real today, I would reach for transfer fees for any protocol where the treasury needs to be funded trustless, and for non-transferable for anything credential-shaped: completion badges, access passes, reputation tokens that should not be liquid. The interest-bearing extension is the most nuanced of the three — powerful for display purposes, but you need to understand what it is and is not doing to use it safely.

100DaysOfSolana #solana #web3 #tutorial

What I learned minting NFTs on Solana with Token Extensions #100DaysOfSolana

Siddhant Chavan — Sat, 13 Jun 2026 11:48:43 +0000

What I learned minting NFTs on Solana with Token Extensions

Before this week, I thought creating a Solana NFT meant using a marketplace stack or relying on a separate metadata program. I wanted to understand what actually happens underneath.

It turns out an NFT on Solana is still built from the same token primitives I had already been working with: a mint, a supply of one, zero decimals, and extensions that add meaning directly on-chain.

This week I went from creating a basic 1-of-1 token to building a complete NFT with metadata, collections, and on-chain verification using Token Extensions.

The mental model: what an NFT actually is on Solana

The biggest shift was realizing that an NFT is not a completely different asset type.

At the core, it is still a token mint.

The difference is:

Supply is exactly 1
Decimals are 0
Mint authority is disabled so no more copies can be created

In Web2 terms, imagine creating a database row where the ID is unique, the quantity can never increase, and ownership history is tracked publicly.

The first NFT I created started with a simple mint:

solana config set --url https://api.devnet.solana.com

spl-token create-token --decimals 0

spl-token create-account [YOUR_MINT_ADDRESS]

spl-token mint [YOUR_MINT_ADDRESS] 1

spl-token authorize [YOUR_MINT_ADDRESS] mint --disable

After this, the token was technically an NFT, but it had no identity.

No name.
No image.
No metadata.

It was just an on-chain asset waiting for more information.

What I built: metadata, collections, and extensions

The next step was adding identity.

With Token Extensions, metadata can live directly with the mint account instead of depending on a separate metadata account.

The metadata extension allowed me to attach:

Name
Symbol
Image URI
Attributes

The flow looked like this:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --enable-metadata \
  --decimals 0

spl-token initialize-metadata \
  [YOUR_MINT_ADDRESS] \
  "First Light" \
  "LIGHT" \
  [YOUR_METADATA_URI]

Seeing the NFT appear in Solana Explorer with its own metadata was the moment it stopped feeling like a token experiment and started feeling like an actual NFT.

The next challenge was collections.

A real NFT usually belongs to something bigger. A collection is basically another mint that acts as the parent.

The Group extension creates the collection:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 \
  --enable-group

Then member NFTs reference that group using the Member extension:

spl-token initialize-member MEMBER_ONE_MINT COLLECTION_MINT

Now the relationship exists fully on-chain:

Collection → NFT members

Similar to a database foreign key connecting two tables.

The surprising part: what was different from Web2

Coming from Web2 development, I expected NFTs to be mostly application logic.

A database stores metadata.
A backend verifies ownership.
A frontend renders the result.

Solana flips a lot of that thinking.

The blockchain itself becomes the source of truth.

The mint account contains the structure.
Extensions define additional capabilities.
Explorer tools can directly read and display the data.

I also found it interesting that metadata is not just a static image attached forever.

The update authority can modify fields:

spl-token update-metadata [MINT_ADDRESS] name "Field Notes"

spl-token update-metadata [MINT_ADDRESS] rarity legendary

spl-token update-metadata [MINT_ADDRESS] rarity --remove

This felt very similar to updating a database record, except the change happens through a blockchain transaction.

What I would build next

After understanding the building blocks, the next step would be building an actual NFT application around them.

Some ideas:

A Flutter mobile app that creates and manages NFTs
An NFT dashboard that reads extensions directly from Solana
A creator platform where users mint collections without writing CLI commands
AI-generated NFTs with dynamic metadata updates

The biggest lesson from this week:

NFTs are not magic objects. They are carefully designed token structures with rules, ownership, metadata, and relationships.

Understanding the primitives makes the whole ecosystem easier to build on.

This post is part of #100DaysOfSolana. Follow along or jump in any day.

Beginner #DEV

From Interest-Bearing Assets to Soul-bound Credentials: My Deep Dive into Solana Token Extensions

Siddhant Chavan — Fri, 05 Jun 2026 14:58:02 +0000

One of the things that surprised me most while learning Solana is how much functionality can exist directly inside a token.

In traditional Web2 applications, features like interest accrual, transaction fees, user verification, account restrictions, and credentials are usually implemented through backend services, databases, and application logic. Developers spend significant time wiring these systems together and ensuring they work correctly.

Over the last five days of my #100DaysOfSolana journey, I explored how Solana's Token-2022 program approaches the same problems differently. Instead of building these features around a token, many of them can be built directly into the token itself through extensions.

Day 36 — Creating an Interest-Bearing Token

The first extension I explored was the Interest-Bearing Token extension.

At first, I expected the token balance itself to increase over time. What I learned was much more interesting.

The actual on-chain balance never changes. Instead, Solana stores an interest rate and uses time-based calculations to display an adjusted balance to users and applications.

This creates an experience similar to a savings account where your balance appears to grow continuously while the underlying ledger remains unchanged.

Some key takeaways:

Interest rates are configured in basis points.
Wallets calculate adjusted balances using elapsed time.
No additional tokens are minted automatically.
The extension acts as a display layer rather than modifying token supply.

It was my first look at how financial primitives can be implemented directly at the protocol level.

*Day 37 — Combining Multiple Extensions
*
After experimenting with individual extensions, I wanted to see what would happen if multiple extensions were combined into a single token.

I created a token that included:

Transfer fees
Interest-bearing balances
On-chain metadata

This was where the Token-2022 design really started to click for me.

Each extension operates independently while sharing the same mint account. The token could charge fees during transfers, display interest-adjusted balances, and carry its own metadata without any of the features interfering with one another.

The biggest lesson from this day was understanding that extension choices must be made when the mint is created. Solana allocates account space upfront, so planning matters.

*Day 38 — Building a Compliance-Gated Token
*
Financial systems often require permissions before users can transact.

Brokerage accounts require verification.
Payment apps may freeze suspicious accounts.
Many regulated assets require approval before transfers can occur.

To replicate this pattern, I experimented with the Default Account State extension.

Every new token account created for the mint started in a frozen state.

Nothing could be transferred, received, or burned until the freeze authority explicitly approved the account.

What made this powerful was that enforcement happened at the protocol level rather than inside application code.

Even if a frontend contained a bug, users still couldn't bypass the restriction because the blockchain itself enforced the rules.

This was my first exposure to how regulated asset systems can be implemented directly on Solana.

Day 39 — Reading Before Building

After creating several different token configurations, I spent a day inspecting and comparing them.

Instead of deploying something new, I focused on understanding what I had already built.

I examined:

Interest-bearing mints
Multi-extension mints
Default-frozen mints

Using the CLI, I reviewed extension configurations, authorities, metadata, fees, and account sizes.

One observation stood out immediately:

More extensions mean larger account sizes.

Larger accounts require larger rent-exempt deposits, which means every design decision has a cost attached to it.

This reinforced an important engineering lesson:

Before building new systems, understand the systems that already exist.

*Day 40 — Creating Revocable Digital Credentials
*
The most interesting experiment of the week involved combining two extensions I had never used before:

Non-Transferable
Permanent Delegate

Together, these allowed me to create a token that behaved like a digital credential.

The token could:

Be issued to a specific wallet
Never be transferred to another wallet
Be revoked by the issuing authority

This closely resembles real-world certificates, licenses, employee badges, or verified status systems.

A credential belongs to the recipient, but the issuing organization still retains the ability to revoke it when necessary.

Seeing this implemented entirely through token extensions was fascinating.

The token itself enforced ownership and transfer restrictions without requiring additional application logic.

What I Learned This Week

This week completely changed how I think about tokens.

I started by viewing tokens as simple units of value.

Now I see them as programmable assets capable of enforcing business rules directly at the protocol level.

Across these five days I learned how to build:

Interest-bearing financial assets
Fee-generating tokens
Compliance-gated systems
Multi-extension token architectures
Soulbound credentials with revocation mechanisms

The most valuable lesson wasn't a specific command or extension.

It was understanding that Token-2022 turns tokens into building blocks for entire applications.

Instead of asking, "What can my application do with a token?"

I'm starting to ask,

"What functionality can I move directly into the token itself?"

And that shift in perspective might be the biggest lesson I've learned so far in my Solana journey.

100DaysOfSolana #Solana #Web3 #Blockchain #Token2022 #BuildInPublic #DeveloperJourney

Week 5 of my #100DaysOfSolana challenge is complete 🚀

Siddhant Chavan — Wed, 03 Jun 2026 13:38:33 +0000

This week I built custom SPL tokens on Solana using the Token Extensions Program. I created tokens with on-chain metadata, configured protocol-level transfer fees, and even experimented with non-transferable (soulbound) tokens.

The most interesting moment was testing a non-transferable token and watching the blockchain reject the transfer attempt automatically. Seeing the protocol enforce the rule itself — without any custom backend or off-chain validation — completely changed how I think about token design.

I also explored transfer fee extensions and learned how economic rules can be embedded directly into the token standard instead of being handled by application logic.

Next week I'm diving deeper into how these token extensions interact with on-chain programs and real-world applications built on Solana.

All code is open source and documented as part of my learning journey:
GitHub: https://github.com/Siddhant0122/100-days-of-solana

Solana #Web3 #Blockchain #BuildInPublic #LearnInPublic #100DaysOfSolana

I Built My First Token on Solana — Here's What Actually Surprised Me #100DaysOfSolana.

Siddhant Chavan — Tue, 02 Jun 2026 18:42:37 +0000

I Built My First Token on Solana — Here's What Actually Surprised Me
This week I went from zero tokens to minting, transferring, charging fees, and locking tokens so they can never move. Here's what stuck with me.

Tokens don't live in your wallet
Coming from Web2, I assumed tokens would just... show up in your account. Nope. On Solana, every wallet needs a separate token account for each token it holds. One mint, one folder. It felt weird at first. Now it makes sense.
You can charge fees without writing a single backend
The Token Extensions Program has a built-in transfer fee. One flag at mint creation time:

spl-token create-token \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --transfer-fee-basis-points 100

That's a 1% fee on every transfer, enforced by the blockchain. No middleware. No payment processor. No way to bypass it.
You can make a token that literally cannot be transferred

spl-token create-token \ --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \ --enable-non-transferable

I minted 10, tried to send 5, and watched the transaction get rejected. Not by my code — by the program itself. Perfect for credentials, badges, or certificates that should belong to one person forever.

The biggest shift from Web2: these rules are set at creation and are permanent. You can't add a transfer fee to an existing token. You can't make a transferable token non-transferable later. It forces you to think about token design upfront, which is honestly a good constraint.

solana #blockchain #webdev #beginners #100DaysOfSolana

Share your explorer challenge #100DaysOfSolana

Siddhant Chavan — Sat, 30 May 2026 15:39:26 +0000

I opened Solana Explorer today and searched for the Jupiter v6 program.

What I saw surprised me.

It is marked Executable: Yes, has a balance of 6.19 SOL, and its actual bytecode lives in a completely separate account called Executable Data. The program itself holds no state at all.

That is Solana's account model in one screenshot. The logic lives in one account. The data lives somewhere else. They are never mixed.

Coming from Web2, this felt strange at first. Now it feels clean.

This is Jupiter's live transaction history on Solana Explorer.

Failed. Failed. Failed. Success. Success.

At first I thought something was broken. Then I read the instruction names. The failed ones are all trying to create token accounts that already exist. The successful ones are simple SOL transfers.

This is normal. Programs attempt things optimistically and fail fast. Failed transactions still cost a small fee. The network does not hide any of this. Everything is public and permanent.

This caught me off guard.

Jupiter's upgrade authority is not a single wallet. It is a Squads V3 multisig with 7 members and a 4 of 7 approval threshold.

That means 4 out of 7 keyholders have to sign before anyone can push an update to the program that handles billions in DEX volume.

You can verify this yourself on Solana Explorer. No trust required. Just a public address and the data it holds.

That is the whole point.

address: JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4

100DaysOfSolana #Solana #Web3

Solana's Account Model, Explained to My Past Self (A Web2 Dev's Guide) #100DaysOfSolana

Siddhant Chavan — Sat, 30 May 2026 11:59:32 +0000

Coming from Web2, Solana's account model felt completely backwards to me. No objects, no built-in state, no familiar patterns. After a 4 week of building on devnet, it finally clicked. Here's the short version I wish I had on day one.

Everything is an account

Wallet? Account. Smart contract? Account. The data that smart
contract reads and writes? Also an account.

They all live in the same flat key-value store. A 32-byte address maps to an account. That's it. No separate contract accounts vs wallets like Ethereum does. One model for everything.

Every account has five fields

Run "solana account

" in your terminal and you'll see
five things every time.

Lamports is the SOL balance. 1 SOL equals 1 billion lamports.
Everything on-chain works in whole numbers.

Data is a raw byte array. Empty for a basic wallet. Token balances, NFT metadata, and program bytecode all live here.

Owner is the program that controls this account. Only the owner can modify the data or move the lamports.

Executable is a simple true or false. True means this account is a runnable program. False means it holds data. That is literally the only structural difference between a smart contract and a wallet.

Rent epoch is deprecated. You will always see it set to the max value. Ignore it.

Programs don't store their own state

This is the part that trips up every Web2 developer, including me.

Solana programs are stateless. The program account holds compiled bytecode and nothing else. All state lives in separate data accounts that users pass in on every single call.

Think of it like a stateless REST API. The server holds no memory between requests. The caller sends everything the server needs to do its job. Same idea here, except the "data" being passed in are actual on-chain accounts.

The security model is simple

Only the owner program can modify an account's data or debit its lamports. The runtime enforces this, not your code. There is no auth middleware to forget. The account structure itself is the permission system.

Rent exemption

Every account needs to hold a small minimum balance to stay
on-chain, roughly 0.00089 SOL for a basic account. It is not
a fee. It is a refundable deposit. Close the account and you
get the lamports back.

You can check the exact amount by running "solana rent 0" in
your terminal.

The one analogy that ties it all together

Think of Solana as a filesystem. Accounts are files. Programs
are executables. Data accounts are documents. The System Program is the OS kernel that creates files and manages ownership.

Once that image lands, everything else starts to make sense.

Beginner #WEB3 #Solana #Blockchain #100DaysOfSolana

Building My First Solana Transfer CLI Tool | #100DaysOfSolana

Siddhant Chavan — Tue, 26 May 2026 17:35:33 +0000

Built a CLI tool that transfers SOL on Solana devnet and tracks the transaction through processed, confirmed, and finalised states.

This project helped me understand that Solana transactions are much more than just “sending crypto.” I learned how recent blockhashes work, why transactions need signatures, how confirmation levels actually matter, and what really happens after a transaction gets submitted to the network.

The most interesting part was watching the transaction lifecycle in real time and seeing how Solana moves from processed → confirmed → finalised.

Also spent time debugging failed transactions and honestly learned more from the failures than the successful transfers 😅

Built using Solana Kit + System Program on devnet.

📸 Terminal demo + Explorer screenshot attached
🔗 Explorer Link: https://explorer.solana.com/tx/2tQJ8YEwtTC7UdS5nYsHtRWV73LsiSR37vHEVTpJeiGGGEoXTotfX4SVGHnEvrhak8DvhFEy8G4eJLCsayrFNQGR?cluster=devnet

Solana #Web3 #Blockchain #BuildInPublic #100DaysOfSolana

What Learning Solana Transactions Actually Felt Like | #100DaysOfSolana

Siddhant Chavan — Tue, 26 May 2026 15:44:59 +0000

A few days ago, Solana transactions looked completely overwhelming to me.

I kept seeing terms like signatures, instructions, blockhashes, compute budgets, and account ownership everywhere, but none of it felt intuitive at first. Coming from a more traditional backend mindset, I was expecting transactions to work like a normal API request — send something, get a response, done.

Solana quickly showed me that it doesn’t work that way.

Over the past few days in my #100DaysOfSolana challenge, I spent most of my time experimenting with transactions on devnet. Some worked instantly, some failed for confusing reasons, and honestly, the failures taught me the most.

One thing that really changed my understanding was realising that a Solana transaction is more like an atomic state change than a simple request. Everything either succeeds together or fails together. There’s no “half success.” That mental shift took me time to understand.

I also started paying attention to details I normally would have ignored:

why transactions need signatures
why blockhashes expire
how instructions are bundled together
why compute limits matter
and how even transaction size affects development decisions

The most interesting part was exploring failed transactions on Solana Explorer and trying to understand why they failed instead of just retrying them. Sometimes it was balance issues, sometimes account problems, and sometimes timing-related issues because of expired blockhashes. Reading logs and debugging those mistakes made the concepts feel real instead of theoretical.

Another thing I noticed while learning Solana is how different the developer experience feels compared to Web2. In Web2, most complexity is hidden behind servers and APIs. On Solana, you’re much closer to the system itself. You actually see how accounts, programs, and transaction execution interact.

That was frustrating at times, but also what made it interesting.

Looking back, transactions were probably the first Solana topic that genuinely challenged the way I think about software systems. But after spending several days building, testing, breaking, and debugging them, I finally feel like I’m starting to understand what’s happening under the hood instead of just copying code blindly.

Still learning every day, but this part of the journey definitely made Solana feel “real” to me.

100DaysOfSolana #Solana #Blockchain #Web3

On day-10 I built something and it genuinely surprised me. 😲#100DaysOfSolana

Siddhant Chavan — Wed, 20 May 2026 18:42:22 +0000

I didn't expect this to work the way it did.
On Day 10 I built a Solana Dashboard — paste any wallet address and it pulls:
💰 Live SOL balance
📋 Complete transaction history
🔍 Full account data
But here's what actually blew my mind —
I never asked anyone for permission.
No API key. No login. No "request access" form. No terms of service to agree to. I just pointed my code at a public address and the blockchain handed me everything. Every transaction. Every balance. Every interaction. Out in the open.
Coming from Web2, this broke my brain a little. We're so used to data being locked behind auth layers, rate limits, and paywalls. But on Solana? The ledger is just… there. Public. Permanent. Readable by anyone.
That's not just a technical difference. That's a completely different relationship between code and data.
I built a dashboard expecting a fun project. I got a perspective shift instead. 🤯
🔗 GitHub link in the comments — try it with your own wallet address.
What surprised YOU most when you first touched blockchain data? I want to know. 👇

100DaysOfSolana #Solana #Web3 #BuildInPublic #SolanaDevs #Blockchain #LearnInPublic #DevCommunity #OpenSource

Week 2 of #100DaysOfSolana — Breaking down what I built and learned, day by day. 🔥

Siddhant Chavan — Wed, 20 May 2026 16:36:58 +0000

This week was packed. Here's exactly what went down:

📅 Day 8 — Reading Solana Data

Learned how to fetch and read on-chain data using a public address. The blockchain is fully transparent — you just need the right tools to query it. First time pulling live data felt like unlocking a superpower. 📖⚡

📅 Day 9 — Transactions in Solana

Went deep into how Solana transactions are structured, signed, and processed. Understanding the anatomy of a transaction — instructions, signers, recent blockhash — changed how I see every on-chain interaction. ✍️🔗

📅 Day 10 — Building a Solana Dashboard

Put Days 8 & 9 together and built a full dashboard that reads account data and transaction history from any public address. First real project of the challenge — turning raw blockchain data into something visual and usable. 📊🛠️

📅 Day 11 — Solana Accounts vs Traditional Databases

This one flipped my thinking. Solana accounts aren't database rows — they're more like files that store state, owned by programs. The shift from a Web2 database mindset to an on-chain storage model is real and essential. 🧠🗃️

📅 Day 12 — Devnet vs Mainnet

Understood the critical difference between Devnet and Mainnet — same code, completely different consequences. Knowing when and why to use each environment is foundational before you ship anything serious. 🚨🌐
5 days. 5 solid concepts. Each one building on the last.
The foundation is getting stronger — Week 3 is where it gets even more interesting. 🚀
Drop a 🔥 if you're also building on Solana!

100DaysOfSolana #Solana #Web3 #BuildInPublic #SolanaDevs #Blockchain #LearnInPublic #SolanaDeveloper

[Boost]

Siddhant Chavan — Mon, 18 May 2026 08:19:25 +0000