DEV Community: Russell Oje

Solana: The Byte Tax

Russell Oje — Sat, 04 Jul 2026 22:19:32 +0000

Why does every feature you bolt onto a Solana Token come with a price tag?

In every Web2 stack I've worked in, adding a column to a table is basically free. You run a migration, maybe wait a minute for it to backfill, and move on. Storage is cheap, and nobody itemizes what a single boolean field costs you.

On Solana, I found out the hard way that every feature I bolt onto a token has a literal, permanent, one-time price tag, and even more fascinating, you can watch that price change in real SOL as you add extensions.

Rent Isn't a Metaphor Here

Proportional to how many bytes of data it stores, every account on Solana, including a token's mint account, has to hold enough SOL to stay "rent-exempt". Token Extensions live inside that same account, packed into a Type-Length-Value buffer bolted onto the base mint. So more extensions means more bytes, which implies a bigger one-time deposit before the account can exist at all.

I built three different mints in Arc 6 of the 100DaysOfSolana and measured them side by side:

Mint	Extensions Enabled	Account Size (bytes)	Rent Cost (SOL)
Interest-bearing only	Interest-bearing	222	~0.002436
Multi-extension	Interest-bearing, Transfer fees, Metadata Pointer, Metadata	599	~0.005060
Compliance-gated	Default Account State (Frozen)	171	~0.002081

That's roughly a 2.4x jump in both size and cost just from stacking three extra behaviors onto one mint. Meanwhile, the "default frozen" mint, despite sounding like the heaviest compliance feature of the three, turned out to be one of the cheapest, smallest accounts I created all Epoch.

Why This Actually Matters

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 2 \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 500 \
  --interest-rate 5 \
  --enable-metadata

This single command above (the one that produced my 599-byte mint), reads like a feature checklist: fees, yield, and metadata, all in one line. In Web2, shipping that many "nice to haves" costs you engineering time, not a line item you pay before the feature goes live. On Solana, the cost is upfront, denominated in SOL, and visible the moment you run solana account $MINT --output json and read the space field.

The Best Part Yet

The correlation is almost too clean: every extension adds a predictable number of bytes, and every byte has a knowable SOL cost. There's no hidden "it depends on load" the way cloud storage pricing gets murky. You can price out a token's entire feature set before writing a single line of code, the same way you'd budget infrastructure before choosing a stack.

It reframed extensions for me as a real trade-off instead of a free checkbox. There's no such thing as a free feature flag on a mint account. You decide what you actually need, because you're the one paying the rent-exempt deposit for whatever you don't cut.

The Way Forward

Say you design a schema, choose any product that you've done in the past. But the caveat is that every field you added to the schema, will cost you real money, forever, and upfront; which of your product's "nice to have" fields would you cut first? I want to hear about the most bloated schema you've ever inherited. Let's see how it stacks up against a 599-byte mint account.

Solana: Can You Own Something You're Not Allowed to Sell?

Russell Oje — Sat, 04 Jul 2026 22:12:24 +0000

Solana's Soulbound Credentials, explained for Web2 Devs.

Ownership on a blockchain is supposed to be the whole pitch: whoever holds the private key holds the asset, full stop, no admin panel required. So what happens when I build a token that you can hold... but can never sell, trade, or give away — and that I can delete from your wallet without asking you?

That's exactly what I built in Arc 6 of the #100DaysOfSolana using two Token Extensions stacked on the same mint (three, actually), and it forced me to rethink what "ownership" even means once code, not policy, is the one enforcing it.

The Extensions That Make This Possible

Non-Transferable locks a token to the account it was minted into. Forever. Not "until the marketplace updates its terms" — the transfer instruction itself is rejected by the protocol.

Permanent Delegate grants one authority (in this case, me, the issuer) the power to burn or move the token out of any holder's account without their signature. No multisig, no support ticket, no "please confirm this action."

Combined with a Metadata extension, this is enough to build a revocable credential entirely from CLI flags; think about a certification, a compliance badge, or even a membership pass:

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token \
  --decimals 0 \
  --enable-non-transferable \
  --enable-permanent-delegate \
  --enable-metadata

