DEV Community: Vincent Jande

Fungible and Non-Fungible Tokens on Solana: Same System, Different Rules

Vincent Jande — Fri, 29 May 2026 18:40:51 +0000

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 passes, certifications, domain names, gaming items, real estate deeds, event tickets, and anything where the individual item matters more than the quantity.

How Solana handles both with the same system

This is where Solana does something interesting. On some blockchains, fungible and non-fungible tokens are completely separate systems with different standards and different smart contracts. On Solana, both run through the same Token Program (or the newer Token Extensions program, also called Token-2022).

The difference comes down to two configuration settings: decimals and supply.

A fungible token has a mint initialized with multiple decimals (typically 6 or 9) and a supply far greater than one. You can mint millions of fractional units from the same mint, and they are all interchangeable.
A non-fungible token is a mint initialized with exactly 0 decimals, where exactly one token is minted and the mint authority is then permanently revoked.

That second part is worth being precise about, because there is no "maximum supply" field you set when you create a base SPL mint. A mint has a supply value that simply increments every time you mint into it. You create the mint with 0 decimals, mint exactly one token to a token account, and then set the mint authority to None. Revoking the authority is what locks the total supply at 1 forever, guaranteeing that no more units of this specific token can ever be printed.

Same program, same mint account layout. The rules are enforced purely by how you configure the mint and what you do with the mint authority.

One nuance: at this level you have created a non-fungible token. Wallets and marketplaces do not yet recognize it as an "NFT" in the way you would see it on a marketplace. That recognition comes from the metadata and standard layer, which is what we cover next.

The role of metadata

If a non-fungible token is just a mint with a supply of one, how do you know what it actually represents? How do you attach an image, a name, or specific traits to it?

This is where metadata comes in. On-chain, a token mint is just a state account holding configuration details and balances. The metadata gives it context.

The long-standing approach is the Metaplex Token Metadata standard, which creates a separate metadata account cryptographically linked to the token mint via a Program Derived Address (PDA). This account holds the token's name, symbol, and a URI pointing to an off-chain JSON file containing the image and attributes. That JSON is typically stored on decentralized storage like Arweave or IPFS, though some projects use centralized hosting such as AWS S3.

Token Metadata is still widely used and is not deprecated. Interestingly, a large share of assets minted through it today are actually fungible tokens, since it is also the common way to give a fungible mint a name, symbol, and icon.

For new NFT projects specifically, the current recommended standard is Metaplex Core. Core uses a single-account design, storing all of an asset's data in one account instead of the separate mint, metadata, and token accounts the older model required. That cuts minting cost dramatically (on the order of 80 percent cheaper than Token Metadata) and ships with built-in features like enforced royalties and a plugin system for custom behavior. If you are starting a new NFT collection today, Core is usually where you should look first.

There is also the Token Extensions (Token-2022) path. By enabling the MetadataPointer and TokenMetadata extensions, you can store the name, symbol, and URI directly inside the mint account itself. The pointer says where the metadata lives, and the metadata extension holds the actual fields. In practice this is used most often for fungible and utility tokens, letting a stablecoin or reward token carry a native icon and tracking data without a separate metadata account or any cross-program coordination at creation.

So the honest map of the landscape is: Token Metadata (legacy, still common, heavily used for fungibles), Core (the modern recommendation for new NFTs), Token-2022 metadata extensions (great for fungible and utility tokens), and compressed NFTs for high-volume cases, which we will get to in a moment.

For fungible tokens, metadata is simple. You usually just need a name, symbol, and maybe an icon. For non-fungible tokens, metadata can be extensive because each token is unique and needs its own description, image, and properties.

Token accounts work the same way

Whether you are holding a fungible token or a non-fungible one, you need a token account for it. This is the same concept you learned in the challenges. Your wallet needs an Associated Token Account (ATA) for each mint you want to hold.

For fungible tokens, your token account has a balance that can go up and down as you send and receive tokens. For non-fungible tokens, your token account has a balance of exactly one. You either have it or you do not.

The mechanics are identical. Creating the account, paying rent, transferring tokens. The same code patterns you have been writing in the challenges apply to both. (Metaplex Core is the one exception worth noting, since its single-account model does not use a separate token account in the same way, but the fungible side and classic NFTs both follow the familiar ATA pattern.)

Editions, collections, and scale

Not every NFT is a complete one-of-one. Sometimes you want to create multiple copies of the same item but still have each one be individually trackable. Think limited edition prints. There are 500 of them, each one is numbered, but they all share the same artwork.

In the Token Metadata standard, this is handled through editions. A master edition can produce a set number of prints. Each print is its own mint with its own token, but they are all linked back to the original master edition.

Collections group related NFTs together. A collection is itself an NFT that acts as a parent. Individual NFTs reference the collection in their metadata, which is how marketplaces know that 10,000 different mints all belong to the same project.

