DEV Community: Russell Oje

Trilogy in Solana: Transfer Fee, Interest-Bearing, and Nontransferable

Russell Oje — Sun, 14 Jun 2026 23:18:09 +0000

Token-2022 is the upgraded SPL token program on Solana, bringing native extensions that allow a single mint to opt into advanced behaviors without custom programs. This week, I explored three powerful extensions: Transfer Fees, Interest-Bearing tokens, and Non-Transferable tokens. Think of these extensions as middleware for your tokens—enforced at the protocol level.

The Transfer Fee Mint

Mint Address: FeoMWHjNJgJM6iEQUnUjsJsdPtP3Cu9m99iiuz9RhALG

I configured this token to skim a fee on every transfer. This is perfect for protocol treasuries or community currencies where a small percentage of every transaction supports the ecosystem.

spl-token create-token --program-id TokenzQdBNbLqP5VEhdkThT93YfkdY59uL35t4Z5Xl --transfer-fee 100 5000

This command sets a 1% fee (100 basis points) with a maximum cap of 5000 lamports.

The Interest-Bearing Mint

Mint Address: 6vZ9eXTTtGCpwRVLGg6uuyLXxk2yYEykroBTNybf6wT3

This extension allows a token to accrue interest over time. Crucially, it doesn't mint new supply; instead, the UI-displayed amount updates based on the on-chain rate.

spl-token create-token --program-id TokenzQdBNbLqP5VEhdkThT93YfkdY59uL35t4Z5Xl --interest-rate 10

NB: Remember that the rate is stored on-chain, but the principal balance remains the same until updated. It's a clever way to handle yield display natively.

The Non-Transferable Mint

Mint Address: 3PWCwuiPauNhYxwArDGaRizKLpJHETLS7RNRqHL1AQvm

Finally, I built a "Soul-bound" token. Once minted to an account, it cannot be transferred or moved. I tested this by attempting a transfer and received a satisfyingly firm error: Program log: Transfer is disabled for this mint: custom program error: 0x25.

spl-token create-token --program-id TokenzQdBNbLqP5VEhdkThT93YfkdY59uL35t4Z5Xl --enable-non-transferable

Take Home

What caught my attention this week is how simple it is to compose these behaviors. Native extensions remove the need for "wrapped" versions of tokens to get simple features like fees or interest. I’m excited to see how these primitives will be used in real products for loyalty programs.

NFTs in Solana: Another Week with Token Extensions

Russell Oje — Mon, 08 Jun 2026 18:11:03 +0000

This week, I stepped away from the usual Extension system from last week, to creating NFTs, using only Solana's native Token Extensions (Token-2022). It turns out, you can build a fully functional, grouped, and mutable NFT collection entirely at the protocol level.

The Mental Model: What is a Solana NFT?

Coming from a Web2 background, I used to think of an NFT as a complex smart contract. On Solana, using Token Extensions, an NFT is simpler and more elegant: it's a token mint with supply 1, decimals 0, and a few specific extensions that handle metadata and grouping.

What I Built This Week

I spent the last few days moving from a single 1-of-1 token to a full-blown collection:

The 1-of-1 Mint: I started by creating a mint with the Metadata extension, ensuring it had zero decimals and a supply of exactly one.
Metadata Extension: Instead of an external metadata account, I stamped the name, symbol, and URI (pointing to a JSON on a GitHub Gist) directly onto the mint.
Group and Member Extensions: I created a collection mint and then linked my individual NFTs to it using the Group and Member extensions. This creates a "foreign key" relationship natively on the blockchain.

The Surprising Part: Live Mutation

The most eye-opening moment was realizing how "alive" this data is. As long as you hold the update authority, you can mutate the metadata in real-time with a single CLI command.

On Friday, I renamed my NFT, updated the metadata's JSON uri (to update the image icon) and added custom fields like rarity: legendary directly from my terminal:

# Adding a custom metadata field live on devnet
spl-token update-metadata $MINT_ADDRESS rarity "legendary"

Watching Solana Explorer update the "legendary" tag seconds after my transaction confirmed felt like running an UPDATE statement on a production database, but the "database" is a global public network.

Week Digest

Using Token Extensions for NFTs feels like the "bare metal" way to build. It's fast, cost-effective, and removes the dependency on third-party programs for basic collection management. I’m excited to see how these primitives will be used to build more complex "programmable" NFTs that react to on-chain events.

Follow along on my #100DaysOfSolana journey!

Soulbound Credentials on Solana

