Forem: Tanisha fonseca

Solana's Account Model Explained for Web2 Developers

Tanisha fonseca — Mon, 18 May 2026 03:36:32 +0000

Solana's Account Model Explained for Web2 Developers

If you're coming from web development, Solana's account model is probably the first thing that will genuinely confuse you and then, once it clicks, the first thing that will genuinely impress you.

Let me save you a few days of head-scratching.

Think of It Like a Filesystem

Before diving into the technical details, here's an analogy that will carry you a long way:

Solana is a filesystem.

Every account is a file. Each file has metadata (owner, permissions, size) and contents (data). Programs are like executable files chmod +x style. Data accounts are the documents those programs read and write. And the System Program? That's the kernel. It creates files, manages ownership, and handles the lowest-level operations.

Keep that mental model handy. We'll come back to it.

Everything is an Account

In Ethereum, there's a distinction between "externally owned accounts" (wallets controlled by private keys) and "contract accounts" (smart contracts). Different types, different rules.

Solana doesn't do that.

Everything is an account. Your wallet? An account. A smart contract (called a "program" in Solana)? An account. The token balance you hold? Stored in... an account. All of this lives in one giant flat key-value store where:

Key = a 32-byte public address
Value = the account itself

Simple. Uniform. Powerful.

The Five Fields Every Account Has

Pop open a Solana account in the CLI and you'll see something like this:

$ solana account 11111111111111111111111111111111

{
  "lamports": 1000000000,
  "data": "",
  "owner": "NativeLoader1111111111111111111111111111111",
  "executable": true,
  "rentEpoch": 18446744073709551615
}

Every single account on Solana — whether it's a wallet, a program, or a piece of stored state — has exactly these five fields:

1. `lamports`

This is the SOL balance, but measured in the smallest unit: lamports. 1 SOL = 1,000,000,000 lamports (one billion). Think of it like wei to ether, or satoshis to bitcoin. It's just a u64 integer under the hood.

2. `data`

A raw byte array. This is where the interesting stuff lives. For wallets, it's empty. For programs, it holds compiled bytecode. For data accounts (more on those in a moment), it holds whatever state the owning program decides to write there.

3. `owner`

The program address that "owns" this account. This is the key to Solana's security model: only the owner program can modify this account's data or debit its lamports. Anyone can add lamports (credit), but only the owner can take them away or change the data.

4. `executable`

A boolean. true means this account holds a deployable program. false means it's a data/state account. Once set to true, the data becomes immutable — you can't accidentally overwrite a running program.

5. `rentEpoch`

This field is deprecated. You'll always see it set to the max u64 value (18446744073709551615). Ignore it — it's a legacy artifact from how rent collection used to work.

Ownership Rules (and Why They Matter)

Here's Solana's security model in two sentences:

Only the owner program can modify an account's data or debit lamports.
Anyone can credit lamports to any writable account.

That's it. That's the whole access control system.

In web2 terms: the owner is like a Unix file owner with exclusive write permissions. Other programs can look, but they can't touch unless they own it.

This is why, when you interact with a Solana program (say, a DeFi protocol), you have to sign a transaction that authorizes that program to act on accounts you own. The program can only write to accounts where it is listed as owner — it can never reach into your wallet uninvited.

The Surprising Part: Programs Don't Store Their Own State

This is the concept that trips up almost every Web2 developer the first time.

In most backend frameworks, state lives inside the application. Your Node.js server has in-memory state, or it queries a database it owns. Either way, the program and its data are tightly coupled.

On Solana, programs are stateless.

A Solana program stores its compiled code in one account (marked executable: true). Any data it needs to track — user balances, game state, protocol configuration — lives in completely separate accounts that the program owns.

The analogy: imagine a REST API (the program) that never stores anything locally. Every request reads from and writes to a database (the data accounts). The API logic and the database are cleanly separated. The "database" is owned by the API, but the data itself lives outside the code.

In practice, this means when you call a Solana program, you have to tell it which accounts to read and write. You pass them in as part of the transaction. The program can't go looking for its own data — you have to bring it.

This feels weird at first. Then you realize it's what makes Solana blazing fast: the runtime knows exactly which accounts a transaction will touch before it even executes, so it can parallelize transactions that don't share accounts.

Rent Exemption: Paying for Space on Chain

Every account occupies space on every Solana validator in the world. That's not free.

To keep an account alive on-chain, it must hold a minimum lamport balance proportional to the size of its data. This is called being rent-exempt.

For a basic account with no extra data, the threshold is roughly 0.00089 SOL (about $0.10–$0.20 at most price ranges). Accounts above this threshold stay on-chain indefinitely. Accounts below it... don't exist in the first place, because modern Solana tooling simply won't let you create underfunded accounts.

