DEV Community: Russell Oje

The Missing Operations Manual for An On-Chain Autonomous Agent

Russell Oje — Fri, 24 Jul 2026 21:43:23 +0000

Over this concluded week, we built an autonomous Solana devnet agent that checks wallet balances, executes transfers, and works within strict, code-level safety boundaries. Below is the comprehensive runbook and architectural breakdown of the system.

Architectural Lessons

Model Adaptation: The model responds dynamically to tool outputs. When a transaction is blocked by a policy rejection, the LLM adapts by splitting the amount into smaller, valid chunks.
Turn Limits are Essential: A runaway loop could result in high API usage costs. Enforcing a turn limit ensures the agent exits if it gets stuck.
Safety Lives Outside the Prompt: Prompt engineering alone cannot guarantee safe behavior. Every transaction must pass through the policy engine before reaching the blockchain, regardless of what the model decides.
Observability Builds Trust: Detailed logs made it easy to verify every reasoning step, every tool call, and every policy decision. Without them, debugging autonomous behavior would have been significantly harder.
Autonomy is More Than Automation: The agent doesn't execute a fixed script. Instead, it observes its environment, reasons over tool outputs, adjusts its plan when necessary, and stops when the goal becomes impossible or is successfully completed.

End-to-End Request Flow

The following diagram shows how a plain-English request travels through the stack until it becomes a confirmed Solana devnet transaction.

Natural Language Goal
        │
        ▼
+---------------------------+
|      OpenAI Agent Loop    |
|  Decides next tool call   |
+---------------------------+
        │
        ▼
+---------------------------+
|       MCP Server          |
| Exposes available tools   |
+---------------------------+
        │
        ▼
+---------------------------+
|      Read/Write Tools     |
| get_balance / transfer    |
+---------------------------+
        │
        ▼
+---------------------------+
|      Policy Engine        |
| Deny by default           |
+---------------------------+
      │              │
Allowed│              │Denied
      ▼              ▼
+---------------------------+
|     Solana Devnet         |
| Transaction confirmed     |
+---------------------------+

The agent itself never communicates directly with Solana. Every write request must pass through the policy layer first, making the policy engine the single gatekeeper for all fund movements.

System Components

Our agentic stack consists of five modular parts working in unison:

Agent Loop (agent-workflow.mjs): The core reasoning engine powered by OpenAI that takes a natural language goal, decides on tool calls, and runs them up to a turn limit (MAX_TURNS = 12).
Read/Write Tools: Thin Javascript wrappers around Solana Web3 RPC calls that expose get_balance and transfer_sol to the model.
MCP Server (server.ts): Connects our tools to external clients (like VS Code Copilot via .vscode/mcp.json) using standard stdin/stdout protocols.
Policy Engine (policy.mjs): Enforces deny-by-default rules, checking every proposed spend against a recipient allowlist and budget caps.
On-Chain Solana Devnet: The settlement layer where transaction signatures are verified and recorded.

Tool Reference

Tool: `get_balance`

Inputs: address (string, base58 Solana address)
Returns: Stringified JSON containing the account address and balance in lamports.
Side Effects: None (read-only).

Tool: `transfer_sol`

Inputs: to (string, base58 recipient address), lamports (number, amount to transfer)
Returns: JSON object containing transaction status (confirmed, denied, or failed), transaction signature, or failure reason.
Side Effects: Debits the agent's wallet and credits the recipient wallet on-chain if approved.

Log Analysis of a Real Run

Here is the log analysis from our Day 96 trial runs, showcasing how the agent behaves under normal, restricted, and impossible scenarios.

Scenario A: Normal Goal-Seeking Run (0.2 SOL Target)

Initial savings wallet holds 896,000 lamports. Target is 200,000,000 lamports (0.2 SOL).

Turn 1: Model calls get_balance for both operating and savings wallets.
Turn 2: Calculates the difference (199,104,000 lamports) and calls transfer_sol.
Policy Check: Approved (under single-transfer cap of 0.25 SOL).
Turn 3: Model calls get_balance again, verifies the savings wallet holds exactly 200,000,000 lamports, and outputs the final report.

Trying again when the target has been met is properly handled.

Scenario B: Multi-Step Transfer Under Cap (0.4 SOL Target)

Initial savings wallet holds 0.2 SOL. Per-transfer cap is set to 50,000,000 lamports.

