DEV Community: Aborisade Ayomiposi

Solana Transactions Are Not What I Expected (Coming From EVM)

Aborisade Ayomiposi — Thu, 28 May 2026 00:10:54 +0000

I've been building on EVM chains for a while Base, Ethereum, the usual.
I thought picking up Solana would be a lateral move. Same concept, different syntax.

I was wrong, and the transactions are where that became obvious.

What I thought I knew

On EVM chains, a transaction is mostly a wrapper. You have:

A to address
Some value (ETH)
Optional data (the encoded function call)
A signature from your wallet

The RPC figures out what to do with it. You don't think too hard about the
structure. ethers.js handles most of it.

Solana transactions look structurally similar at first glance. You sign something,
you broadcast it. But once you actually build one from scratch, the differences
become hard to ignore.

The anatomy is more explicit

A Solana transaction is made of instructions, and each instruction spells
out exactly which accounts it touches and whether each account is a signer,
writable, or read-only.

You don't just call a function and let the runtime figure out state. You declare
upfront: "This instruction reads from account A and writes to account B."

Here's what building a simple transfer looked like when I did it:

const transaction = new Transaction().add(
  SystemProgram.transfer({
    fromPubkey: sender.publicKey,
    toPubkey: recipient,
    lamports: LAMPORTS_PER_SOL * 0.001,
  })
);

transaction.recentBlockhash = (
  await connection.getLatestBlockhash()
).blockhash;

transaction.feePayer = sender.publicKey;

Three things you set manually that ethers.js would've handled for you:
the instruction, the blockhash, and the fee payer. On Solana, you're closer
to the metal.

The blockhash thing caught me off guard

Every Solana transaction includes a recentBlockhash. It's not optional.
It's what ties your transaction to a specific point in time, and it expires.

If your transaction doesn't land within roughly 60 to 90 seconds, it's dead.
You have to rebuild it with a fresh blockhash and try again.

On EVM chains, you deal with nonces and gas price wars. Transactions can sit
in the mempool for minutes. Solana's model is different: it's intentionally
short-lived. Either your transaction lands fast, or it doesn't land at all.

I actually triggered this on devnet by fetching a blockhash, waiting too long,
and then trying to send. The transaction came back invalid. Once I understood
why, it made sense, Solana is optimizing for speed and finality, not
for letting transactions queue.

Breaking transactions taught me more than building them

The task I was working through asked me to intentionally break transactions
to understand the failure modes. That turned out to be the most useful part.

Some things I broke on purpose:

Sending without enough SOL for rent-exempt balance
Exceeding the compute budget (Solana allocates compute units per transaction, similar to gas but more explicit)
Including too many instructions in one transaction, Solana has a hard 1,232-byte size limit on transactions

That last one doesn't have a direct EVM equivalent. On Ethereum, you can
pack a lot into calldata. On Solana, 1,232 bytes is the ceiling, full stop.
It shapes how you design programs. If you need to do a lot, you batch across
multiple transactions or restructure your logic.

The failed transactions show up on Solana Explorer with a clear error log.
That's actually better than what I'm used to on EVM, where a reverted
transaction sometimes just says "execution reverted" with nothing useful attached.

The mental model that finally clicked

On EVM, I think of a transaction as sending a message to a contract.

On Solana, it's closer to submitting a batch of state changes that either
all succeed or all fail. The accounts are the state. The instructions are the
operations. The transaction is the atomic unit that wraps them.

That's not a huge conceptual leap, but the way you build for it is different.
You think about accounts before you think about logic. You declare intent upfront
instead of letting the runtime discover it.

I'm still early in this. Day 20 of 100. But transactions are the part where
Solana stopped feeling like "Ethereum but faster" and started feeling like
its own thing.

Building through the 100 Days of Solana challenge. If you're doing the same,
feel free to connect.

Reading the Chain, Querying Data, and Understanding Solana's Storage Model

Aborisade Ayomiposi — Tue, 19 May 2026 23:14:18 +0000

Day 8 : Reading On-Chain Data with RPC Calls

This is where things got real. Instead of just generating wallets and checking balances manually, I started making actual RPC calls to read data from the Solana network programmatically.
The one that clicked immediately was getBalance, you pass in a public key, and the network hands you back the wallet's balance in Lamports. Simple, but it made the connection between "wallet" and "on-chain account" feel concrete for the first time.

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

const { value: balanceInLamports } = await rpc
  .getBalance(targetAddress)
  .send();

RPC calls are basically how you talk to the Solana network. No SQL, no REST endpoints you design yourself just a set of predefined functions the network exposes.

Day 9: Querying Recent Transactions

Next I queried transaction history using getSignaturesForAddress. The interesting part was adding a limit, without it, you'd potentially pull back thousands of transactions for an active wallet.

const signatures = await rpc
  .getSignaturesForAddress(targetAddress, { limit: 5 })
  .send();

What impressed me: transactions on Solana are identified by signatures, not IDs like in a traditional database. Every signed transaction leaves a permanent, public record on-chain. You can't hide it, you can't delete it.