You can check the exact minimum for any given data size:

# Check rent for a 0-byte account
$ solana rent 0

# Output:
# Rent-exempt minimum: 0.00089088 SOL

Or via RPC:

curl https://api.mainnet-beta.solana.com -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getMinimumBalanceForRentExemption","params":[0]}'

The larger the account (more bytes in data), the higher the minimum balance required. Close the account, reclaim the lamports — the space is yours to rent, not buy forever.

Putting It All Together

Here's the mental model, fully assembled:

Solana Concept	Filesystem Analogy
Account	File
`data` field	File contents
`owner` field	File owner (Unix permissions)
`executable: true`	Executable binary (`chmod +x`)
Program account	Application binary
Data account	Data file read/written by the app
System Program	OS kernel
Lamports	Disk quota

When you deploy a Solana program, you're writing an executable file to the filesystem. When that program creates accounts to track state, it's creating data files it owns. When users interact with it, they're running the binary and pointing it at the right files.

Why This Design?

The account model isn't arbitrary. It's designed for performance and parallelism.

Because every transaction must declare its accounts upfront, the Solana runtime can look at two transactions and immediately know whether they can run in parallel (different accounts) or need to be serialized (same accounts). This is how Solana achieves the throughput it does — it's not just hardware, it's the data model.

State separation also means programs are more composable. One program can pass an account it owns to another program, delegating access in controlled ways. The whole DeFi ecosystem on Solana is built on programs handing account authority back and forth.

Your First Mental Checkpoint

Before you write your next line of Solana code, be able to answer these questions:

What's the difference between executable: true and executable: false?
Which account can modify which data, and why?
Why do you have to pass accounts into a program call instead of letting the program find its own state?
What happens to an account that falls below the rent-exempt threshold?

If you can answer those confidently, you understand the account model. Everything else tokens, NFTs, PDAs, CPIs — is built on top of exactly this foundation.

This article is part of my #100DaysOfSolana journey. If you're on a similar path, drop a comment always happy to compare notes.

Solana transactions expire and nobody warned me 💀

Tanisha fonseca — Fri, 15 May 2026 21:47:01 +0000

okay so I need to talk about something that genuinely caught me off guard during #100DaysOfSolana and I feel like nobody explains it properly so here we go

you know how in Web2, if you build an API call and it fails, you just... retry it? same request, same body, send again. worst case you get a duplicate, you handle it with idempotency keys, whatever the request itself doesn't have an expiry date baked in

Solana transactions have an expiry date baked in

like structurally. at the protocol level. you cannot opt out of it

let me explain because this is actually kind of wild

the blockhash thing

every Solana transaction contains something called a recent blockhash. it's a 32-byte hash of a recent block, and it's required you literally cannot construct a valid transaction without one

const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();

const tx = await pipe(
  createTransactionMessage({ version: 0 }),
  m => setTransactionMessageFeePayerSigner(sender, m),
  m => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, m), // 👈 this
  // ...
);

that latestBlockhash you fetched? it's valid for approximately 150 slots

slots happen every ~400 milliseconds

150 × 400ms = 60 seconds

your transaction has roughly 60-90 seconds to land on the network before it is permanently dead. not retryable. not recoverable. you need to build a brand new transaction with a fresh blockhash

why does this exist though

Okay here's where it gets interesting

The blockhash serves two purposes simultaneously and they're both actually really smart:

1. it proves the transaction is fresh

If there was no expiry, someone could intercept your signed transaction and replay it weeks later. the blockhash ties your transaction to a specific point in time after ~150 slots, that blockhash is no longer considered valid, so the transaction dies even if someone tries to resubmit it

2. It prevents literal duplicate transactions

Imagine you send 0.1 SOL to someone. the transaction looks identical to the last time you sent 0.1 SOL to that same person. without the blockhash, the network would have no way to tell "did this already happen or is this a new send?" WITH the blockhash, every transaction is unique because it references a specific recent block

so like... it's doing the job of a CSRF token AND an idempotency key AND a TTL all in one field. that's kind of a lot of work for 32 bytes

what this looks like when it goes wrong

Here's the scenario that'll get you: you build a transaction, get a blockhash, do some other stuff (UI interactions, user confirmations, whatever), and THEN try to send it

// ❌ bad pattern : time passes between fetch and send
const { value: blockhash } = await rpc.getLatestBlockhash().send();

await waitForUserToClickConfirm(); // this takes 2 minutes
await doSomeOtherAsyncThing();     // and this takes another minute

// by here? blockhash might be expired already
const signature = await sendTransaction(signedTx);
// TransactionExpiredBlockheightExceededError 💀

the fix is to fetch the blockhash as late as possible — right before you sign and send, not when you start building