Russell Oje — Mon, 01 Jun 2026 11:25:53 +0000

"Combining Non-Transferable and Permanent Delegate Extensions to Build a Soulbound Token System on Solana"

Imagine you're issuing a digital certificate or a compliance-gated membership. In traditional web2 systems, you have absolute control over a database record and can decide who holds it and when it should be revoked or expired. In web3, assets are typically owned by the wallet holding them, so once they are transferred, the issuer loses control.

But what if you need an on-chain credential that the holder can't sell or transfer, and the only issuer can revoke if necessary?

This week I explored Solana's Token Extensions (Token-2022) to build exactly this: A Soulbound Token with a Permanent Delegate.

The Token Extensions Involved

To achieve a revocable credential, we combine three Token Extensions at the protocol level:

Non-transferable: Enforces that the token cannot be moved from the recipient's wallet.
Permanent Delegate: Allows an authority (us, the issuer) to burn or transfer the token regardless of who holds it.
Metadata: Binds the credential's details directly to the mint.

Creating and Revoking the Credential

Here is the exact code snippet I used to generate the token mint with these extensions enabled:

# Create the mint with non-transferable and permanent-delegate extensions
spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --decimals 0 --enable-non-transferable --enable-permanent-delegate --enable-metadata

Using --decimals 0 makes sense here because credentials are whole units—you either hold the certification or you don't.

If the credential owner attempts to transfer the token, the non-transferable extension outright blocks it. The transaction fails on-chain.

If a credential expires or the user violates compliance, the issuer can revoke it using their permanent delegate authority. We do this by burning the token directly from the recipient’s token account—no signature from the recipient required:

# Burning the credential from the recipient's account
spl-token burn $RECIPIENT_TOKEN_ACCOUNT_ADDRESS 1 --owner ~/.config/solana/id.json --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

What Surprised Me

What surprised me the most was how deeply these extensions remove the need for custom smart contracts. Previously, I imagined that the "Soulbound" logic would require deploying a custom Anchor program to intercept transfers, but, the protocol inherently understands these rules natively, making the execution safer and cheaper.

It was incredibly satisfying to watch a transfer attempt legally fail on-chain because the token was minted with the non-transferable flag!

If you want to dive deeper and experiment with these configurations, check out the official Token-2022 extensions guide in the Solana documentation.

Week5 Recap of #100DaysOfSolana

Russell Oje — Tue, 26 May 2026 21:49:54 +0000

This week I created a custom SPL token on Solana with metadata, transfer fees, and non-transferable extensions!

I didn't expect the Token Extensions Program to let you enforce economic rules directly at the protocol level, no off-chain logic needed.

#100DaysOfSolana

# Week5 of #100DaysOfSolana: A Tour of Solana Token Extensions

Russell Oje — Tue, 26 May 2026 21:47:31 +0000

If you come from Web2, the idea of a token might seem like a simple integer variable stored in a database. But on Solana, tokens are deeply integrated into the programming model. This week, I went from compiling my first dependencies to creating fully featured tokens using Solana's Token Extensions Program (Token 2022).

In this post, I want to walk you through what I learned, how token extensions change the game, and why enforcing economic rules on-chain instead of off-chain is so powerful.

The Starting Point: Why The Token Extensions Program?

When I first started looking into Solana, I learned about the standard Token Program. It's the original program that handles SPL tokens. But then I discovered the Token Extensions Program (often referred to as Token-2022).

Why do we need a new program? Because the original program was simple by design. If you wanted to do something complex-like enforcing transfer fees, tying metadata directly to the token mint, or making a token non-transferable, you had to build an entire custom smart contract to act as an intermediary.

The Token Extensions Program brings these powerful features directly to the protocol level. You can just configure the mint to utilize specific extensions, and the protocol handles the rest. This drastically reduces the surface area for bugs and the barrier to entry for developers.

Adding Metadata Directly to the Mint

Previously, token metadata (like the name, symbol, and URI for an image) was typically handled by Metaplex programs off to the side. With the MetadataPointer and TokenMetadata extensions, you can embed this directly.

Here is what the flow looks like when initializing a mint with token extensions via the CLI:

solana-keygen new --outfile token-keypair.json
spl-token create-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb --transfer-fee-basis-points 200 --transfer-fee-maximum-fee 5000 --enable-metadata --decimals 9

By linking metadata directly to the mint, building indexers, wallets, or explorers becomes so much simpler. Everything you need is right there in the token's core data structure. No hunting across different accounts.