Here is an important practical point that trips people up. Editions and one-mint-per-item NFTs do not scale cheaply. Each one is a real account that carries rent. So if your goal is something like 1,000 identical-but-individually-owned event tickets, minting a thousand separate full NFTs gets expensive fast.

For that high-volume case, the modern answer is compressed NFTs (the Metaplex Bubblegum standard). Compressed NFTs store ownership data in a Merkle tree rather than in a full account per token, which makes it possible to mint thousands or even millions of individually owned, transferable assets at a tiny fraction of the cost. This is the dominant approach for large drops on Solana today, and it is exactly what you would reach for in the 1,000-ticket scenario.

So the decision for "many of the same thing" is really: a handful of numbered prints can use editions, but anything at real scale should use compression.

Fungible tokens with NFT properties

The Token Extensions program blurs the traditional line between fungible and non-fungible tokens in powerful ways:

Non-Transferable Tokens: By initializing a fungible mint with the NonTransferable extension, you create assets that are locked to the recipient's wallet the moment they are minted. If a user earns 50 reputation points, those points are structurally fungible but behave like "soulbound" credentials because the runtime blocks any transfer instruction.
Mint-Linked Metadata: Before Token Extensions, detailed metadata was largely reserved for NFTs via Metaplex. Now, you can inject rich metadata directly into a fungible utility token or stablecoin mint, allowing wallets to display custom icons and tracking data natively.
Transfer Hooks: You can attach a custom program to a fungible token mint that executes additional logic every time a transfer occurs. A fungible token that checks an allowlist or verifies a KYC credential before allowing a transfer begins to behave like a restricted real-world security, changing its economic behavior entirely through code.

The categories are not as rigid as they seem. Solana gives you the building blocks and you decide how to combine them.

When to use which

If you are building something where every unit is the same and users care about quantity, use a fungible token. Currencies, points, credits, governance votes.

If you are building something where each item is unique and users care about the specific item they hold, use a non-fungible token. Art, collectibles, certificates, tickets, identity documents. For a brand-new collection, start with Metaplex Core. For high-volume drops, reach for compressed NFTs.

If you are building something in between, like a limited-edition with 100 copies or a membership tier with different levels, look at editions and collections, or explore how Token-2022 extensions can give you the behavior you need.

The good news is that the skills you are building in these challenges apply to all of it. The mint, token account, and transfer patterns are the same regardless of whether you are working with fungible or non-fungible tokens.

What is coming next

The upcoming challenges will take you deeper into how NFTs work on Solana, how to mint them, how metadata is structured, and how collections come together. Understanding the foundation covered here will make those challenges click faster.

Keep building. See you in the Discord.

100 Days of Solana is a free daily coding challenge: https://mlh.link/solana-100

Web3 Apps You Can Build With Token Extensions

Vincent Jande — Fri, 22 May 2026 20:07:47 +0000

In our previous articles, we covered how Web3 tokens get their value and broke down the new standards in What is Token 2022 and why Solana built it. You understand authorities, token accounts, and the extensions available.

Now the question is what you actually build.

Token extensions are building blocks for real products. Each extension solves a specific problem. By leveraging Token 2022 via modern client libraries, you can build applications from frontend or backend scripts that would have required custom smart contracts before.

Here are some app ideas, the extensions they use, and the tools to start building them.

1. Creator Subscription Platform

Subscribers hold a token that grants monthly access to exclusive content. The token cannot be resold or moved between wallets.

Extensions: Non-transferable tokens prevent resale; metadata stores the creator name, tier, and subscription period.

How it works: Create one mint per creator per subscription period, one for "Creator X - January 2026," another for February. When a user subscribes, bundle a USDC payment with a non-transferable token mint into a single atomic transaction.

Use one mint per period because Token-2022 metadata is mint-level, every holder of a given mint reads the same expiry. Gating access is then a direct read of the period from the mint's on-chain metadata against the current date.

To reclaim or burn subscription tokens directly, add PermanentDelegate at mint creation. The extension itself can never be removed once the mint is initialized, though the delegate authority can be rotated or set to None via SetAuthority.

Tools: @solana/kit, @solana-program/token-2022, Next.js or React.

2. Loyalty Rewards Program

A business issues loyalty points as tokens. Customers earn points on purchases and redeem them for discounts.

Extensions: Non-transferable tokens keep points tied to the customer; the business retains mint authority to issue new points; metadata displays the brand.

How it works: Each business gets its own token mint. The backend mints points directly into the customer's token account on purchase events. Customers connect their wallet to a redemption portal to spend points.

On-chain identity here is pseudonymous, not private, wallet balances and minting activity are visible to anyone. Non-transferability stops third parties from trading or seizing the points, but doesn't hide them from view.

Tools: @solana/kit, @solana-program/token-2022, Node.js, React, Solana Pay.