// ✅ fetch blockhash late, sign, send immediately
const tx = buildTransactionWithoutBlockhash(sender, recipient, amount);

// fetch RIGHT before sending
const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();
const txWithBlockhash = setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx);
const signed = await signTransactionMessageWithSigners(txWithBlockhash);

// send immediately after signing
const signature = await rpc.sendTransaction(
  getBase64EncodedWireTransaction(signed),
  { encoding: "base64" }
).send();

minimize the gap between "I got a blockhash" and "I sent the transaction"

and if it expires mid-flight?

sometimes the transaction reaches the network but confirmation takes longer than the blockhash window. this happens more on mainnet under load

the network will eventually return TransactionExpiredBlockheightExceededError and you need to handle this explicitly:

try {
  // wait for confirmation
  const status = await waitForConfirmation(signature);
} catch (err) {
  if (err.message.includes('BlockheightExceeded')) {
    // the transaction is dead, not pending
    // you need to rebuild with a fresh blockhash and try again
    console.log('Transaction expired rebuilding with fresh blockhash');
    return await sendTransfer(sender, recipient, amount); // retry the whole thing
  }
  throw err; // different error, rethrow
}

the key thing: TransactionExpiredBlockheightExceededError is NOT a "try again with the same transaction" situation. that transaction is gone. you build a new one

the thing that makes this different from everything else

In literally every other system I've worked with, "retry" means "resend the same thing"

In Solana, retry means "construct a new thing that does the same action"

your signed transaction isn't a reusable object : it's a snapshot tied to a specific moment in time. once that moment passes, the snapshot is invalid. you're not retrying a request, you're making a new one that happens to do the same thing

This is a mental model shift that took me a minute to actually internalize because it runs against every HTTP instinct I have

tldr

every Solana transaction embeds a recent blockhash that expires in ~60-90 seconds
this is on purpose, it prevents replay attacks and duplicate transactions
fetch the blockhash as late as possible before signing and sending
if a transaction expires, don't retry it, rebuild it from scratch with a fresh blockhash
TransactionExpiredBlockheightExceededError = make a new transaction, not send the old one again

the more I learn about Solana's design decisions the more I realize how much thought went into things that feel annoying at first, this being a perfect example. The expiry isn't a bug, it's load-bearing

Anyway that's what got me this week 🙂

Epoch 1 of #100DaysOfSolana. Writing about the things that actually surprised me so the next person is slightly less confused.

#100daysofsolana #solana #web3 #blockchain

Your try/catch Won't Save You on Solana (and That Cost Me Lamports to Learn)

Tanisha fonseca — Fri, 15 May 2026 21:38:28 +0000

In Web2, failed requests are free.

You misconfigure a Stripe call, Stripe says 400 Bad Request, you fix it, you try again. No charge. The server rejected your request before doing any real work, or if it did do work, the rollback is Stripe's problem, not yours.

I assumed Solana worked the same way. It doesn't. And I found out the expensive way , well, "expensive" in a devnet sense, but the lesson transferred.

The day I broke things on purpose

On Day 19 of #100DaysOfSolana, the challenge was to deliberately trigger failed transactions and inspect them. Not handle them gracefully. Break them intentionally, on purpose, and then read the wreckage.

I generated a fresh keypair with zero SOL:

solana-keygen new --outfile /tmp/broke-wallet.json --no-bip39-passphrase --force

Then tried to send from it:

solana transfer --keypair /tmp/broke-wallet.json $(solana address) 1 \
  --url devnet --allow-unfunded-recipient

Expected: error message, nothing happens.

Got: error message, nothing happens. ✓

Okay, that one the CLI caught locally before anything reached the network. Let me try something that actually hits the chain. I wrote a small script that skips preflight simulation the safety check that normally catches failures before sending and forces a transaction through that's guaranteed to fail on-chain:

import {
  createSolanaRpc, devnet, address,
  createKeyPairSignerFromBytes,
  pipe, createTransactionMessage,
  setTransactionMessageFeePayerSigner,
  setTransactionMessageLifetimeUsingBlockhash,
  appendTransactionMessageInstruction,
  signTransactionMessageWithSigners,
  getBase64EncodedWireTransaction,
  lamports,
} from "@solana/kit";
import { getTransferSolInstruction } from "@solana-program/system";
import { readFile } from "node:fs/promises";

const rpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));

const keyData = JSON.parse(await readFile(
  `${process.env.HOME}/.config/solana/id.json`, "utf-8"
));
const sender = await createKeyPairSignerFromBytes(
  new Uint8Array(keyData)
);

const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();