Turn 1: Model checks balances, determines a deficiency of 200,000,000 lamports.
Turn 2: Proposes transferring 200,000,000 lamports. The policy engine blocks it for exceeding the per-transfer limit.
Turns 3-6: The agent adjusts and executes four sequential transfers of 50,000,000 lamports. All four are approved and confirm.
Turn 7: Verifies the new balance of 400,000,000 lamports and exits successfully.

Scenario C: Impossible Goal (5 SOL Target)

Turn 1: Agent checks balances: operating wallet has 1.55 SOL, savings has 0.4 SOL.
Turn 2: Agent recognizes it needs 4.6 SOL but only has 1.55 SOL in its operating wallet. It aborts immediately and reports that the goal is impossible to meet, preventing unnecessary transaction attempts.

Usage of Policy as Guardrails

Although the language model is responsible for planning the next action, it has no authority to move funds on its own.

Every transfer request passes through the policy engine before reaching the blockchain.

Current policy rules include:

Default action: Deny every transfer unless explicitly permitted.
Recipient Validation: Only approved wallet addresses can receive funds.
Transfer Cap: Reject any transfer that exceeds the configured maximum amount.
Budget Enforcement: Reject transfers that would exceed the configured spending budget.
Input Validation: Reject malformed addresses or invalid transfer amounts.

From the model's perspective, a denied transfer simply becomes another tool response.

Instead of forcing execution, the model must either adjust its plan or conclude that the goal cannot be completed.

This separation of responsibilities creates the core invariant of the entire system:

The prompt can change. The model can change. The reasoning path can change. No transaction moves funds without passing the policy engine.

Lessons Learnt and Surprises

The biggest surprise throughout this Arc 14 was how naturally the model adapted to changing circumstances.

When a transfer exceeded the configured policy limit, the model didn't repeatedly make the same invalid request. Instead, it interpreted the denial as new information and adjusted its strategy by splitting the transfer into smaller approved chunks.

Another interesting observation was that two runs with the same prompt did not always produce identical tool-call sequences. The reasoning process varied slightly, but the end result remained consistent because every action was constrained by the same policy layer.

Perhaps the most important lesson was realizing that the policy engine, and not the prompt, is the real source of safety. Prompt instructions can influence behavior, but executable rules are what ultimately determine whether funds can move.

The Way Forward

Over this Arc, the challenges reinforced an architectural principle that extends well beyond Solana:

Reasoning should decide what to do. Policy should decide whether it is allowed. The blockchain should record what actually happened.

Separating those responsibilities makes the system easier to audit, easier to extend, and significantly safer than relying on prompt instructions alone.

While this implementation is intentionally limited to devnet, the same layered architecture can serve as a foundation for more capable on-chain autonomous agents in the future.

This article summarizes the agent workflow completed during Arc 14 (Days 92–98) of #100DaysOfSolana.

Check out the Week 14 Workspace.

The Architecture of Guarded Blockchain Agents using Code-Enforced Policies

Russell Oje — Thu, 23 Jul 2026 17:25:31 +0000

Large Language Models can reason, write code, and make decisions, but they also hallucinate, get confused, and can be persuaded to break rules. Prompt engineering helps guide an AI's behavior, but it is not a security mechanism. When connecting an LLM to a live blockchain wallet, the real protection must come from code-enforced policies that explicitly define what actions are allowed and reject everything else by default. Here is how we design a robust, code-enforced, deny-by-default policy layer to protect on-chain assets.

The Illusion of Prompt Security

When developers first build AI agents, they often try to secure them through the system prompt:

"You are a helpful assistant. You have a wallet, but you must never transfer more than 0.1 SOL at a time, and you must never send funds to any address not listed below..."

This is a dangerous anti-pattern. Prompts are instructions, not bounds. Through jailbreaking, role-play attacks, or simple adversarial persuasion, an LLM can be manipulated into ignoring its system prompt. If the agent's tools have direct, unrestricted access to sign and send transactions, a successful prompt injection means your wallet can be drained instantly.

To build secure on-chain agents, we must separate the Reasoning Engine (the LLM) from the Execution and Policy Engine (our code). The model decides what it wants to do; our code decides what is allowed to be signed.

The Guarded Agent Architecture