3. Regulated Investment Token

A real estate company tokenizes a property. Only verified investors can hold the token, and the company needs a way to freeze accounts and recover tokens if compliance requires it.

Extensions: Default account state can be set to frozen so new holders start out locked until KYC clears. Freeze authority handles ongoing compliance actions, like freezing an account that falls out of good standing. A permanent delegate provides a recovery path for legal scenarios. Metadata stores property details and links to legal documentation.

How it works: New investor token accounts start frozen and are thawed after the investor passes KYC. The freeze authority can re-freeze any account later if compliance requires it, and the permanent delegate handles court-ordered recovery if it ever comes to that.

Tools: @solana/kit and @solana-program/token-2022 for the mint, freeze actions, and delegate operations, plus a KYC provider API for investor verification.

4. In-Game Currency with Transaction Fees

Players earn an in-game currency through gameplay and trade it with each other. The studio automatically collects a small fee on every user-to-user transfer to generate ongoing revenue from the game economy.

Extensions: Transfer fees collect a percentage on every token movement; metadata handles branding like names, icons, and descriptions; mint authority is retained so the studio can inject new currency into the economy via gameplay achievements.

How it works: Fees are configured at mint creation and collected automatically on token transfers with no custom program or market smart contract required. When players send tokens to each other, the configured fee is withheld directly inside the recipient's token account.

Because fees accumulate quietly inside thousands of individual player accounts, the studio's withdraw-withheld authority can periodically collect these withheld amounts and pool them into a central treasury wallet, without touching player balances.

Tools: @solana/kit, @solana-program/token-2022, a game client SDK, and an administrative backend.

Patterns to Notice

@solana-program/token-2022 is often all you need. For loyalty, subscriptions, in-game currencies, and yield-bearing wrappers, you can usually compose instructions against it from @solana/kit and skip Rust. Reach for Anchor when you need to build custom programs or manage complex state logic that standard extensions don't cover.

Plan compatibility before mint creation. Not every extension pairs with every other extension. Some combinations are blocked because their behaviors conflict (for example, anything that gates or modifies transfers tends to clash with non-transferability). Most extensions can't be added after mint creation, so check the compatibility matrix in the Token-2022 docs before committing to a design.

"No Rust required" is not "no centralized authority required." Permanent delegate, freeze authority, mint authority, and withdraw-withheld authority are centralized controls encoded in extension config. If any are live on your token, make sure to state them clearly in your project's docs or UI.

Start thinking about what you want to build

You have the fundamentals. The app ideas above are starting points, take one, modify it, make it your own.

Keep building. See you on Discord.

100 Days of Solana is a free daily coding challenge: https://mlh.link/solana-100

What Is Token 2022 and Why Solana Built It

Vincent Jande — Fri, 15 May 2026 19:29:20 +0000

Last week, we examined the economic theories that underpin the value of Web3 tokens. This week, we are shifting our focus to the engineering reality of how these assets actually function on the Solana blockchain. As you begin building with tokens in the upcoming challenges, the nuances of account ownership and program logic will become the foundation of your development workflow.

The Library Model: Why One Program Rules

On many virtual machine blockchains, every token exists as its own independent smart contract that contains both the rules and the ledger. In that model, the ledger for a token is essentially a massive list stored inside a single contract. Solana utilizes a fundamentally different architecture by strictly separating logic from data, which is known as an account-based architecture.

Instead of requiring developers to deploy new code for every individual asset, Solana provides the SPL Token Program. This single, audited, and highly optimized program handles the logic for nearly every standard token on the network. When you create a new token on Solana, you are not deploying a smart contract. You are instead asking the Token Program to initialize a new Mint Account and designating that program as the owner. In this context, the owner refers specifically to the program that has the permission to modify the data within that account.

This standardized approach ensures that every asset follows the same predictable execution paths. This consistency is a major security feature because it reduces the surface area for logic bugs and allows every wallet or exchange to interact with any token without needing to audit unique code. The original Token Program was designed with a rigid, fixed-size account layout that handled the basics like minting and transferring, but it lacked the flexibility to adapt to the complex requirements of modern decentralized finance.

Accounts: Your Blockchain Mailboxes

To understand Solana development, you must internalize the concept that your wallet does not actually contain tokens. Instead, your wallet address acts as an authority over a specific Token Account. You can think of your wallet as a master key and the Token Account as a specialized mailbox located elsewhere on the ledger. If you wish to hold three different types of tokens, you must have three distinct Token Accounts.

Allocating space on the blockchain ledger for these data accounts requires a deposit of SOL known as the Rent-Exempt Minimum. This deposit ensures the network remains performant by preventing the accumulation of empty accounts. In modern applications, we typically use the Associated Token Account pattern. This is a deterministic way of finding a token account address using a user’s main wallet address, the token’s mint address, and the specific Token Program ID being used. Because the address is predictable, the sender can automatically initialize the mailbox for a user before sending them tokens, which solves the friction of manual account creation.