// Trying to send WAY more than the wallet holds
const tx = await pipe(
  createTransactionMessage({ version: 0 }),
  m => setTransactionMessageFeePayerSigner(sender, m),
  m => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, m),
  m => appendTransactionMessageInstruction(
    getTransferSolInstruction({
      source: sender,
      destination: address("11111111111111111111111111111112"),
      amount: lamports(999_000_000_000n), // 999 SOL — I definitely don't have this
    }),
    m
  ),
  m => signTransactionMessageWithSigners(m),
);

// skipPreflight: true — bypass the safety check, let it fail on-chain
const signature = await rpc.sendTransaction(
  getBase64EncodedWireTransaction(tx),
  { skipPreflight: true, encoding: "base64" }
).send();

console.log("Signature:", signature);

The script ran. It printed a signature. The transaction landed on-chain.

I checked the result:

solana confirm -v [THE_SIGNATURE] --url devnet

Transaction executed in slot 312847103:
  Status:   Error: InstructionError(0, Custom(1))
  Fee:      5000 lamports
  Compute:  3436 units consumed

  Account 0 (sender):
    Before: 1,800,000,000 lamports
    After:  1,794,995,000 lamports  ← wait

The transfer didn't go through. But my balance dropped by 5,000 lamports.

Why this happens (and why it matters more than you think)

When your transaction reaches the Solana network, validators do real work. They:

Verify your signature
Check that the recent blockhash is valid
Load all the accounts referenced in the transaction
Execute the instructions
If execution fails, roll back state changes — but the fee is already gone

The fee compensates validators for steps 1–4. They did that work. They get paid. Your instruction failing at step 4 doesn't undo steps 1–3.

This is fundamentally different from a failed HTTP request.

When your API call to Stripe returns a 400, Stripe either rejected it before doing anything (client-side validation) or caught it in a transaction and rolled back (database atomicity). Either way, you don't get billed per attempt.

On Solana, you do. Every failed on-chain transaction costs a fee. On mainnet, the base fee is still only ~0.000005 SOL per transaction — not a lot. But if you're running a production app that sends transactions in a loop and you have a bug that causes systematic failures? That adds up. And you can't get it back.

The thing that actually saves you: preflight simulation

Solana's RPC has a simulation endpoint. Before sending a transaction for real, you can run it in a sandboxed environment validators simulate execution, return what would happen (including errors), and charge you nothing.

This is what skipPreflight: false (the default) does automatically when you call sendTransaction. It's why my first attempt (the CLI transfer from an empty wallet) failed locally the SDK simulated it first and caught the error before it ever touched the network.

By setting skipPreflight: true in my script, I deliberately bypassed that safety net.

The lesson: preflight simulation is not optional on Solana. It's the economic gatekeeper.

In Web2 terms: it's like client-side form validation. Yes, you should also validate on the server (the network will reject truly invalid transactions regardless). But the form validation is what stops you from wasting a round-trip and on Solana, that round-trip has a real lamport cost.

// Always let preflight run (this is the default don't override it unless you know why)
const signature = await rpc.sendTransaction(
  getBase64EncodedWireTransaction(tx),
  { encoding: "base64" }
  // skipPreflight defaults to false ✓
).send();

What `meta.err` actually tells you

When a transaction fails on-chain, the error lives in the meta.err field of the transaction record. It looks like this:

InstructionError(0, Custom(1))

Breaking this down:

InstructionError the failure was in instruction execution (not signature verification or blockhash expiry)
0 it was the first instruction (zero-indexed) that failed
Custom(1) a program-specific error code. For the System Program, code 1 is InsufficientFunds

As you start writing your own programs, you define your own custom error codes. When something fails in production, this field tells you exactly which instruction, in which program, threw which error. It's your stack trace.

The mental model shift

Here's the reframe that made everything click for me:

In Web2, errors are free information. You throw them, catch them, log them, retry. The cost is compute time, which is cheap and yours.

On Solana, errors that reach the chain have a price tag. Not a punishing one, we're talking fractions of a cent. But the architecture forces you to think about correctness before submission, not just after.

This changes how you write Solana code:

Validate before submitting. Check balances, check account state, check instruction data, off-chain, for free, before sending anything.
Trust preflight. If simulation catches an error, fix it. Don't route around it with skipPreflight: true unless you're doing something very deliberate (like stress-testing failure modes on devnet).
Treat failed transactions in your logs as real events. They cost real fees. They're worth understanding, not just re-trying blindly.

Quick reference

Failure type	Reaches chain?	Fee charged?	How to catch it
Invalid signature	No	No	SDK throws before sending
Expired blockhash	Sometimes	Sometimes	Preflight simulation
Insufficient funds	No (if preflight on)	No	Preflight simulation
Program execution error	Yes	Yes	`meta.err` after confirmation
Compute budget exceeded	Yes	Yes	`meta.err` after confirmation