--decimals 0 because a credential is a whole thing. You either hold it, or you don't.

Testing the Rules, Not Just Trusting Them

I minted one credential to a second wallet, then tried to move it to a third wallet using the second wallet's own keypair:

spl-token transfer $MINT 1 $THIRD_PARTY --owner ~/recipient-wallet.json --fund-recipient --allow-unfunded-recipient

Rejected. Not "denied by my backend" — rejected by the Token-2022 program itself, because the non-transferable rule is written into the mint's on-chain data.

Then I did the uncomfortable part. Using my permanent delegate authority, I burned that same credential straight out of the recipient's account, without requesting a signature from them:

spl-token burn $RECIPIENT_TOKEN_ACCOUNT_ADDRESS 1 --owner ~/.config/solana/id.json --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

It worked. Instantly. No dispute process.

Outside the Theory

This pattern already exists in production. A good example is Paxos, which uses the Permanent Delegate extension on its USDP stablecoin specifically to claw back funds tied to illegal activity, satisfying a regulatory requirement it operates under. That's a real, audited, non-hypothetical use of "I can take this back from you" living directly inside a currency that moves real money.

The Best Part Yet

I expected "soulbound" logic to require deploying a custom contract or program that intercepts every transfer instruction and checks a condition. It doesn't. The protocol understands non-transferability and delegated revocation natively — no custom smart contract, no audit surface beyond the extensions I opted into.

The Way Forward

Here's the uncomfortable question I can't fully answer myself:

if I can revoke your credential without your signature, is it actually yours, or is it just a permission slip with extra ceremony? - Is this meaningfully different from a company revoking your enterprise SSO seat the day you're offboarded, or is it even worse, since it's permanent and public?

I want the Web2 argument here. Tell me where I'm wrong in the comments.

What Solana's Transfer Fee Extension Taught Me About Trustless Payments

Russell Oje — Sat, 04 Jul 2026 22:04:34 +0000

Every web2 payment flow I've ever shipped has the same shape: a request hits my server, my server calculates the amount and fees, and then my server updates the database. The fee only exists because my code enforces it. If someone finds a way around my API, say, using a direct database write, or a race condition, or even a webhook that never fires, then the fee just doesn't happen.

In Epoch 2 of #100DaysOfSolana, I built a token where this entire problem disappears. It disappears, not because I wrote better backend code, but because there was no backend to bypass.

The Web2 Way:

Fees Live in Application Code

Think about how a typical marketplace fee works. A buyer pays $100, your Stripe webhook fires, your server calculates a 5% platform fee, and your server moves $95 to the seller's payout and the $5 fee to your treasury. That logic lives entirely in your application layer. It is correct as long as nobody modifies to your database directly, nobody manipulates your webhook, and your cron job never double-fires.

That's a lot of "as long as."

How Solana Does It:

Baking the Fee into the Currency Itself

Solana's Token Extensions Program (Token-2022) lets you attach a TransferFeeConfig directly to a token's mint account. Once it's there, the fee isn't a suggestion your application makes, but a rule the network itself enforces on every single transfer, for every wallet, FOREVER.

Here's the exact command I used to create a mint with a 1% fee and a fee cap:

spl-token create-token \
  --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb \
  --transfer-fee-basis-points 100 \
  --transfer-fee-maximum-fee 1000000 \
  --decimals 6

No webhook. No cron job. No server at all. The 100 basis points (1%) is stored in the mint's own account data, and the Token-2022 program checks it on every transfer instruction before the transaction is even allowed to land.

Watching It Actually Refuse to Be Bypassed

The part that changed how I think about this wasn't creating the mint, but it was when I tried to move tokens around it. When I sent 1,000 tokens to a second wallet, I had to tell the CLI what fee I expected:

spl-token transfer $MINT 1000 $RECIPIENT --expected-fee 10

If that number doesn't match what the protocol calculates, the transfer fails outright. There's no code path where the fee "doesn't happen." The 10 tokens land in a withheld balance sitting inside the recipient's own token account, visible, auditable, and untouched until the mint's withdraw authority explicitly harvests it:

spl-token withdraw-withheld-tokens $MY_TOKEN_ACCOUNT $RECIPIENT_TOKEN_ACCOUNT