Authorities and Governance

Every token minted on Solana is governed by specific authorities that define the lifecycle of the asset. The Mint Authority is the address granted permission to generate new tokens, which directly controls the circulating supply. When a project claims its supply is hard-capped, it generally means they have renounced this authority by setting it to null. Once renounced, the supply is mathematically frozen and no further tokens can ever be created.

The Freeze Authority is a more powerful component that allows a specific wallet to lock an individual token account. A frozen account is completely immobilized and cannot receive, transfer, or burn tokens until it is explicitly thawed by the authority. While this level of control is often viewed with skepticism in purely decentralized communities, it is crucial for regulated assets, such as stablecoins, to comply with legal requirements or freeze assets involved in theft. For a developer, auditing these authorities is the first step in assessing the risk profile of any token.

The Evolution: Token 2022

As the Solana ecosystem matured, developers began hitting the ceiling of the original Token Program’s fixed layout. If you wanted to add a transfer fee or metadata to a token, there was simply no space left in the original account structure to store that information. This led to the creation of Token 2022, which is also known as the Token Extensions Program.

Token 2022 is an upgraded version of the original functionality that utilizes a more flexible data structure. This allows the program to support an expandable list of features without breaking compatibility with the original instruction set.

Transfer Fees: This extension allows projects to implement protocol-level fees without custom token logic. A configurable fee can be withheld from transfers and later withdrawn by the designated authority, allowing projects to generate revenue directly from token activity.
Confidential Transfers: This extension utilizes Zero-Knowledge Proofs to encrypt balances and transfer amounts. The network can mathematically verify that a transaction is valid without ever revealing the specific numbers to the public ledger.
Transfer Hooks: This is a powerful tool for developers because it allows a mint to require that every transfer call a secondary program. This enables logic such as mandatory identity checks or automated royalty enforcement.
Native Metadata: Developers can now store names and symbols directly within the mint account. This reduces the reliance on separate metadata systems for simpler use cases and reduces the overall complexity of your code.
Permanent Delegate: This extension allows a specific authority to move or burn tokens from any account. While powerful, it is essential for institutional compliance and the recovery of assets in legal disputes.

Why This Matters for the Challenges Ahead

As you progress through the coding challenges, you will be responsible for choosing when to use the legacy Token Program and when to leverage the advanced capabilities of Token 2022. Understanding the relationship between programs and accounts will save you hours of debugging when a transaction fails due to a missing account or an unauthorized signer. You are not just learning to code, you are learning to architect on a global and parallelized ledger. The flexibility of Token 2022 represents the next chapter of Solana’s growth by shifting tokens from simple balance entries into complex and programmable financial instruments.

Keep building and pay close attention to the account constraints in your upcoming programs. The precision you apply today will be the security of the protocols you deploy tomorrow.

See you on Discord.

100 Days of Solana is a free daily coding challenge. If you have not joined yet, you can start your journey here: https://mlh.link/solana-100

How Web3 Tokens Get Their Value

Vincent Jande — Thu, 07 May 2026 18:03:23 +0000

Someone in the 100 Days of Solana community asked a question last week that needs to be addressed: "What gives SOL its value?"

You have been using SOL in every challenge. You airdropped it, checked your balance, and you are about to start sending it in Arc 3. But where does the value actually come from? Is it just numbers on a screen?

I understand why people think that. Let’s break it down.

Liquidity: Where price comes from

The first thing to understand is that for a token to have purchasing power, there needs to be liquidity. This means there are people or pools willing to trade real assets, such as fiat or stablecoins, for that token. That liquidity is what allows a market price to exist.

Think of it like converting currencies at an airport. You hand over dollars, and you get euros. The value isn't created in that moment; it is a transfer of value from one form to another. In Web3, liquidity is the bridge that connects digital assets to the broader economy.

Different tokens, different sources of value

Not all tokens work the same way. Understanding the types helps you see where the value sits.

Native Tokens: SOL is required to pay transaction fees, stake with validators, and interact with applications. As usage of the network grows, the demand for these specific functions can increase the demand for SOL.
Stablecoins: These are often pegged to a currency like the US dollar. They maintain this peg through reserves and market mechanics. Issuers like Circle hold cash and bonds so you can redeem USDC for dollars.
Utility Tokens: These provide access to specific services, such as in-game items or decentralized file hosting. The token has value because the service it unlocks is useful to someone.
Governance Tokens: These provide voting power. Holding governance tokens for a protocol allows participation in decisions about fees, features, or treasury management.
Meme Tokens: These often derive value from community and attention. While they may begin as jokes, they can build large social networks.

The Solana-Specific Engine

Beyond general categories, Solana has unique technical mechanics that influence its economy:

The Cost of State (Rent) On Solana, storage is not free. Every time you create an account or deploy a program, you must deposit a minimum amount of SOL to make that account Rent Exempt. This SOL is held in the account to keep it active. While it isn't permanently removed, it is temporarily locked, which can reduce circulating liquidity as the ecosystem grows.
The Burn Mechanism Solana has a built-in "fee burn" where 50% of every base transaction fee is permanently destroyed. However, Solana also has inflation (new SOL issued to validators to secure the network). The net effect on supply depends on how much network activity (burn) occurs versus the rate of new issuance.
Efficiency via Proof of History (PoH) Solana’s design enables fast, low-cost transactions (settling in roughly 400ms). This can make certain applications, like high frequency DeFi or real time payments, more efficient. This efficiency increases the usefulness of the network, which in turn supports the value of its native token.

Liquidity pools: How tokens stay tradeable

In Web3, we often use liquidity pools instead of traditional order books. A liquidity pool is a smart contract holding two tokens, such as SOL and USDC. Prices are set automatically using mathematical formulas rather than matching individual buyers and sellers like a traditional exchange.

People who deposit tokens into these pools are called liquidity providers. They put in a balanced value of both tokens and earn a portion of the trading fees. This is how decentralized exchanges like Raydium or Orca function. When more people buy SOL from the pool, it becomes scarcer in that pool, and the price rises automatically.

Is it real?

Value in Web3 comes from the same place all value comes from: utility and demand.

SOL is useful because the network processes thousands of transactions per second for very low costs. USDC is useful because it allows for digital dollar movement globally. DeFi protocols are useful because they provide financial tools without traditional intermediaries.

The infrastructure is different from traditional finance, but the principles are the same. Value frequently follows utility.

What this means for you

You have been working with DevNet SOL, which has no monetary value. However, the mechanics are identical to Mainnet. The RPC calls, the wallet interactions, and the transaction flows are all the same.

In Arc 3, you start sending transactions and moving "simulated value." Understanding how that value flows, even on a test network, makes you a better builder. You are practicing the exact same movements you will eventually perform on Mainnet. Whether you end up creating a payment system, a DeFi protocol, or something entirely new, this technical foundation is where it starts.

Keep building. See you on Discord.

100 Days of Solana is a free daily coding challenge. If you have not joined yet, start here: https://mlh.link/solana-100

Why Web3 Exists and Why Solana Matters

Vincent Jande — Tue, 28 Apr 2026 18:19:40 +0000

You trust middlemen every single day. You probably don't even think about it.

Your bank holds your money. Instagram holds your followers. Spotify holds your playlists. Google holds your emails. Every service you use, someone else is in control. They control access to your data and assets within their systems and policies.

In our current digital landscape, our "ownership" is essentially a managed service. Whether it's a financial institution or a social media platform, your access depends on the stability and policies of the provider. Web3 is the movement to change this, to build an internet where you actually own your digital assets and data.

To make this vision a reality, we need a foundation that doesn't rely on a central boss. This is precisely what blockchain was designed to provide.

So what is a blockchain?

Imagine a notebook that thousands of people have a copy of. Every time someone writes something in it, every copy is updated simultaneously, provided the network agrees the entry meets specific conditions. You can't rip out a page, change what was already written, or claim ownership over the whole thing.

That's the core idea of a blockchain. It is a shared record that functions without a central boss. Once information is recorded, it remains there permanently because the system is designed to prevent anyone from tampering with the history. Instead of trusting a single company to keep the records straight, the system relies on math and a network of computers reaching a consensus.

While this describes the initial "open and ownerless" concept, the technology has evolved to allow for managed variations like private, hybrid, or consortium blockchains, where specific entities or pre-selected groups control the records rather than the general public.

Why does this matter?

It shifts how we handle control and trust in our daily lives.

Moving value without traditional hurdles. Usually, sending money abroad involves a chain of banks. It can take days, involves various fees, and a single institution can decide to halt the transaction. Blockchain allows for more direct transfers that often settle much faster, bypassing many of the usual middlemen.

Agreements governed by code. Think about hiring a freelancer. Rather than relying solely on a handshake or expensive legal backing, you could use a smart contract. The agreement is programmed: when the work is verified, the payment is released automatically. This reduces the need to chase invoices or worry about payment delays.

Secure records of ownership. Most important documents, like house deeds, are stored in centralized offices. If those records are lost, damaged, or altered by error, proving what you own becomes a nightmare. Recording ownership on a blockchain provides a decentralized backup, meaning there is no single point of failure that can wipe out your proof of property.

These aren't just ideas for the future; the infrastructure to support these shifts is being built and used right now.

If it's so great, why hasn't it taken over?

To be honest, the early versions were often slow and expensive.