A secure agentic transaction flow operates like a restricted banking API:

       User Request (Goal)
              |
              v
     +-----------------+
     |   Agent Loop    | <--- LLM reasons and outputs a tool call (e.g., transfer_sol)
     +-----------------+
              |
              v
     +-----------------+
     |   MCP Server /  |
     |   Tool Handler  | <--- Resolves the tool request
     +-----------------+
              |
              v
     +-----------------+
     |  Policy Engine  | <--- Deny-by-default checks (Allowlist, per-tx caps, session budgets)
     +-----------------+
              |
        Approved?
         /      \
      Yes        No
      /            \
     v              v
+----------+   +----------+
| Sign &   |   | Block Tx |
| Send Tx  |   | & Return |
|          |   | Error    |
+----------+   +----------+

In this architecture, the LLM never sees or touches the wallet's private key. The private key resides strictly within the backend execution process. When the agent requests a transfer, the parameters are passed to a hard-coded validator. If the parameters violate any policy, the transaction is rejected immediately before it is even compiled.

Three Pillars of Agentic Wallet Policy

A production-grade agent wallet policy should enforce three layers of protection:

1. Deny-by-Default Allowlisting

Never let an agent send funds to an arbitrary address. The policy should contain a hard-coded set or read-only database of approved recipient addresses. If the target address is not in the set, the execution halts.

2. Per-Transfer Cap

Limit the maximum amount of lamports that can be moved in a single transaction. This prevents a single compromised or runaway model turn from transferring the entire wallet balance.

3. Session / Cumulative budget

A per-transfer cap alone is insufficient; an LLM could run in a loop and execute twenty 0.1 SOL transactions to drain 2 SOL. A cumulative session cap tracks the sum of all successful transfers in the current run and blocks further action once the threshold is crossed.

Lessons from the Field

As we ran experiments with this architecture, several critical insights emerged:

LLMs are adaptive, not deterministic. The same prompt may produce different—but still valid—tool-call sequences.
Policies are more important than prompts. Prompt engineering cannot guarantee safety; executable policy checks can.
Autonomy requires observability. Detailed logs made it possible to understand every reasoning step and verify that safety rules were enforced.
Small constraints encourage better planning. Lower transfer limits forced the model to decompose larger goals into valid sequential actions instead of repeatedly failing.
Devnet is the right proving ground. Autonomous agents should earn trust in a sandbox before interacting with assets of real value.

The Ultimate Integration Checklist to Deploy A Solana Program To Mainnet

Russell Oje — Sat, 18 Jul 2026 10:28:12 +0000

Moving a program to Solana mainnet-beta is the ultimate staging-to-production moment. Mistakes here are not free: they cost real SOL, and a single wrong click can lock up your authority or freeze your bytecode forever. Here is the hands-on launch checklist I wrote after taking my vault program live.

The Background Picture

In Web2 development, a bad deployment is resolved by a quick git rollback or a server restart. On Solana, the blockchain is your server. Your bytecode is deployed into accounts that stay live forever, funded by real-world rent. The wallet that executes the initial deploy silently inherits permanent upgrade authority over that address.

Under launch pressure, relying on memory is a recipe for disaster. That is why astronauts, surgeons, and similarly, smart contract engineers, use checklists. This guide groups the exact steps we walked through across Days 85 to 89 to take our vault program from staging to production, ensuring nothing is missed.

Phase 1: Pre-Flight (Staging on Devnet)

Before committing real value, you must run through staging checks on devnet where failures cost nothing.

☑ All local and integration tests pass perfectly against the final binary.
☑ The build is compiled verifiably.
- Compiling with anchor build --verifiable ensures that the resulting bytecode on-chain can later be matched and verified against your open-source repository. > [!IMPORTANT] > Once you generate a verifiable build, do not run cargo build-sbf or a simple anchor build, as variations in local environment compilation can alter the binary hash and break verification.
☑ Program keys are fully synchronized.
- Sync the program IDs in your workspace with anchor keys sync. Recompile if any changes are made so that declare_id! and the generated key files match.
☑ The deploy wallet is funded.
- Run the rent estimator to see how much SOL the program account will require:
```
solana rent $(wc -c < target/deploy/vault.so)
```
- Ensure the deploy keypair holds enough devnet (and eventually mainnet) SOL to cover this rent plus transaction fees.