The most useful debugging habit I've built from Epoch 1: whenever a transaction does something unexpected, paste the signature into Solana Explorer, switch to devnet, and read meta.err and the program logs. It's all there, permanently, for free. The blockchain is a better debugger than console.log ever was.

Day 19 of #100DaysOfSolana. Breaking things on purpose so you don't have to break them by accident.

#100daysofsolana #solana #web3 #blockchain

Solana Transactions Are Not API Calls (But They Kind of Are)

Tanisha fonseca — Thu, 14 May 2026 00:08:48 +0000

Week 3 of #100DaysOfSolana: on anatomy, failures, fees, and why I now read error logs differently.

I've been staring at HTTP request anatomy for years. Headers, body, method, auth token. When someone told me a Solana transaction has a similar structure, I nodded politely and assumed I'd get it quickly.

I did not get it quickly.

Here's what I understand now that I didn't at the start of this arc.

The Structure That Surprised Me

A Solana transaction has two parts: signatures and a message. Simple enough. But the message has a header that does something I hadn't seen before three single-byte numbers that partition the account keys array into permission groups:

How many signatures are required
How many signing accounts are read-only
How many non-signing accounts are read-only

That's it. Three numbers, and the runtime knows the entire permission structure for every account in the transaction. No per-account metadata flags. No separate auth table. The ordering of accounts in the array is the access control.

When I ran solana confirm -v on my first transfer and actually read through the output, this was the part I had to re-read three times. The account keys list isn't just a list of addresses its position carries meaning.

Account Keys:
  [0] Writable, Signer, Fee Payer  → your wallet
  [1] Writable                     → recipient
  [2] Read-only                    → System Program

It's a positional encoding of permissions. Elegant, and also deeply non-obvious the first time.

The 1,232-Byte Wall

Every serialized Solana transaction must fit in 1,232 bytes. This comes from the IPv6 minimum MTU (1,280 bytes) minus 48 bytes of network headers. It is the tightest constraint I've hit so far in this challenge.

Each account key is 32 bytes. A transaction with 10 unique accounts is already using 320 bytes just on addresses. Add a signature (64 bytes), a recent blockhash (32 bytes), instruction headers, and actual instruction data, and you run out of space faster than you'd expect.

This is why Address Lookup Tables exist they let you reference on-chain tables of addresses using 1-byte indexes instead of 32-byte keys. I haven't built with them yet, but now I understand why they exist. That feels like progress.

Failed Transactions Are the Most Useful Thing I Did All Week

Day 19 was "explore failed transactions on purpose" and honestly it should have been day 1.

Here's the thing I didn't know before: failed transactions still cost fees. The network processed your transaction. Validators did the work. They get paid regardless.

This is completely unlike a failed HTTP request. If your API call errors out, you don't get billed per attempt. On Solana, every failed transaction is real lamports gone. The economics of error handling are different.

When I ran solana confirm -v on a deliberately-failed transfer, I saw:

Status: Error: InstructionError(0, Custom(1))
Fee: 5000 lamports charged
Compute Units: 3436 consumed before failure

That 5000 lamports is gone. And the balance changes still show up the fee payer lost lamports even though the transfer did nothing.

Production Solana apps use preflight simulation to catch failures before submitting. It's the blockchain equivalent of validating a form before POSTing it to your server. I understand that pattern now in a way I couldn't have without watching money disappear on devnet.

The Commitment Model is Not Binary

When you send a transaction on Solana, it doesn't go "pending" → "done." It moves through three stages:

Processed a validator included it in a block. Like your POST reaching the server.

Confirmed 66%+ of validators voted on the block. Like getting a 200 OK from a properly load-balanced API. In Solana's entire history, no confirmed transaction has ever been reversed.

Finalized 31+ more confirmed blocks have been built on top. Irreversible by any reasonable threat model.

I added real-time confirmation tracking to my CLI transfer tool on Day 18 — breaking out the stages and reporting each one as it happened. On devnet, processed → confirmed takes about 400ms. Confirmed → finalized takes 6-12 seconds. Watching it happen in the terminal made the whole model concrete in a way reading the docs didn't.

The Web2 Comparison That Actually Holds (and Where It Breaks)

Solana transaction ↔ HTTP request mapping:

Solana	HTTP
Message header	Request headers (metadata, permissions)
Account keys	URL paths + query params (resources)
Instructions	Request body (operations)
Signatures	Auth tokens (proof of authorization)
Recent blockhash	CSRF token with expiry (~60-90 seconds)

The analogy holds pretty well until you hit atomicity. HTTP requests are processed by one server. If the server errors mid-request, partial state changes can persist. Solana transactions are atomic across all instructions — if any instruction fails, all of them roll back. And the transaction is validated by every validator in the network independently before anything changes.