Bitcoin, the first major implementation, can handle roughly 7 transactions per second. Compare that to Visa, which processes around 65,000. While Bitcoin was a massive breakthrough in proving the concept of decentralized trust, it wasn't originally designed for high-speed, high-volume traffic.

Ethereum expanded the horizon by making the technology programmable. It allowed people to build applications and write smart contracts, but it faced similar growing pains. During busy periods, the network can get congested, causing transaction fees to spike sometimes to $50 or more. High costs like that make it difficult to use for everyday things like buying coffee or paying a small invoice.

For a while, these limitations meant the tech was mostly used for speculation. People traded tokens back and forth, not necessarily because the technology lacked potential, but because the underlying infrastructure was still catching up to the demand.

Where Solana comes in

Solana was built to address these specific bottlenecks.

While many earlier blockchains struggled with low throughput, Solana was engineered to handle thousands of transactions per second. This shift makes the technology much more practical for daily use. Instead of paying dollars in fees and waiting minutes for a confirmation, transactions on Solana typically cost fractions of a cent and finalize in under a second.

This performance is what allows for real-world applications beyond just trading. It opens the door for:

Global payment systems that rival traditional speeds.
Social platforms and games where every interaction doesn't require a massive fee.
Supply chain tracking that needs to record thousands of data points in real-time.

Solana isn't the only high-speed network available, but it has become one of the most battle-tested. With a large developer ecosystem and a growing list of products running in production, it represents a move away from theoretical potential toward actual, scalable utility.

Why you should care right now

If you are a developer, blockchain isn't a "future" skill you can indefinitely postpone. Companies are hiring for it, products are shipping on it, and those who understand the architecture now have a distinct advantage.

The best part? If you know JavaScript, you already have a solid foundation. Building on Solana doesn't mean starting from scratch or throwing away your existing knowledge. Many of the core concepts map directly to the logic and systems you already understand.

Start building

100 Days of Solana is a free, daily coding challenge designed to take you from zero blockchain experience to building functional applications.

The Format: One challenge per day.
The Goal: No prerequisites, just show up and build.
The Progress: Last week, participants set up their first wallets, funding them with test SOL, and interacting with the network. This week, participants will learn how to read the blockchain. By the end of the 100 days, you won't just have theoretical knowledge; you'll have a portfolio of real projects that demonstrate exactly what you can do.

Join 100 Days of Solana

How AI Can Make You a 10x Software Engineer

Vincent Jande — Thu, 14 Aug 2025 20:46:35 +0000

In the rapidly evolving world of technology, artificial intelligence (AI) has sparked intense debates. Some predict that AI will replace software engineers entirely, while others argue that building products has become so straightforward that traditional software engineering skills are obsolete. I strongly disagree with both views. In fact, learning software engineering is more valuable than ever. With a solid foundation, you can leverage AI to handle edge cases, make informed decisions, and automate boilerplate code. This turns you into a productivity powerhouse. In this article, I'll share how I used AI to build a complex product in just three weeks (part-time), what I learned from the experience, and why skilled engineers are uniquely positioned to thrive in this AI-driven era.

The Power of Experience in an AI World

Before diving into the specifics, consider this: I'm currently working on another project where I reached a minimum viable product (MVP) in just a couple of days. Why so fast? My years of software engineering experience allowed me to architect the solution efficiently, anticipate pitfalls, and integrate AI tools seamlessly. Without that knowledge, AI alone wouldn't have sufficed. It's the synergy between human expertise and AI that creates magic.

This brings me to the main story: I was tasked with building a trading academy API. This wasn't a simple app; it needed a full learning management system (LMS) for courses, channels for trading signals, direct messaging (DMs) for user interactions, and subscription management. A project of this scope would typically take several months for a solo developer. But by combining my engineering skills with AI assistance, I completed it in three weeks. And it was not even full-time. If I'd dedicated myself entirely, it could have been done in two. Here's how I did it.

Laying the Foundation: Structure and Tech Choices

Success started with thoughtful planning, drawing on my software engineering background. I knew the pros and cons of common architectures; for instance, the Model-View-Controller (MVC) pattern can lead to cluttered code in larger projects. Instead, I opted for a feature-based structure to keep things modular and scalable.

I chose Node.js with Express.js for the backend to enable rapid development, paired with MongoDB for flexible data storage. Crucially, I designed the features to be loosely coupled, allowing me to build and test one at a time without ripple effects. This modularity is a hallmark of good engineering and made AI integration smoother.

For each feature, I enforced a consistent structure: controllers for handling requests, services for business logic, validators for input checks, routes for API endpoints, models for data schemas, types for TypeScript definitions, and middlewares for cross-cutting concerns. I also created a shared utilities folder for reusable components.

Building Features with AI: From Auth to Messaging

I kicked off with authentication, a standard but critical component. Using Claude (an AI coding assistant), I generated boilerplate code for email-based auth with refresh tokens. The output was well-structured, but it had a few errors, like outdated dependencies, which I quickly fixed using my knowledge. After testing in Postman, it was solid.