Phase 2: The Deploy (Promoting to Mainnet-Beta)

This is the point of no return. Double-check your networks and fee parameters.

☑ The Solana CLI is pointing to the correct environment.
- Confirm with solana config get that the endpoint is set to https://api.mainnet-beta.solana.com (or your private RPC endpoint).
☑ A dedicated RPC endpoint is configured.
- The public mainnet RPC nodes are heavily rate-limited. Deploys consist of dozens of sequential transactions; always deploy via a dedicated RPC (e.g., Helius, QuickNode) wrapped in quotes:
```
anchor program deploy \
  --provider.cluster "https://mainnet.helius-rpc.com/?api-key=YOUR_KEY" \
  -- --with-compute-unit-price 10000 --use-rpc
```
☑ Priority fees and TPU routing are enabled.
- Passing --with-compute-unit-price 10000 (in micro-lamports per CU) and --use-rpc ensures your transactions land safely even during periods of heavy mainnet congestion.
☑ Buffer recovery strategy is prepared.
- If a deploy stalls halfway due to expired blockhashes, your SOL is not lost. It is resting in a temporary buffer. Do not start over! Identify and resume it:
```
# List stranded buffers
solana program show --buffers
# Reclaim buffer rent if abandoning
solana program close [BUFFER_ADDRESS]
```

Phase 3: Authority & Verification (Securing the Contract)

Once the code is on-chain, secure the keys that control it.

☑ Verify upgrade authority immediately.
- Run solana program show [YOUR_PROGRAM_ID] and inspect the Authority field.
☑ Determine the long-term upgrade authority.
- Single Keypair: Keep it only for developer testing.
- Multisig (Squads): The recommended production path. Transfer authority to a multi-signature safe so upgrades require approval from multiple team members (Coming soon...).
- Immutable (--final): Freeze the program permanently. Note that this is a one-way door; you can never fix a bug or add a feature once you freeze it (Coming soon...).

☑ Publish the IDL on-chain.

Make your program self-documenting by publishing the Interface Definition Language schema:

anchor idl init -f target/idl/vault.json [YOUR_PROGRAM_ID] --provider.cluster "https://mainnet.helius-rpc.com/?api-key=YOUR_KEY"

☑ Generate and export the typed client.
- Run Codama to output autocomplete-ready TypeScript helpers for your team or frontend:
```
npx codama run js
```

Phase 4: Frontend Integration & Going Live

Your program is secure and documented; now connect it to the user interface.

☑ Point the frontend to the new mainnet program ID.
- Update the configuration in src/providers.tsx to target Mainnet-Beta.
☑ Test wallet discovery with the Wallet Standard.
- Verify that browser-extension wallets (Phantom, Solflare, Backpack) discover the app smoothly.
☑ Verify error classification is active.
- Ensure that walletErrors.ts is wired to handle user cancellations, insufficient funds, and network failures gracefully instead of throwing raw stack traces.

Lessons Learnt and Surprises

The biggest surprise during this process was how easily a deploy can stall. Without adding priority fees (--with-compute-unit-price) and using a custom RPC, the public endpoint rate-limiting would fail after 10–20 transaction writes, leaving half-finished bytecode stranded in buffers. Understanding buffer management commands and knowing that the rent SOL could be reclaimed via solana program close was a massive relief.

This post summarizes the production launch workflow completed during Week 13 (Days 85–91) of #100DaysOfSolana.

Check out the Week 13 Workspace and the React frontend implementation at my-frontend.

Building a Bulletproof Program in Solana: A Hands-On Security Checklist

Russell Oje — Wed, 15 Jul 2026 08:40:52 +0000

On public blockchains, there are no friendly QA teams to catch your slip-ups before mainnet. The first entity to find a vulnerability in your code should be you. Here is the hands-on security checklist I built after auditing, testing, and intentionally breaking my own Anchor programs.

The Background Picture

Transitioning from a traditional web2 backend to writing Solana programs requires a complete shift in security mindset. On Solana, the execution model is completely different: programs are stateless, so the runtime allows any arbitrary account to be passed into any instruction, and arithmetic overflows wrap silently in release builds.

Under pressure, it is easy to forget routine checks. That is why safety-critical industries use checklists. This checklist translates theoretical security concepts into concrete, verifiable rules that you can run down line by line before any contract touches mainnet.