I could see the withheld amount sitting there before I swept it. In Web2 terms, it's like the database enforcing your business rule for you at the storage engine level, instead of trusting your application code to get it right every time.

Outside the Theory

This isn't just a devnet toy "in theory". There's a meme-adjacent token called BERN, which uses the Transfer Fee extension so that every transfer automatically skims a percentage split between burning BONK, burning BERN, and rewarding holders.

Regulated stablecoin issuers also use the same Token-2022 toolbox for very different reasons. Another interesting use case is Paxos, where they specifically enabled the Permanent Delegate extension on their USDP stablecoin so it can claw back funds used for illegal purposes, meeting strict regulatory requirements it operates under.

Same program, wildly different use cases, both enforced at the protocol layer instead of the application layer.

The Best Part Yet

I stacked the Transfer Fee extension with an Interest-Bearing rate on the same mint later in the week, and both behaviors lived independently in the same account's data. The fee deducts on transfer, and the interest accrues on display; neither one needs to know the other exists. Composability at the protocol level means that, I get a "middleware" for my currency, without writing a single line of middleware. Cool.

The Way Forward

If a fee genuinely could not be bypassed, no matter who touched the raw ledger, what would you build with that guarantee?

A treasury that funds itself?
Or a royalty stream that survives even if the marketplace's website goes down?

Tell me the fee-based idea you'd never trust a Web2 backend to enforce correctly.

A Mental Dive into Solana PDAs

Russell Oje — Sun, 28 Jun 2026 09:49:02 +0000

On Solana, programs are stateless. So if your program needs to remember something per user, per config, per anything, it needs a deterministic address it can find again later without storing it anywhere. PDAs are that address.

The Background Picture

From the web2 world, a PDA (or Program Derived Address) is like a database primary key you compute from the row's logical identity. But instead of INSERT INTO counters (user_id) RETURNING id, you run a hash over ["counter", user_pubkey, program_id] and that hash is the address or PDA. It requires no lookup table and no coordination. The client and the program independently arrive at the same address every time.

But there's a twist here, that must be noted: PDAs are not necessarily similar to rows in a table. Meaning that the address may exist, i.e. there is a live account with data at that location, or it may not. So deriving an address does not create an account. That is a separate step, and it costs rent (a small SOL deposit, held as collateral for the bytes you occupy on every validator). The derivation is just arithmetic.

Another observation to note is that the program ID is baked into the hash. The same seeds in a different program produce a completely different address. This implies that a PDA belongs to exactly one program, and only that program can authorize writes to it.

The Derivation

On Day 64, I ran a standalone script to make the determinism tangible. The core of it was this:

const [pda, bump] = PublicKey.findProgramAddressSync(
  [Buffer.from("counter")],
  programId
);

Running the same call twice gave the identical address. Running it with "alice" as a second seed gave something completely different, which is the whole point of PDAs.

When the same seeds moved into the counter program itself, they looked like this:

#[account(
    init,
    payer = user,
    space = 8 + Counter::INIT_SPACE,
    seeds = [b"counter", user.key().as_ref()],
    bump
)]
pub counter: Account<'info, Counter>,

Key pieces to note:

b"counter" — a static byte string that namespaces this address. Without it, different account types with the same user key would collide.
user.key().as_ref() — the signer's public key as a byte slice. This is what gives every wallet its own address.
bump — this is a range from 0 - 255, more on this below.
space = 8 + Counter::INIT_SPACE — the 8 is Anchor's discriminator, a prefix that identifies which account type this is.

Why the Seeds Matter

Day 68 especially, was deliberately breaking things, and it was my most instructive day this week.

Compare these two seed arrays:

seeds = [b"counter", user.key().as_ref()]  // per-user PDA
seeds = [b"counter"]                        // global PDA

The first gives every wallet its own isolated counter, while the second gives every wallet the same address, with a first-write-wins collision where whoever calls init_counter first owns the account for everyone. This is not a bug in either case; it is a design choice, just like the config singleton is intentionally global:

seeds = [b"config"],
bump

There's usually only one config per program, derived from a fixed seed, and initialized once. Calling init on an existing account will return a runtime error, so the singleton guarantee is enforced for free.