Next came user management. I separated the User model (focused on authentication) from the Profile model (for easily updatable user details). Again, Claude provided the CRUD (Create, Read, Update, Delete) boilerplate. I didn't accept it blindly; I reviewed for adherence to my structure, fixed issues, and ensured everything worked through rigorous testing.

File management followed suit. Claude generated the code, but I spotted an outdated AWS SDK version in the output. This was a reminder that AI tools might not always reflect the latest updates. Drawing on my experience, I upgraded it, set up an AWS S3 bucket with a CDN for efficient delivery, and verified functionality.

Courses were straightforward: same process, with minor error fixes leading to a working LMS module.

Messaging proved trickier. Midway through, I hit Claude's chat limit. Undeterred, I had the AI generate a detailed prompt summarizing the project's state, structure, and progress. I pasted this into a new chat session, allowing the AI to pick up seamlessly. The structure shifted slightly at first, but I guided it back on track. In the end, I handled most error resolutions myself, making necessary updates to ensure robust DMs and channels.

Lessons Learned: AI as a Bootstrapper, Not a Replacement

This project reinforced a key insight: AI excels at bootstrapping. It generates standard solutions quickly, handles repetitive tasks, and accelerates development. But it's not infallible. Errors, outdated info, and context loss require human intervention. That's where software engineering shines: knowing what to ask, spotting flaws, and refining outputs.

AI has empowered engineers to become solo founders, pushing products to market at unprecedented speeds. It hasn't made us obsolete; it's elevated us to "god-like" productivity levels. Imagine completing months of work in weeks. That's the reality for those who know how to wield it. A novice "vibe coder" couldn't achieve this; only a skilled engineer can direct AI effectively, avoiding pitfalls and ensuring quality. In my case, AI shaved off boilerplate drudgery, letting me focus on architecture and innovation. The result? A fully functional trading academy API, delivered efficiently.

Conclusion: Embrace AI, But Build Your Foundation First

AI isn't here to replace software engineers. It's here to amplify them. By mastering the fundamentals, you can become a 10x engineer: faster, more innovative, and capable of solo feats that once required teams. My experience proves it: leverage AI for speed, but rely on your expertise for precision.For inquiries, reach out via X at @janvinsha.

Ethereum vs Solana: Understanding Data Storage Differences in Their Ecosystems

Vincent Jande — Wed, 08 Jan 2025 19:04:30 +0000

Introduction
In the rapidly evolving blockchain landscape, Ethereum and Solana stand out as two of the most prominent platforms, each with its unique architecture and capabilities. While both aim to facilitate decentralized applications (dApps) and smart contracts, their approaches to data storage differ significantly. Understanding these differences is crucial for developers choosing the right platform for their projects.

Ethereum's Smart Contract Data Storage
Ethereum, the pioneer of smart contracts, allows developers to store data directly within smart contracts. This capability is intrinsic to Ethereum’s design, where each smart contract is essentially a stateful entity on the blockchain. Developers can define and manage variables within contracts, enabling complex logic and data manipulation directly on-chain.

Storing data within smart contracts offers several advantages:

Simplicity and Cohesion: All related logic and data reside within the same contract, making the development process more straightforward.
Atomic Transactions: Operations on data can be executed atomically, ensuring consistency and reliability.
Rich Ecosystem: Ethereum’s mature tooling and extensive documentation support seamless data management within contracts. However, this approach also has drawbacks. Storing large amounts of data on-chain can be expensive due to gas fees, and it may lead to scalability issues as the blockchain grows.

Solana’s Account-Based Data Separation
In contrast, Solana adopts a different strategy by separating data storage from program logic. Instead of embedding data within smart contracts, Solana uses separate accounts to hold data. These accounts are often Program Derived Addresses (PDAs), which are deterministic and derived from the program’s public key and specific seeds.

Key aspects of Solana’s data storage model include:

Modularity: By decoupling data from program logic, Solana promotes a more modular architecture. Programs can interact with multiple data accounts, enhancing flexibility.
Scalability: This separation allows for more efficient data handling and reduces the overhead on individual programs, contributing to Solana’s high throughput.
Security: PDAs ensure that only the designated program can modify the associated data, enhancing security through deterministic address generation. While Solana’s approach offers scalability and modularity, it introduces complexity. Developers must manage multiple accounts and ensure proper interactions between programs and data accounts. This can increase the learning curve compared to Ethereum’s more integrated model.

Comparative Insights