1. Account Validation (The "Owner Question")

☑ Every account's owner is validated.
☑ Account types are guarded by distinct 8-byte discriminators.

On Solana, if you read an account's data without checking who owns it, an attacker can pass a fake account containing whatever bytes they want. This exact class of vulnerability resulted in the $326 million Wormhole bridge hack.

To understand the mechanics, I rebuilt this vulnerability in a sandbox using LiteSVM. The vulnerable program accepted an UncheckedAccount and deserialized it:

// VULNERABLE: we read this account's bytes without checking who owns it.
let data = ctx.accounts.config.try_borrow_data()?;
let config = Config::try_deserialize(&mut &data[..])?;

Because there was no owner validation, an attacker could set up a custom account owned by the System Program, write a custom config layout with their own public key as the admin, and bypass the authorization checks.

The fix is declarative. By changing the account type to Anchor's typed wrapper, Anchor validates the owner and discriminator before execution:

// SECURE: Account<'info, T> automatically checks the discriminator and program ownership.
pub config: Account<'info, Config>,

2. Authority & Signer Checks (The "Signer Question")

☑ Privileged actions require a verified signature, not just a matching key.
☑ Anchor constraints (has_one or custom constraint) enforce logical ownership.

Just because a public key is passed into your instruction and matches a storage field does not mean that the wallet owner authorized the action. You must verify the signature flag:

#[derive(Accounts)]
pub struct Withdraw<'info> {
    #[account(
        mut,
        seeds = [b"vault", authority.key().as_ref()],
        bump,
        has_one = authority, // Enforces vault.authority == authority.key()
    )]
    pub vault: Account<'info, Vault>,
    pub authority: Signer<'info>, // Verifies the authority signed the transaction
}

3. Arithmetic Safety

☑ Every math operation uses checked arithmetic (checked_add, checked_sub, checked_mul).
☑ All mathematical assumptions are proven using property-based testing.

Rust compiles with overflow checks enabled in debug builds, but in release mode (by default on mainnet), overflows wrap around silently. To ensure safety, we must write pure math functions and stress-test them.

Instead of guessing inputs, we can use property-based testing (proptest) to throw thousands of random numbers at our math module:

pub fn apply_deposit(balance: u64, amount: u64) -> Option<u64> {
    balance.checked_add(amount)
}

#[cfg(test)]
mod tests {
    use super::apply_deposit;
    use proptest::prelude::*;

    proptest! {
        #[test]
        fn deposit_never_shrinks_a_balance(balance in any::<u64>(), amount in any::<u64>()) {
            match apply_deposit(balance, amount) {
                Some(new_balance) => prop_assert!(new_balance >= balance),
                None => prop_assert!(balance.checked_add(amount).is_none()),
            }
        }
    }
}

4. Invariant Fuzzing

☑ State invariants are tested through multi-step instruction sequences.

While unit tests prove isolated logic, vulnerabilities often arise from unexpected interaction sequences. Fuzzing frameworks like Trident allow you to set up guided, automated instruction flows (like running deposit continuously) to ensure your invariants hold:

#[flow]
fn deposit_never_shrinks(&mut self) {
    let before = self.trident.get_account_with_type::<Vault>(&vault_pda, 8).map(|v| v.balance).unwrap_or(0);
    let amount = self.trident.random_from_range(0..1_000_000u64);

    // Process random deposit instruction...

    if let Some(v) = self.trident.get_account_with_type::<Vault>(&vault_pda, 8) {
        assert!(v.balance >= before, "deposit shrank the balance");
    }
}
fn main() {
    FuzzTest::fuzz(1000, 100);
}

The fuzzing campaign was configured using FuzzTest::fuzz(1000, 100). So rather than executing 1,000 individual instructions, the framework generated approximately 1,000 randomized instruction sequences, each containing up to 100 operations. This resulted in roughly 100,000 instruction executions, allowing the program invariants to be validated across a wide variety of automatically generated transaction sequences.

5. Adversarial Testing with LiteSVM

☑ The test suite includes tests designed explicitly to rob the vault.
☑ Assertions check for specific error codes, preventing false positive passes.

A robust security verification flow doesn't just check the happy path; it acts as a pessimist. Write dedicated test cases that mimic penetration attacks—trying to withdraw without a signature, swapping PDA inputs, or attempting to trigger underflows.