The near-miss variants from the collision experiment on Day 68 drove the point home. "counter", "counters", "counter\0", and "Counter" each produce a completely unrelated address. There is no fuzzy matching, one byte difference, entirely different account namespace.

The 'Bump' Key Piece

The bump, is the byte (0-255) that makes the whole thing work, even though it seems easy to hand-wave past it.

findProgramAddressSync hashes the seeds together with the program ID and a trailing byte, the bump, which starts at 255 and counting down to 0. Most public keys happen to fall on the ed25519 elliptic curve, which means they could theoretically have a private key. The runtime needs your PDA to be off that curve, so no one can generate a private key for it. The first bump value that produces an off-curve address is the canonical bump, and it is always the same for a given seed + program ID combination.

The canonical bump is the only safe one to use. Anchor finds it for you during init and Anchor also stores it for you (i.e. bump in the constraint and counter.bump in the struct). So that on subsequent instructions, you pass the stored bump back:

#[account(
    mut,
    seeds = [b"counter", user.key().as_ref()],
    bump = counter.bump,
)]
pub counter: Account<'info, Counter>,

Storing and re-passing is important here also, because re-deriving the canonical bump every time costs compute. Storing it once at init and re-using it is free.

The Full Picture

Across the five days, this is how the counter account went through a complete lifecycle:

Derive — findProgramAddressSync on the client, same arithmetic in the program. Both sides agree on the address before any transaction is sent.

Initialize — init allocates the account, sets aside the rent-exempt deposit (lamports — Solana's smallest unit of currency), and populates the fields. This is the moment the address goes from "a possible location" to "a live account."

Mutate — subsequent increment calls re-derive the address from the signer's key and reject the transaction at the constraint layer if anything does not match. No defensive code needed inside the handler.

Close — Close the PDA account and reclaim rent. Day 67 added this, and it took one attribute:

#[account(
    mut,
    close = user,
    seeds = [b"counter", user.key().as_ref()],
    bump = counter.bump,
    has_one = user,
)]
pub counter: Account<'info, Counter>,

Where close = user drains the lamports to the user's wallet and zeros the account data. When a Solana account's balance hits zero, the runtime removes it at the end of the transaction, without any separate delete syscall. A subsequent getAccountInfo returns null, which means that the rent deposit comes back in full, minus the transaction fee.

NB: This is not "delete from a table." The account disappears from the account model entirely. There is no tombstone, no soft-delete flag.

The Little Observations

The program ID is part of the derivation. Same seeds with different program —> different address. A PDA is not portable across programs.
PDAs cannot sign transactions on their own. Only the program can authorize writes to a PDA, by presenting the same seeds internally. This is called signing with "signer seeds" and it happens inside the program, not in the client transaction.
Seed design is access control. Including the user's pubkey in the seeds gives each wallet its own isolated namespace. Omitting it and every wallet shares one account. Both are valid choices, but you have to be deliberate. I saw this clearly when the spoof attempt where Wallet A trying to increment Wallet B's counter, and was rejected before the handler even ran, purely because the re-derived address did not match the supplied account.
init_if_needed is a footgun. It initializes the account if it does not exist, silently does nothing if it does. That silent-do-nothing behavior is exactly the kind of thing that hides bugs in test suites. Reach for it deliberately and always test the already-initialized path explicitly.

Anchor Constraints as an Entire Auth Layer

Russell Oje — Mon, 22 Jun 2026 16:46:13 +0000

This week I made the jump from being a consumer of Solana programs to being a builder of them.

Let me walk you through what I built, what I tested, and the one experiment that made everything click.

The Program: A Counter with an Owner

The running example for the week was a counter program. Simple on the surface — one Pubkey (the owner) and one u64 (the count) — but surprisingly rich in what it teaches.

#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub authority: Pubkey,
    pub count: u64,
}

#[account] stamps an 8-byte discriminator onto the front of every serialised Counter. That discriminator is how the program can later verify "yes, this account was created by me and nothing else." #[derive(InitSpace)] auto-calculates the byte size so you don't have to count fields by hand. One macro, zero arithmetic.