Enforcing Transfer Fees at the Protocol Level

One of the most fascinating extensions I experimented with is the TransferFeeConfig. Let's say you want to build a token that burns 1% of every transaction, or sends a 1% royalty to the creator's treasury.

In traditional Web2 logic, you'd write a server route that deducts this amount before updating the database. But blockchains are public; users can bypass your server and transact directly. With the transfer fee extension, the rule is baked into the token's DNA.

When you attach this extension, the blockchain will not allow a transfer to succeed unless the fee is properly calculated and withheld. This is what it means to enforce economic rules in code rather than policy documents. It requires zero custom smart contracts—just standard configuration.

Soulbound: Non-Transferable Tokens

The final extension that blew my mind was creating a non-transferable token. In the Web3 world, these are sometimes called "Soulbound" tokens. They are permanent credentials glued to your wallet.

Think about a university degree or an event ticket. You want the person to own it, but you definitely don't want them selling it on an exchange.

By applying the NonTransferable extension during mint creation, the token becomes forever locked to the account it is minted to. If someone tries to solana transfer <mint> <amount> <recipient>, the transaction will simply fail. The blockchain itself rejects it.

What Surprised Me Most

The biggest moment for me was realizing just how much heavy lifting the Solana protocol can do for developers out of the box. Coming from an environment where I normally have to write an entire backend service to manage custom tokenomics, the fact that I could enable transfer fees and non-transferability just by passing a few flags during initialization was stunning.

It feels less like writing complex financial software and more like configuring a highly secure, decentralized operating system.

What’s Next?

Building these tokens locally and via the CLI on devnet was an incredible foundation. Next week, I plan to dive into how these tokens interact with actual custom on-chain programs (smart contracts). Now that I understand the assets, I want to write the logic that trades, manages, and interacts with them.

If you are a Web2 developer sitting on the fence, jump in. The water is fine, and the tooling has never been better. Follow along on my #100DaysOfSolana journey!

#100DaysOfSolana Week4 Recap

Russell Oje — Sun, 17 May 2026 21:57:29 +0000

I opened my devnet account in Solana Explorer today and it clicked how much the explorer reveals: balance, owner, executable flag, and full transaction history in one view. I like Solana Explorer for this clarity.

#100DaysOfSolana

Week4 of #100DaysOfSolana: Solana's Account Model

Russell Oje — Sun, 17 May 2026 21:47:11 +0000

If you come from Web2, Solana's account model can feel strange at first. The first time I inspected an account with the CLI, I saw fields like lamports, owner, and data all sitting together and thought, "Wait, where is the smart contract state stored?"

That question is the whole lesson. On Solana, everything is an account. Wallets are accounts. Program code lives in accounts. Application state lives in accounts. There is no separate world of contract accounts versus externally owned accounts like you may have seen elsewhere. Solana uses one flat key-value store where the key is a 32-byte address and the value is the account itself.

That design clicked for me when I started thinking about accounts like files in a filesystem. Each file has metadata, contents, and permissions. Solana accounts work the same way:

the address is the filename
the owner is the program allowed to manage it
the data is the file contents
the balance is the lamports stored alongside it
the executable flag tells you whether the file is runnable code or just data

That analogy is not perfect, but it gets you close fast. The System Program is like the operating system kernel. It creates accounts, assigns ownership, and handles basic bookkeeping. Other programs then read and write the accounts they own.

Every Solana account has the same five fields:

lamports - the balance stored in the account. One SOL equals 1 billion lamports.
data - a byte array that can hold arbitrary state.
owner - the program that controls the account.
executable - whether the account contains runnable program code.
rent_epoch - a legacy field that is now effectively retired and set to the maximum value.

The most important rule is ownership. Only the owner program can modify an account's data or debit its lamports. That means a token program can update token accounts it owns, but nobody else can casually rewrite those bytes. At the same time, anyone can credit lamports to a writable account. That combination is simple, but it creates a very clear security model.

What surprised me most was the statelessness of programs. In Web2 terms, a program is not a server that keeps its own memory forever. It is more like a web server binary that reads from and writes to a database. The executable account stores the code, and separate data accounts store the application state. That separation is why the account model matters so much: if you understand who owns the account and what data it contains, you understand how the program behaves.

Here is the kind of output I kept seeing while exploring accounts:

Each field tells a story. A zero-length data field means the account is just holding value. The owner 11111111111111111111111111111111 is the System Program. executable: false means this is not a program account. And the huge rentEpoch value is a clue that rent exemption has taken over the old rent schedule.