#[test]
fn wrong_signer_is_rejected() {
    let mut svm = setup_svm();
    // Craft transaction with invalid signer, send, and verify error code
    let result = svm.send_transaction(tx);
    assert!(result.is_err());
    // Assert the exact Anchor error (e.g. 2006 for ConstraintHasOne)
}

By enforcing specific error code matches, you ensure the transaction failed for the exact security boundary you defined, rather than an unrelated execution error.

One final, but very important check, was to ensure that while these bulletproof methods were in place, our program would not lock out legitimate actors.

This post summarizes what was learnt across Arc12 (Days 78–84) of #100DaysOfSolana. We moved from auditing state accounts, hardening instructions, writing adversarial tests in LiteSVM, to fuzzing code paths with Trident and reproducing real-world vulnerability patterns.

See the complete Arc12 advanced testing repository on Github.

CPI in Solana: A Function Call with a Guest List

Russell Oje — Mon, 06 Jul 2026 16:13:04 +0000

Five days ago, CPI was three letters I had started to recognize in the docs. Now I have watched programs call the System Program, Token-2022, and even my own code.

The Background Picture

A cross-program invocation is exactly what it sounds like: your program pauses, calls an instruction in a different program, waits for it to return, and then picks up where it left off. That description sounds simple, but the first time you stare at a CpiContext you do not feel simplicity; you feel three unfamiliar arguments and a missing mental model.

Every CPI is a function call with a guest list. Your program is the host. The program you are calling is the venue. The guest list is the set of accounts that venue needs to do its job. Before it lets anyone in, the runtime checks three things:

The program being called — identified by its program ID. When you write CpiContext::new(ctx.accounts.system_program.key(), ...), that first argument is the ID of the program you are delegating to. The runtime verifies it is a real deployed program.
The accounts that program needs — which your program has to pass through. The program you are calling cannot see your entire account list. It only sees what you hand it inside the struct you attach to the context. If you forget an account, the inner program gets a lamport discrepancy or an unexpected signer error, not a helpful message.
The signer authority — either a real keypair or a PDA your program signs for. This is the one that took me the longest to understand, so it gets its own section below.

The Code: Smallest Working CPI

Here is the deposit handler from the vault program on Day 73. It is the smallest CPI I have that is doing something real:

pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
    let cpi_ctx = CpiContext::new(
        ctx.accounts.system_program.key(),
        Transfer {
            from: ctx.accounts.user.to_account_info(),
            to: ctx.accounts.vault.to_account_info(),
        },
    );
    transfer(cpi_ctx, amount)?;
    Ok(())
}

#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub user: Signer<'info>,

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

    pub system_program: Program<'info, System>,
}

Three things to notice. First, system_program.key() is the target program ID — the first argument to CpiContext::new. Second, Transfer { from, to } is the guest list, the exact accounts the System Program needs to move lamports. Third, the user is a Signer, so the runtime already has their signature from the outer transaction; it is automatically forwarded into the inner one. No extra work needed.

Signer Seeds: How a Program Proves It Is the PDA

The deposit CPI above is an easy case. The user signed the outer transaction, so the System Program happily accepts their authority over the from account.

The withdraw case is different. The from account is the vault PDA, i.e. an address with no private key. Nobody could have signed the transaction on its behalf. This is where invoke_signed (and Anchor's .with_signer(...)) comes in.

pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
    let user_key = ctx.accounts.user.key();
    let bump = ctx.bumps.vault;

    let signer_seeds: &[&[&[u8]]] = &[&[b"vault", user_key.as_ref(), &[bump]]];

    let cpi_ctx = CpiContext::new(
        ctx.accounts.system_program.key(),
        Transfer {
            from: ctx.accounts.vault.to_account_info(),
            to: ctx.accounts.user.to_account_info(),
        },
    )
    .with_signer(signer_seeds);

    transfer(cpi_ctx, amount)?;
    Ok(())
}

The seeds array in .with_signer(...) is the program saying: "I can reproduce the derivation that created this address. Here are the ingredients." The runtime re-derives the PDA from those seeds plus the calling program's ID and checks that it matches the account you are claiming authority over. If it does, the CPI proceeds as if the vault signed it. If it does not, the transaction fails before any lamports move.