Oh, and if your recent blockhash expires (~150 slots, roughly 60-90 seconds after the block it references), your transaction is dead. You'd need to rebuild it with a fresh blockhash. There's no such thing as "my API call timing out and retrying with the same request", a retry here is a new transaction.

What Week 3 Left Me With

I came into this arc thinking transactions were "the thing you do to move tokens." I'm leaving it understanding that they're signed, atomic, time-bounded, fee-always-charged state transitions with a 1,232-byte budget and a positional permission model.

That's a lot more interesting than "the thing you do to move tokens."

Week 4 is tokens. I'll be back.

Week 3 of my #100DaysOfSolana journey. Writing about what I'm learning so I actually learn it.

#100daysofsolana #solana #web3 #blockchain

I Queried a Blockchain Like a Database and It Kind of Broke My Brain

Tanisha fonseca — Thu, 14 May 2026 00:05:39 +0000

Week 2 of #100DaysOfSolana: on reading public data, comparing accounts to tables, and the moment the "everything is public" thing got real.

Let me tell you about the exact moment week 2 of this challenge stopped feeling theoretical.

I had just written my first getBalance() call. Simple stuff paste an address, get a number back. And then I thought: what if I paste someone else's address?

So I did. I pasted the Token-2022 program address (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb) into my script. Same code, different address. And it just... worked. No API key. No authentication. No 403 Forbidden. Full balance, full transaction history, returned immediately.

That's when the "Solana is a public database" framing stopped being a metaphor and started being a fact I could feel.

What I Actually Built This Week

Week 2 was the Reading the Blockchain arc. Seven days of querying data, building UIs around it, and then staring at the account model until it made sense.

Days 8–9: Reading balances and transaction history

The RPC pattern is genuinely familiar if you've worked with any REST API:

const rpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));
const { value: balance } = await rpc.getBalance(targetAddress).send();

That's it. That's the whole thing. getBalance returns lamports, you divide by 1_000_000_000, you're done. getSignaturesForAddress is just as clean, you get back a list of transaction signatures with slots, timestamps, and status. Felt immediately comfortable coming from a REST background.

Day 10: Moving it to the browser

Same SDK, same calls, just inside a Vite project instead of a Node script. The @solana/kit package bundles fine for the browser, Vite handles it. The interesting part was error handling in a terminal script you can let an error crash and read the stack trace. In a web app, you're catching bad addresses and network failures and actually telling the user something useful.

Day 11: Accounts vs. databases: the comparison that changed how I think

This was the one that took the longest to sit with. I built a comparison table. Here's the short version of what surprised me most:

Thing I assumed	How it actually works
"Storage costs are in my hosting bill"	You deposit lamports proportional to bytes stored. It's refundable. It's per record.
"Access control is my app's job"	The runtime enforces it. Only the owning program can modify an account.
"Data is private by default"	Everything is public by default. Opt-out doesn't exist at the protocol level.
"Code and data are separate systems"	Both live in the account model. Programs are just accounts with `executable: true`.

That last one genuinely surprised me. When I ran solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA and saw executable: true and a BPF Loader as the owner, I had to sit with it for a minute. The thing that runs your code and the thing that stores your data are the same kind of object, just with different contents.

Days 12: Devnet vs. mainnet

Two RPC connections, one URL difference:

const devnetRpc = createSolanaRpc(devnet("https://api.devnet.solana.com"));
const mainnetRpc = createSolanaRpc(mainnet("https://api.mainnet-beta.solana.com"));

Same queries, completely different data. Different balances, different transaction histories, different activity. It's what I'd expect from staging vs. production databases : same schema, separate state — except here "staging" is a whole separate validator network, not a different database on the same server. And the type system in @solana/kit enforces this: you can't accidentally pass a devnet RPC where a mainnet one is expected. That's actually a nice developer ergonomics detail.

The Thing That Still Feels Weird

There are no JOINs. There's no server-side filtering.

In a traditional database, I write a query, the server processes it, and I get back exactly the rows I asked for. On Solana, programs receive accounts as inputs to instructions. If I want to filter or combine data, I do that off-chain via RPC and assemble results myself.

Coming from SQL, this feels backwards. But I think I'm starting to understand why it has to be this way: when thousands of validators are independently processing transactions, you can't have them running arbitrary compute-heavy queries. You need deterministic, bounded operations. The query layer is the developer's problem. The blockchain's job is to execute and record.

It's a constraint that's also the entire point.

What's Next

Week 3 is transactions actually writing state changes instead of reading them. I've been querying this global database for a week. Now I get to write to it.