Constraints Are Like Middleware

In a Web2 backend you might write a route guard like this:

if request.user.id != resource.authority_id:
    return 403

In Anchor, you write this instead:

#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut, has_one = authority)]
    pub counter: Account<'info, Counter>,
    pub authority: Signer<'info>,
}

has_one = authority tells Anchor: before the increment handler runs, verify that the authority field stored inside the counter account on-chain matches the authority key passed in this transaction. If they don't match, the transaction fails before your Rust code ever executes. You didn't write an if statement. You declared a rule.

Similarly, the init constraint on Initialize does the heavy lifting of creating the account:

#[account(
    init,
    payer = authority,
    space = 8 + Counter::INIT_SPACE,
)]
pub counter: Account<'info, Counter>,

One attribute makes a CPI to the System Program, allocates the right number of bytes, funds the rent from authority's wallet, assigns the account to your program, and refuses to run if the account already exists. You write one line. Anchor writes the boilerplate.

Testing with LiteSVM

Once the program writes state, you need a way to prove it works. In the earlier epochs, I observed that waiting for devnet confirmations was slow and flaky, which brings LiteSVM into the picture, as it is an in-process Solana virtual machine that can run your compiled .so binary against a fresh ledger in the same Rust test process.

The happy-path test looks like a normal Rust unit test, but it executes a real Solana transaction:

svm.send_transaction(tx).unwrap();

let account = svm.get_account(&counter_kp.pubkey()).unwrap();
let parsed = counter::Counter::try_deserialize(&mut account.data.as_slice()).unwrap();
assert_eq!(parsed.count, 1);
assert_eq!(parsed.authority, authority.pubkey());

State even persists across transactions within one LiteSVM instance — just like a real cluster — so a test that calls initialize and then increment is a genuine end-to-end simulation.

Including Failure Tests

A happy-path test proves the program works. A failure test proves the program refuses. Both are necessary.

I wrote two:

1. Wrong authority is rejected

let init_tx = build_initialize_tx(&svm, program_id, &authority_a, &counter);
svm.send_transaction(init_tx).expect("initialize should succeed");

let bad_tx = build_increment_tx(&svm, program_id, &authority_b, counter.pubkey());
let result = svm.send_transaction(bad_tx);
assert!(result.is_err(), "increment should fail for a different signer");

2. Double-initialization is rejected

svm.send_transaction(first_tx).expect("first initialize should succeed");
svm.expire_blockhash(); // make the second tx genuinely new
let result = svm.send_transaction(second_tx);
assert!(result.is_err(), "initializing the same counter twice should fail");

The expire_blockhash() call is subtle but important. Without it, both transactions are byte-for-byte identical and LiteSVM rejects the second as a duplicate signature — the wrong error. Expiring the blockhash ensures the failure comes from the init constraint, not the duplicate check.

The Mutation Testing Experiment

On friday I deliberately broke the program in three ways, one at a time, and watched the tests catch each regression:

Bug introduced	Test that failed	Why
Removed `has_one = authority`	`increment_fails_when_wrong_authority_signs`	Constraint gone, unauthorized call now succeeds
Changed `checked_add(1)` to `checked_add(2)`	`initialize_then_increment`	Count was 2, expected 1
Commented out `counter.authority = ...`	`initialize_then_increment`	On-chain authority was all-zeros; `has_one` failed at increment time

The third bug was the most instructive. The initialize transaction itself succeeded, i.e. the account was created and rent was paid. The bug only surfaced at increment, when the runtime compared the stored (all-zero) authority to the real signer and found a mismatch. The error pointed downstream of the cause. The tests caught it; the logs explained it.

Take Home

Anchor constraints are not just convenience sugar. They are a declarative authorization layer that runs before your handler, cannot be bypassed by a careless refactor, and produces clear error messages when violated. Combined with LiteSVM's in-process test runner and a suite that includes both happy-path and failure tests, you get a feedback loop that's fast enough to run on every save and trustworthy enough to catch real bugs.

The mutation experiments this week weren't busywork. They were the proof. Every assertion that lit up red when I broke something is an assertion I now trust when it stays green.

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; so 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 complex custom 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.