This is the moment invoke_signed clicked for me: the seeds inside your handler have to match the seeds inside your #[account(seeds = ..., bump)] constraint exactly. Those two places are talking about the same address. When they match, you get a vault your program can spend from. When they differ, you get an error.

The Little Observations

On Day 75, I broke the signer seeds on purpose. I changed b"vault" to b"vault!" in the .with_signer(...) call while the constraint on the accounts struct still said b"vault". The runtime error was:

Error: Cross Program Invocation with Unauthorized Signer

It is a short sentence but it is a precise diagnosis. The System Program looked at the vault account in the Transfer struct, expected a valid signature on its behalf; either a real keypair in the transaction or a valid invoke_signed derivation, and found neither. The seeds mismatch meant the re-derived address did not match the vault, so the program's implicit signature was rejected. The fix was to put b"vault" back in both places.

Where to Go Next

The same CpiContext pattern scales without modification. On Day 72, the same three-piece structure called token_interface::mint_to against the Token-2022 program. On Day 74, it called an increment instruction in a second program I wrote, with declare_program!(counter) generating the CPI client from the counter's IDL automatically.

One pattern, three targets, identical shape each time. That is the thing worth internalizing. Once the pattern is solid, picking a new CPI target is mostly reading the target program's accounts struct and mapping it to the guest list.

This post draws from Days 71–75 of #100DaysOfSolana. Day 71 was my very first first CPI. Day 73 was the PDA-signed vault. Day 74 was program-to-program. Day 75 was deliberately breaking all three.

See the complete Arc11 flow on Github

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!

DEV Community: Russell Oje

The Missing Operations Manual for An On-Chain Autonomous Agent

Architectural Lessons

End-to-End Request Flow

System Components

Tool Reference

Tool: get_balance

Tool: transfer_sol

Log Analysis of a Real Run

Scenario A: Normal Goal-Seeking Run (0.2 SOL Target)

Scenario B: Multi-Step Transfer Under Cap (0.4 SOL Target)

Scenario C: Impossible Goal (5 SOL Target)

Usage of Policy as Guardrails

Lessons Learnt and Surprises

The Way Forward

The Architecture of Guarded Blockchain Agents using Code-Enforced Policies

The Illusion of Prompt Security

The Guarded Agent Architecture

Three Pillars of Agentic Wallet Policy

1. Deny-by-Default Allowlisting

2. Per-Transfer Cap

3. Session / Cumulative budget

Lessons from the Field

The Ultimate Integration Checklist to Deploy A Solana Program To Mainnet

The Background Picture

Phase 1: Pre-Flight (Staging on Devnet)

Phase 2: The Deploy (Promoting to Mainnet-Beta)

Phase 3: Authority & Verification (Securing the Contract)

Phase 4: Frontend Integration & Going Live

Lessons Learnt and Surprises

Building a Bulletproof Program in Solana: A Hands-On Security Checklist

The Background Picture

1. Account Validation (The "Owner Question")

2. Authority & Signer Checks (The "Signer Question")

3. Arithmetic Safety

4. Invariant Fuzzing

5. Adversarial Testing with LiteSVM

CPI in Solana: A Function Call with a Guest List

The Background Picture

The Code: Smallest Working CPI

Signer Seeds: How a Program Proves It Is the PDA

The Little Observations

Where to Go Next

Solana: The Byte Tax

Rent Isn't a Metaphor Here

Why This Actually Matters

The Best Part Yet

The Way Forward

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

The Extensions That Make This Possible

Testing the Rules, Not Just Trusting Them

Outside the Theory

The Best Part Yet

The Way Forward

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

The Web2 Way:

Fees Live in Application Code

How Solana Does It:

Baking the Fee into the Currency Itself

Watching It Actually Refuse to Be Bypassed

Outside the Theory

The Best Part Yet

The Way Forward

A Mental Dive into Solana PDAs

The Background Picture

The Derivation

Why the Seeds Matter

The 'Bump' Key Piece

The Full Picture

The Little Observations

Anchor Constraints as an Entire Auth Layer

The Program: A Counter with an Owner

Constraints Are Like Middleware

Testing with LiteSVM

Including Failure Tests

The Mutation Testing Experiment

Take Home

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

The Transfer Fee Mint

The Interest-Bearing Mint

Tool: `get_balance`

Tool: `transfer_sol`