If you're doing #100DaysOfSolana: what was the hardest mental model shift in week 2 for you? For me it was definitely the rent model: the idea that storage cost is attached to the record itself, not abstracted into infrastructure pricing. Still wrapping my head around the implications.

Week 2 of my #100DaysOfSolana journey. Building in public, one day at a time.

#100daysofsolana #solana #web3 #blockchain

Connecting Phantom to a Web App Changed How I Think About "Login"

Tanisha fonseca — Tue, 28 Apr 2026 01:05:30 +0000

On Day 4 of #100DaysOfSolana, I built a small Vite app that connects to a browser wallet. The feature itself is maybe 30 lines of code. The mindset shift it triggered is harder to measure.

What I Built

A minimal web app that:

Detects installed wallets using getWallets() from @wallet-standard/app
Filters for Solana-compatible wallets by checking wallet.chains
Prompts Phantom to connect with one button click
Displays the connected address and devnet balance

import { getWallets } from "@wallet-standard/app";

const { get } = getWallets();
const solanaWallets = get().filter(wallet =>
  wallet.chains.some(chain => chain.startsWith("solana:"))
);

No API keys. No backend. No session management. The wallet handles all of it.

What Surprised Me

In Web2, "Sign in with Google" feels like a convenience feature, you're still handing your identity to Google, who hands a token to the app. The app trusts Google. You trust Google. Everything flows through Google.

With Phantom, the app never sees your private key. It never talks to a central auth server. It sends a connection request to your wallet extension, which prompts you to approve it. If you approve, the app gets your public address, nothing more. Every subsequent action that needs your signature goes through the same approval flow.

The trust model is completely inverted. The app doesn't authenticate you. You authenticate yourself, and the app just observes the result.

"Sign in with Phantom" isn't "Sign in with Google for Web3." It's closer to showing your passport, the app sees proof of who you are, but it never holds the passport.

What's Next

Week 2 is about writing transactions and moving tokens on-chain. I'm looking forward to seeing how that signing flow works end-to-end from the user clicking a button, to Phantom prompting for approval, to the transaction landing on devnet.

If you're following along, drop your wallet setup experience below. Did anything about the browser wallet model surprise you?

Part of my #100DaysOfSolana journey.

You Already Understand Solana Identity: You Just Don't Know It Yet

Tanisha fonseca — Tue, 28 Apr 2026 00:59:53 +0000

A Web2 developer's guide to on-chain identity, from SSH keys to self-sovereignty

Let me tell you about the moment it clicked for me.

I was on day three of learning Solana, staring at a terminal that had just printed a 44-character string: my new wallet address. I ran one function, and suddenly I existed on a global, permissionless network.

That felt like magic. But it's not magic. It's math you've already worked with before.

The SSH Key You've Been Using Without Realizing It

If you've ever set up a GitHub account with SSH access, you've done this:

ssh-keygen -t ed25519 -C "your_email@example.com"

That command creates two files: a private key (which you protect carefully) and a public key (which you paste into GitHub). GitHub stores your public key. When you git push, your computer signs the request with your private key, GitHub verifies it with the public key you gave them, and you're authenticated no password needed.

Solana identity works on the exact same algorithm. Ed25519. Two keys, one pair.

The difference? On Solana, there's no GitHub in the middle. You don't give your public key to anyone. You broadcast it to a network of thousands of validators, and your identity is established by mathematical proof alone. The "server" that recognizes your key is the entire Solana blockchain.

import { generateKeyPairSigner } from "@solana/kit";
const wallet = await generateKeyPairSigner();
console.log(wallet.address); // Your address

One function call. No server. No company. You just created a valid identity on a global financial network, entirely offline if you wanted to.

Your Username Lives in Someone Else's Database

Here's a thought experiment: open Twitter, GitHub, and your bank in three browser tabs.

In each one, there's a record in a database somewhere that says "this email + this password = this user." That's your identity. And here's the uncomfortable truth: it's not really yours. It's theirs. They let you use it.

Twitter can ban your account. Your followers, your handle, your history — gone.
GitHub can suspend your repositories.
Your bank can freeze your funds pending review.

These aren't hypothetical edge cases. They happen regularly. The companies aren't necessarily being malicious they're following their own rules, regulations, or algorithms. But the point stands: you have access because they allow it, not because you cryptographically own anything.

A Solana address is different at a fundamental level. It looks like this:

14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5

That 44-character string (a 32-byte Ed25519 public key encoded in Base58) is your identity. Not a pointer to a record in a database ,the identity itself. The Base58 encoding is a thoughtful detail: it deliberately excludes characters like 0, O, I, and l that look similar in most fonts, because humans are the ones copying and pasting these addresses.

And ownership of everything associated with that address is proven by one thing only: possession of the corresponding private key. There is no admin panel that can override this. There is no customer support workflow. No one can reset your account because there is no account, there's a cryptographic relationship between a public and private key.