Performance and Scalability: Solana’s account-based model and high throughput make it suitable for applications requiring rapid transactions and extensive data manipulation. Ethereum, while slower and less scalable, benefits from its established network and robust security features.
Developer Experience: Ethereum’s all-in-one contract data storage is more intuitive for developers familiar with traditional smart contract development. Solana’s separation of data and logic requires a deeper understanding of account management and PDA utilization.
Use Cases: Ethereum excels in scenarios where tight integration of logic and data is beneficial, such as decentralized finance (DeFi) protocols and complex dApps. Solana shines in high-frequency applications like gaming, real-time analytics, and NFT platforms that demand speed and scalability.

Conclusion
Both Ethereum and Solana offer powerful ecosystems for building decentralized applications, but their approaches to data storage reflect different priorities and architectural philosophies. Ethereum’s ability to store data within smart contracts provides simplicity and cohesion, making it ideal for a wide range of applications. On the other hand, Solana’s separation of data into PDAs and other accounts enhances scalability and performance, catering to high-throughput demands.
For developers, the choice between Ethereum and Solana hinges on the specific requirements of their projects. Understanding these key differences in data storage is essential for leveraging each platform’s strengths and building efficient, scalable, and secure decentralized applications

A Lesson in Simplicity: Sorting Files Like a Pro in an Interview

Vincent Jande — Tue, 29 Oct 2024 14:30:39 +0000

During a technical interview for a full-stack developer role, I found myself in a familiar yet unexpectedly challenging situation. Everything had been going smoothly until the interviewer presented me with a task that seemed simple at first.

“Can you sort these filenames the way they’d appear in a file explorer, in ascending order?” they asked.

I thought, “Piece of cake.” Sorting is such a fundamental operation that I didn't expect any trouble. But as soon as I started writing the code, I hit a snag. The filenames were all over the place some were simple, but others included numbers, letters, and combinations of both.

I tried using a basic string sorting method like:
array.sort();
But this produced an odd result. The numbers were sorted lexicographically (meaning “10” would come before “2” because it starts with a “1”), and mixed alphanumeric strings weren’t in the correct order. It was a mess, and it didn’t resemble the natural order you see in file explorers at all.

I could feel the clock ticking and pressure building up. I tried to work through various custom comparison functions to handle the numbers properly, but nothing seemed to click.

Then, I remembered a simple trick I had read about not too long ago: localeCompare.

localeCompare allows you to compare strings in a way that mimics how humans sort things. By using it with the numeric option, it handles the numbers as actual numbers rather than comparing them as text. Here’s the code I used:
array.sort((a, b) => a.localeCompare(b, undefined, { numeric: true, sensitivity: 'base' }));
This single line of code sorted the filenames exactly like a file explorer would: numbers were ordered naturally, and letter/number combinations were handled seamlessly.

As soon as I ran the code, I saw the correct order appear on the screen. The filenames were perfectly sorted in ascending order, just like in a file explorer. I smiled as I explained the solution to the interviewer, who seemed pleased with how I resolved the issue.

What initially felt like a complicated problem ended up being solved with a simple, elegant solution. It was a reminder that sometimes the most effective tools are the simplest, and knowing those small tricks can make all the difference.

Debugging WebSocket Connection Failure: wss://relay.walletconnect.org

Vincent Jande — Thu, 24 Oct 2024 15:01:34 +0000

If you've encountered a WebSocket connection failure when trying to use WalletConnect with an error like:
WebSocket connection to 'wss://relay.walletconnect.org' failed
this error might be linked to access restrictions applied by certain services to specific countries, including Nigeria.

Understanding WebSocket and WalletConnect

WalletConnect is an open protocol for connecting decentralized applications (dApps) to mobile wallets through QR code scanning or deep linking. It relies on WebSocket (WS) connections to relay encrypted communication between the dApp and the wallet. The WebSocket protocol, denoted by the wss:// scheme (secure WebSocket), is crucial for maintaining a persistent connection between the client and server for real-time interactions.
However, you might encounter the WebSocket failure for the relay.walletconnect.org endpoint due to geo-blocking. Some platforms, including WalletConnect's relayer, restrict access to certain countries like Nigeria, potentially due to regulatory compliance or risk management strategies.

Common Symptoms

Connection Timeout or Failure: When initiating the connection to wss://relay.walletconnect.org, the WebSocket handshake fails.
Inconsistent Behavior: The issue may persist across different networks and devices in Nigeria but may work without problems when using a VPN or accessing the service from a different location.
Country-Specific Restrictions: WalletConnect's relay servers could be enforcing geo-blocks, resulting in connection denials for users based in regions with restricted access.

Workarounds

If you're facing this error, there are a few options to explore:
Use a VPN: A simple but effective solution is using a VPN to connect from a country where WebSocket connections to WalletConnect relayers are not blocked.
Proxy Services: Set up a proxy server in an unrestricted region to relay the WebSocket connection on your behalf.

In conclusion, this issue highlights the importance of understanding country-specific restrictions when developing or using Web3 tools. While frustrating, using a VPN or alternative relayer services can help you work around the problem.