Day 10: Building a Dashboard to Visualize It All

After two days of reading raw data from the terminal, I built a simple browser dashboard to visualize everything, wallet balance, recent transactions, the works.

This was the most satisfying day so far. Taking raw RPC responses and turning them into something a non-developer could actually read, that's the frontend instinct kicking in.

Day 11: Solana Accounts vs Traditional Databases

This one reshaped how I think about on-chain storage. Coming from Web2, I instinctively think of data as rows in a table, managed by a database I control. Solana flips that entirely.
Here's the comparison that made it click:

Two things that stood out most: storage costs a refundable deposit on Solana, you get it back when you close an account. And everything is public by default. In Web2 you design for privacy. In Web3 you design assuming everyone can see everything.

Day 12: Devnet vs Mainnet

Short but important. I'd been using devnet the whole time without fully understanding what I was opting into.
Devnet is your staging environment. Free SOL via airdrop, transactions that don't cost real money, a sandbox to break things without consequences.
Mainnet is production. Real tokens, real money, real consequences. What you deploy here lives on the blockchain permanently.
The mental model that helped: devnet is like localhost. You'd never ship straight to mainnet without testing on devnet first, just like you wouldn't push untested code straight to production.

Five days of going deeper into how Solana actually stores and exposes data. The dashboard on day 10 brought it all together visually, but day 11 was the one that genuinely changed how I think about data storage.

Next up: on-chain programs.

From Web2 Dev to Solana: My First 5 Days

Aborisade Ayomiposi — Thu, 14 May 2026 16:43:55 +0000

Day 1 was Understanding Keypairs (The Web3 Identity Shift)

The first thing that clicked for me on day one was how identity works differently in Web3.
In Web2, your identity lives in someone else's database. You create a password, a server stores it, and you prove who you are by matching that password. The platform controls your access.

In Web3, you generate your own keypair two halves that work together. The public key is your identity, like a username anyone can see. The private key is your proof, it signs transactions to confirm you're really you. Nobody generates it for you, nobody stores it for you. That shift from "the platform holds your identity" to "you generate and own it "is the real bridge from Web2 to Web3.

Day 2: Creating a Wallet and Checking Balance

I set up my first Solana wallet programmatically. I used Solana Kit and the generateKeypair function to create a wallet, then checked its address on Solana.

const wallet = await generateKeyPairSigner();

Seeing an actual wallet address generated from code that made it real.

Day 3: SOL and Lamports

Quick but important one. SOL isn't the smallest unit you work with on-chain, Lamports are.

1 SOL = 1,000,000,000 Lamports (10^9)

Think of it like how $1 = 100 cents. When you're reading balances or sending transactions in code, you're almost always working in Lamports. Keep that in mind so you don't accidentally send 1 SOL when you meant 1 Lamport.

Day 4: Connecting a Browser Wallet

This one had a setup detour. I'm on Windows, so before I could install the Solana CLI, I had to set up WSL (Windows Subsystem for Linux) and install Ubuntu. The Solana docs pointed me there once I figured that out it was straightforward.
For the browser wallet connection, I already had Phantom installed as an extension. The key thing I learned: detecting a wallet in the browser isn't enough, you also have to verify it actually supports Solana, since some multi-chain wallets don't.

function isSolanaWallet(wallet) {
  return wallet.chains?.some((chain) => chain.startsWith("solana:"));
} // this function checks if the available wallet are solana compatible

I also learned the difference between Devnet (your development/test environment, free SOL via airdrop) and
Mainnet (production, real money). Always build on devnet first.

Day 5 Wallets: A Real Comparison + The Different Types

Before diving into wallet categories, I compared the three wallets I'd actually used so far and the security differences were eye-opening.

CLI Wallet: the private key is stored in a plain file on your machine. Anyone with access to your file system can find it. Least secure for real use, but fine for dev work.
Browser Extension (e.g. Phantom): the app manages your private key and locks it behind a password. More convenient, but you're limited to password protection.
Mobile Wallet: this one surprised me. Mobile wallets can leverage your phone's hardware fingerprint, Face ID, biometrics. The OS-level security adds a layer that browser extensions simply can't match. For everyday use, mobile is arguably the most secure of the three.

The pattern is obvious: the more the app controls key management and hardware integration, the more secure it gets. CLI gives you raw access but also raw exposure.

Not all wallets are the same. Here's what I mapped out:

Hot Wallet: private key lives on a device connected to the internet. Convenient but more exposed.
Cold Wallet: private key is kept completely offline. More secure, less convenient.
Custodial: someone else (usually an exchange) holds your private key. You trust them with your access.
Non-Custodial: you hold your own keys. True ownership, but full responsibility.
Hardware Wallet: a physical device (like a Ledger) that stores your private key separately from your computer. Best of both worlds for security.
Multi-Signature Wallet: requires multiple signatures to approve a transaction. Great for t eam funds or added security.