What This Unlocks

At this point, a reasonable Web2 developer might say: "Okay, so it's a decentralized username. Cool, I guess."

But on-chain identity isn't a replacement for usernames. It's a foundation that enables things that simply aren't possible in Web2 without enormous coordination overhead.

Token ownership is the obvious one. When you hold SOL or a token in your wallet, you hold it directly. There's no custodian, no brokerage, no settlement delay. The network's state says your address owns those tokens, and only your private key can authorize moving them.

Program interactions work the same way. Every time you interact with a Solana program (think: a smart contract, a DeFi protocol, an NFT marketplace), you sign the transaction with your private key. The program knows exactly who called it. There are no sessions, no cookies, no JWT tokens to steal.

Governance becomes meaningful. When a DAO votes on a proposal, each vote is a signed transaction. You can verify on-chain that exactly the right addresses cast exactly the right votes, and that no one voted twice. The auditability is free and automatic.

Reputation is portable. In Web2, your reputation on GitHub doesn't follow you to LinkedIn, which doesn't follow you to Twitter. On Solana, your address accumulates history everywhere, every protocol you've used, every NFT you've minted, every DAO you've participated in — and it's all publicly readable by anyone building on the network.

The Tradeoff Worth Naming

None of this is free. The tradeoff for removing the middleman is that you are now responsible for your private key.

In Web2, "I forgot my password" is a solvable problem. There's a reset flow, a support ticket, a backup email. On Solana, if you lose your private key and your seed phrase, your funds are gone. The network isn't being cruel it genuinely cannot help you, because there's no back door to an account that doesn't exist as a record in anyone's database.

This is why wallet UX matters so much. Browser extensions like Phantom and Solflare exist to manage this complexity, they store your private key encrypted behind a password, derive it from a human-readable seed phrase, and let you sign transactions without ever exposing the raw key to the applications you use. Hardware wallets go further, keeping the key inside a physical device that never lets it leave.

The underlying math is the same everywhere. The security model just shifts where you place your trust: in a company's servers, or in your own custody of a string of words.

A Week In

Seven days ago, I couldn't generate a keypair without following a tutorial. Now I understand that a Solana address isn't some exotic blockchain thing it's an Ed25519 public key, the same algorithm your SSH config uses, deployed on a global network instead of a single server.

The cryptography didn't change. What changed is the architecture around it: no central authority, no database, no company that can revoke your access. Just math, validators, and the private key only you hold.

That, I think, is what "decentralized identity" actually means not a buzzword, but a very specific shift in who controls the proof of ownership.

And it started with one function call that printed 44 characters to my terminal.

This post is part of my #100DaysOfSolana series. Follow along as I go from zero to building on Solana, one day at a time.

100daysofsolana solana web3 blockchain beginners*

Forem: Tanisha fonseca

Solana's Account Model Explained for Web2 Developers

Solana's Account Model Explained for Web2 Developers

Think of It Like a Filesystem

Everything is an Account

The Five Fields Every Account Has

1. lamports

2. data

3. owner

4. executable

5. rentEpoch

Ownership Rules (and Why They Matter)

The Surprising Part: Programs Don't Store Their Own State

Rent Exemption: Paying for Space on Chain

Putting It All Together

Why This Design?

Your First Mental Checkpoint

Solana transactions expire and nobody warned me 💀

the blockhash thing

why does this exist though

what this looks like when it goes wrong

and if it expires mid-flight?

the thing that makes this different from everything else

tldr

Your try/catch Won't Save You on Solana (and That Cost Me Lamports to Learn)

The day I broke things on purpose

Why this happens (and why it matters more than you think)

The thing that actually saves you: preflight simulation

What meta.err actually tells you

The mental model shift

Quick reference

Solana Transactions Are Not API Calls (But They Kind of Are)

The Structure That Surprised Me

The 1,232-Byte Wall

Failed Transactions Are the Most Useful Thing I Did All Week

The Commitment Model is Not Binary

The Web2 Comparison That Actually Holds (and Where It Breaks)

What Week 3 Left Me With

I Queried a Blockchain Like a Database and It Kind of Broke My Brain

What I Actually Built This Week

The Thing That Still Feels Weird

What's Next

Connecting Phantom to a Web App Changed How I Think About "Login"

What I Built

What Surprised Me

What's Next

You Already Understand Solana Identity: You Just Don't Know It Yet

The SSH Key You've Been Using Without Realizing It

Your Username Lives in Someone Else's Database

What This Unlocks

The Tradeoff Worth Naming

A Week In

1. `lamports`

2. `data`

3. `owner`

4. `executable`

5. `rentEpoch`

What `meta.err` actually tells you