Rent exemption is another detail that makes Solana feel different from a traditional backend. Every account must hold a minimum lamport balance proportional to its data size if it wants to stay on-chain. If the account drops below that threshold, it risks being purged over time. For a tiny basic account, the minimum is around 0.00089 SOL, though the exact value depends on the account size. You can check it with solana rent or the getMinimumBalanceForRentExemption RPC method.

That idea matters because it forces you to think about storage costs up front. If you create a larger state account, you need to fund it accordingly. In Web2, disk space is usually someone else's problem. On Solana, the cost of storage is part of the design.

The account model also explains why Solana feels so composable. Programs do not hide their state inside private memory. They operate on explicit accounts that can be inspected, passed around, and reasoned about independently. Once I stopped thinking in terms of "a contract with internal state" and started thinking in terms of "a program that manages files," the architecture made much more sense.

If you are a Web2 developer, that is the mental model I would keep: Solana is a filesystem for programmable state. Accounts are the files. Programs are the executables. The System Program is the kernel. And ownership is the permission system that keeps everything safe.

That framing turned Solana from something mysterious into something structured. The account model is not just an implementation detail. It is the core abstraction that makes the rest of Solana understandable.

Recap of Week3

Russell Oje — Thu, 14 May 2026 10:55:19 +0000

This week I built my some Solana tools: a CLI transfer app and a confirmation UI, and I deep-dived into transaction anatomy: signatures, blockhashes, and atomicity.

I broke transactions to understand failure. Now I can send SOL, verify it on-chain, and explain exactly what's happening at every step.

#100DaysOfSolana

Week3 of #100DaysOfSolana: Understanding Solana Transactions

Russell Oje — Thu, 14 May 2026 10:49:35 +0000

By the end of Week 2, I understood how data lives on accounts, public keys, and the absence of a backend. This week was about understanding change: how transactions work, how to build them, and what happens when they fail.

The turning point: transactions aren't requests to a server. They're cryptographically signed messages that prove you own the keypair and authorize a specific state change. And if they fail, the whole thing rolls back (even though you still pay the fee :)).

The Week 3 Journey

Day 15: Understand transaction anatomy

I started by taking apart an actual transaction on devnet. I sent a small transfer and then inspected it:

Pulled the transaction signature from the terminal
Ran solana confirm -v SIGNATURE to see the raw structure
Opened the same transaction in Solana Explorer and compared the two views.

What I discovered: a transaction has exactly five parts:

Part	What it means	Web2 analogy
Signatures	64-byte Ed25519 signatures proving you own the keypair	Auth token
Header	Three bytes describing how many signers and read-only accounts	HTTP headers
Account Keys	Every account the transaction may touch, in order	Paths / query params
Recent Blockhash	A recent block hash that expires in ~60-90 seconds	CSRF token with expiry
Instructions	The actual program calls with program ID, accounts, and data	Request body

The constraint clicked immediately: a serialized transaction must fit within 1,232 bytes. That's the maximum. And if any instruction fails, the whole transaction rolls back atomically (and like I stated before, you will still pay the fee).

In Web2, I'm used to stateless request/response. This is different. A transaction is atomic, expiring, and size-limited. Those aren't bugs; they're features that make on-chain state changes safe and deterministic.

Day 16: Send your first SOL transfer

Next, I built the practical skill: actually sending SOL on devnet.

The steps felt straightforward:

Set the CLI to devnet: solana config set -ud
Airdrop 2 SOL (devnet only)
Create a recipient keypair
Send 0.5 SOL: solana transfer RECIPIENT_PUBKEY 0.5 --allow-unfunded-recipient
Verify both balances changed on-chain

Day 17: Build a transfer tool

Then I wrote a reusable CLI tool that accepts a recipient and amount. This wasn't just wrapping the CLI command. The tool worked. I could send SOL with three lines of code. But the real insight was seeing the transaction signature in the output. That signature is both the receipt and the transaction's unique ID. I can search it on Solana Explorer forever.

Day 18: Add transaction confirmation UI

On this day, I added a confirmation layer to transaction implementation:

This added complexity, but it taught me something crucial: transactions are asynchronous. You send it, you get a signature immediately, but the transaction isn't confirmed until validators include it in a block. That can take seconds or fail entirely if the blockhash is too old.

Day 19: Explore failed transactions

Finally, I broke transactions on purpose to understand failure modes.

I forced invalid scenarios:

Sending more SOL than I had
Sending to invalid addresses

Each failure gave me a different error message on-chain:

InsufficientFunds — clear and expected
Invalid address formats — caught during construction before sending

What Clicked for Me

Transactions as cryptographic proof: In Web2, a request is just data sent to a trusted server. On Solana, a transaction is a cryptographically signed message that proves I authorized it and that it hasn't been tampered with. That's a fundamentally more trustless model.
Also, confirmation is different from sending: The signature appears immediately, but confirmation requires validators to include the transaction in a block. Polling for confirmation taught me that devnet sometimes takes a few seconds, and mainnet is even less predictable. I can't assume a transaction is final just because I have the signature.

What about you? Have you built with Solana transactions yet? What surprised you most about how they work? Drop a comment below.

Day 16 of #100DaysOfSolana

Russell Oje — Tue, 05 May 2026 23:14:06 +0000

I just made a transfer to a new Solana account in less than a second.

Week2 Recap of #100DaysOfSolana

Russell Oje — Mon, 04 May 2026 14:14:04 +0000

This week I queried on-chain data, built a dashboard, and mapped traditional databases to Solana's account model. The biggest shift: I don't need a backend. The RPC is the API. The ledger is the database. Wallets are auth. Same address, different networks, same architecture. It finally made sense.

#100DaysOfSolana

Week2 of #100DaysOfSolana: The Account Model

Russell Oje — Mon, 04 May 2026 14:11:03 +0000

By the end of Week 1, I understood identity on Solana. This week was about understanding state.

In traditional Web2 development, I was trained to think in two separate layers: code lives on a server, data lives in a database. They talk to each other through the database queries and middleware. It felt natural because I built that way for years. But Solana doesn't work that way, and this week it finally made sense why.

The Week 2 Journey: From RPC Queries to Account Architecture

Day 8: "Read your first on-chain data"

I wrote a simple script that connected to devnet's RPC and queried a balance. It felt like calling a REST API, just pointing at a different kind of backend.

The key moment: I realized I wasn't querying a database. I was asking the Solana network for the state of an account. That account is not a row in a table somewhere. It's a first-class entity on the ledger itself.

Day 9: "Fetch transactions"

Next, I pulled transaction history for an address. Seeing block times, signatures, and slot numbers make me realize: every state change is a transaction, and every transaction is immutable history on-chain.

For the first time, I understood audit logs at the protocol level. There's no way to delete a transaction. No way to "update" the past. If a balance changed, that change is forever stored on-chain, visible to everyone.

Day 10: "Build a dashboard"

Similar to Day 4 of Week1, I also built a browser app, but this one displays account data. Nothing fancy, just RPC calls in the frontend, rendered on the page.

What clicked: the dashboard talks directly to the network. No backend API needed. No session management. The wallet in the browser is the auth. The RPC endpoint is the database. This is genuinely different.

Day 11: "Compare accounts vs databases"

On this day, I mapped Web2 database concepts to Solana accounts:

Rows → Accounts
Tables → A flat space of accounts identified by public key
Auto-increment IDs → Base58 public keys
Middleware auth → Program ownership rules
Storage costs → Rent-exempt deposits

Seeing the comparison table made it real. The account model isn't just a different API. It's a fundamentally different way to think about data architecture. And like I leaned here, in web3, there's no "join" operation because you organize data differently from the start. You fetch accounts by address, not by filtering queries. And you pay explicitly for storage, which makes you think carefully about what you store.

Day 12: "Compare networks"

Finally, I queried the same address on both devnet and mainnet. Different balances, different transaction histories, same address model.

The insight: the architecture is identical, but the state is independent. Devnet is a sandbox. Mainnet is production. Both follow the same rules. I could deploy the same program to both and it would work. Same address derivation, same account queries, different network validators securing different state.

What Surprised Me

The biggest surprise was realizing I could build a complete on-chain app without writing a backend. In Web2, "no backend" means leaning on a third-party service (Firebase, Supabase, etc.). On Solana, "no backend" means the network is the backend. The RPC is the API. The ledger is the database. Wallets handle identity.

What's Still Confusing

PDAs (Program Derived Addresses) and how they relate to accounts. I saw them mentioned but haven't built with them yet. The concept of accounts owned by programs, and how programs use PDAs to derive deterministic addresses.

Also, the economics of rent. I understand the concept, but I haven't felt the weight of deploying a large program or managing multiple accounts yet. When do rent costs become a serious consideration? When do I need to optimize?