DEV Community: Samuel Akoji

What I Found When I Actually Explored Solana Explorer

Samuel Akoji — Sat, 16 May 2026 22:34:43 +0000

The Challenge

Day 26 of 100 Days of Solana is open-ended: explore Solana Explorer, find something interesting, compare it to what you've been doing in the CLI. No starter code, no guided steps. Just go look at the blockchain.

I'll be honest I wasn't sure what "interesting" meant at first. I've been writing scripts for 25 days. I know how to fetch data. But sitting down and just exploring felt different. Here's what I found.

First Stop: My Own Wallet

I started with what I knew my own devnet wallet. Pasted the address into explorer.solana.com, switched to devnet, and there it was: every transaction from the last 26 days laid out in reverse chronological order.

The most recent ones are from Arc 3 the SOL transfers I sent when building the transfer tool. Clicking through them, I could see the exact lamport amounts, the fees (consistently 5000 lamports = 0.000005 SOL), and the System Program invocations.

What struck me: I've been reading this same data through scripts for weeks. Seeing it in Explorer felt like switching from reading a map's coordinates to looking at a satellite photo of the terrain. Same information, completely different feel.

The Transaction That Surprised Me

I found a failed transaction from Day 19, the day we worked on handling transaction failures. I had forgotten about it. The error in the log:

The transaction failed, but it's still there. Still cost 5000 lamports. I remember being confused by that when it happened why do you pay for a failed transaction? Explorer made the answer visual: the validators ran the transaction, confirmed it would fail, and recorded that confirmation. The work happened. The fee was for the work.

Going Deeper: The Token Program

I searched for the SPL Token Program: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

This is the program that powers every token on Solana USDC, USDT, every NFT, everything. Its account in Explorer shows:

Executable: true
Owner: BPF Loader (the program loader for on-chain programs)
Data: the compiled BPF bytecode of the program itself

This was the moment Arc 4's account model lesson clicked for me. The program is an account. The code lives in the data field of that account. When you call the TokenProgram, you're passing a message to this account, which the runtime executes as code.

Mainnet for 10 Minutes

I switched to mainnet and just watched the homepage for a few minutes. Transactions streaming in constantly. I clicked a few at random:

A Jupiter swap: 12 accounts, 3 programs, executed in one atomic transaction
A simple SOL transfer between two wallets: clean, 2 accounts, system program only
An NFT mint: token program, metadata program, and associated token account program all invoked in sequence

The complexity range was wild. A simple transfer and multi-protocol DeFi interactions both look like "one transaction" from the outside. Inside, they're completely different.

CLI vs Explorer: The Real Comparison

Here's the honest comparison after spending a day in Explorer:

CLI is better for:

Scripting and automation
Precise control over RPC calls
Building tools that read data programmatically
Piping output into other commands

Explorer is better for:

Getting a quick visual overview
Debugging failed transactions (the log view is excellent)
Discovering programs and accounts you didn't know existed
Building intuition for what on-chain activity looks like

They're not competing. I'll use both. The CLI is how I build. Explorer is how I verify and understand.

What's Next

Arc 4 is taking us into the account model in depth. After spending a day in Explorer seeing accounts everywhere wallets, programs, tokens, sysvars I feel like I actually understand what "everything is an account" means now. It's not a slogan. It's literally how the whole system is organized.

If you haven't spent time in Explorer yet, do it today. Don't follow a tutorial. Just start with your own wallet and follow the threads.

5 Things to Find on Solana Explorer That Will Level Up Your On-Chain Intuition

Samuel Akoji — Sat, 16 May 2026 22:21:20 +0000

Why Exploration Beats Documentation

You can read about Solana's architecture for hours. Or you can spend 20 minutes on Solana Explorer and see it. This tutorial gives you five specific things to find on Explorer that will make abstract concepts concrete each one tied to something you've already learned in 100 Days of Solana.

Open explorer.solana.com and switch to devnet before starting.

1. Find Your Oldest Devnet Transaction

Search your wallet address in Explorer. Scroll to the bottom of your transaction history. Your oldest transaction is probably the airdrop from Day 1 — when you ran:

solana airdrop 2 <YOUR_ADDRESS> --url devnet

Click that transaction. Notice:

The fee payer is your wallet
The program invoked is the System Program (11111111111111111111111111111111)
The instruction type is Transfer

This is the full on-chain record of the moment you got your first devnet SOL. It's permanent. Even after the challenge ends, this transaction will still be there.

What to notice: The fee for an airdrop is 0 the network pays for it. For the transfers you sent, you'll see a small fee deducted from your account.

2. Find the System Program and Read Its Account

Search: 11111111111111111111111111111111

This is the System Program the most fundamental program on Solana. It handles creating new accounts and transferring SOL. Look at its account details:

Executable: true it's a program, not a data account
Owner: Native Loader native programs are a special case
Data: essentially empty in the account, because native programs live in the validator binary
Balance: 1 SOL the minimum to keep it rent-exempt

Every SOL transfer you've made in the last 26 days went through this account. It has processed billions of instructions since mainnet launch.

What to notice: The executable flag is the only thing distinguishing a program account from a data account. That distinction is fundamental to Solana's account model.

3. Find a Token Account

On mainnet, search for any popular token like USDC: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v

You'll see a token mint account, the on-chain record that defines USDC: total supply, decimals, and the mint authority. This is what SPL token accounts point to when they say "I hold USDC."

Switch back to devnet and look at your own wallet if you've interacted with any tokens, you'll see associated token accounts listed. Each one is a separate account that says "this wallet holds X amount of token Y."

What to notice: Your wallet doesn't directly hold tokens. It owns token accounts that hold tokens. This is why you sometimes pay a small fee to receive a new token creating the token account costs rent.

4. Watch Live Mainnet Transactions

Switch to mainnet and go to the Explorer homepage. You'll see transactions streaming in at roughly 2-3 per second. Watch for a minute.

Notice the variety: some are simple SOL transfers, some are complex DeFi interactions with 10+ accounts and multiple program invocations. The transaction volume and complexity gives you a real sense of what's actually happening on-chain day to day.

Click a random complex transaction and trace through the accounts list you'll start recognizing patterns: DEX programs, token programs, associated token account programs.

What to notice: Solana's throughput is real. This isn't a demo — it's the actual network handling thousands of transactions per second in production.

5. Find a Failed Transaction

In any active wallet's history, look for a transaction with a red "Error" badge. Click it.

You'll see the error message in the log section. Common errors you'll encounter:

InsufficientFundsForRent the account doesn't have enough SOL to stay rent-exempt
InvalidAccountData the program received an account it didn't expect
Custom program error: 0x1 a program-specific error code

What to notice: Failed transactions still get recorded and still cost a fee. The fee is paid for the computational work the validators did to attempt the transaction, even if it ultimately failed. This is an important detail for building resilient Solana apps.

Putting It Together

Each of these five explorations maps to a concept from the first 26 days:

Your airdrop transaction → Day 1 (keypairs and devnet SOL)
The System Program → Day 15-17 (transactions and transfers)
Token accounts → the account model you're learning in Arc 4
Live mainnet → the real network you're building toward
Failed transactions → error handling from Days 18-19

Explorer isn't just a block browser. It's a learning tool. The entire history of Solana is there to read.

Solana Explorer Explained: How to Read Blockchain Data Like a Developer

Samuel Akoji — Sat, 16 May 2026 22:12:50 +0000

What Is Solana Explorer?

If you've spent the last few weeks writing scripts to fetch account balances, decode transactions, and inspect on-chain programs via the CLI, opening Solana Explorer for the first time feels like switching from a terminal to a dashboard. Everything you've been reading in JSON is now laid out visually but understanding what you're looking at is still a developer skill.

This post walks you through Solana Explorer as a developer tool, not just a block explorer. By the end, you'll know what every section means and how it maps to the data you've already been working with in code.

Devnet vs Mainnet Switch First

The first thing to do when opening explorer.solana.com is check which network you're on. The network switcher is in the top-right corner. If you've been working through 100 Days of Solana, most of your activity has been on devnet so switch there first or you won't find your own wallets and transactions.

This is the visual equivalent of setting your RPC endpoint in code:

const connection = new Connection(clusterApiUrl('devnet'));

Mainnet is the live network with real money. Devnet is the sandbox. Explorer shows both just make sure you're looking at the right one.

Anatomy of a Transaction in Explorer

Click any recent transaction and you'll see several sections. Here's how they map to what you know from code:

Signature This is the unique transaction ID, equivalent to the string you get back from sendTransaction(). It's how you look up any transaction on-chain.

Result Success or failure. On-chain, a failed transaction still gets recorded and still costs a fee. Explorer shows you the error message if it failed, which is invaluable for debugging.

Timestamp When the transaction was finalized. Solana's block time is roughly 400ms, so this is nearly real-time.

Fee Shown in SOL. Transaction fees on Solana are tiny usually around 0.000005 SOL (5000 lamports). You've worked with lamports in code; Explorer converts them to SOL for readability.

Account Inputs This is the list of accounts involved in the transaction. Every Solana transaction must declare upfront which accounts it will read or write. You'll see which accounts are marked as writable and which are signers.

Instruction Data The raw instruction sent to a program. For simple SOL transfers this is minimal, but for program interactions it contains the encoded instruction arguments.

Log Messages This is the most useful section for developers. Every msg!() call from a Solana program shows up here. When your program panics or hits an error, the log is where you'll find out why.

Finding Your Own Wallet

Paste your devnet wallet address into the search bar. You'll see:

SOL Balance in SOL, with the lamport equivalent
Token Accounts any SPL tokens you hold
Transaction History every transaction this wallet has signed, in chronological order

Compare this to what you'd get from the CLI:

solana balance <YOUR_WALLET_ADDRESS> --url devnet
solana transaction-history <YOUR_WALLET_ADDRESS> --url devnet

Explorer gives you the same data, just navigable. The CLI gives you the same data, just scriptable. Both are reading from the same on-chain state.

Exploring a Native Program

Search for 11111111111111111111111111111111 this is the System Program. Every SOL transfer goes through it. In Explorer you'll see it marked as a native program with the executable flag set to true and a data field that's essentially empty (native programs live in the validator, not in account data).

This is a concept you'll explore deeper in Arc 4: on Solana, programs are just accounts with executable: true. The System Program is the most fundamental one it handles account creation and SOL transfers.

What Explorer Can't Tell You

Explorer is read-only and retrospective. It shows you what happened, not why. For debugging a failing program, you still need your logs and local testing. For building, you still need the SDK. Explorer is the lens you use to verify not the tool you use to build.

Takeaway

Every CLI command you've run in the last 26 days has been reading from the same data that Explorer displays. The difference is interface, not information. Use Explorer to verify your work, explore unfamiliar programs, and build intuition for what on-chain activity looks like at scale.

Decoding Raw Account Data with Borsh

Samuel Akoji — Thu, 14 May 2026 19:30:00 +0000

Day 24 of #100DaysOfSolana

Yesterday I built a terminal account explorer. But that data field kept staring back at me a blob of base64 with no obvious meaning.

Today I cracked it open.

The problem

Every Solana account stores its state as a flat byte array. There's no JSON, no column names, no built-in schema. The program that owns the account defines how those bytes are laid out using a serialization format called Borsh (Binary Object Representation Serializer for Hashing).

To read account data, you need either:

A pre-built codec for that account type, or
The byte-level specification to decode it manually

What I decoded

I used the Wrapped SOL mint account on mainnet as my target a well-known SPL Token account with a fixed 82-byte layout.

Method 1 Pre-built codec (the easy path)

import { getMintDecoder } from "@solana-program/token";

const decoded = getMintDecoder().decode(accountData);
console.log(decoded);

One line. Returns a fully structured object with supply, decimals, mintAuthority, and more. This is what you'd use in production.

Method 2 Manual byte decoding (the learning path)

The 82-byte Mint layout:

Bytes	Field	Type
0–3	mintAuthorityOption	u32
4–35	mintAuthority	32-byte pubkey
36–43	supply	u64 (little-endian)
44	decimals	u8
45	isInitialized	bool
46–49	freezeAuthorityOption	u32
50–81	freezeAuthority	32-byte pubkey

const view = new DataView(data.buffer);

const supply = view.getBigUint64(36, true); // true = little-endian
const decimals = view.getUint8(44);
const isInitialized = view.getUint8(45) === 1;

Two things to understand here:

DataView lets you read multiple adjacent bytes as a single typed value (u32, u64, etc). You'd use it to parse any binary format, not just Solana.

Little-endian flag (true) Solana stores all multi-byte numbers least significant byte first. Forgetting this flag is the single most common decoding bug. Every multi-byte read needs true.

Method 3 RPC jsonParsed (the shortcut)

const { value } = await rpc.getAccountInfo(address, {
  encoding: "jsonParsed"
}).send();

The RPC decodes it server-side for known programs. Great for quick checks but only works for well-known programs. For custom programs, you bring your own decoder.

All three methods returned identical values. ✅

The three encodings you'll see everywhere

Encoding	When you see it
Base64	RPC account data responses
Base16 (hex)	Debugging 1 byte = 2 chars, easy to count
Base58	Solana addresses

They're all just different spellings of the same underlying bytes.

Why this matters

When you write your own Solana programs, you'll define Rust structs → Borsh serializes them into byte arrays → your frontend deserializes them back. Today I proved I can do that translation by hand.

No more mystery blobs.

Day 24 down. Still shipping daily as part of 100 Days of Solana with MLH

solana #web3 #blockchain #100daysofsolana

I Built a Terminal Account Explorer (Mini Solscan)

Samuel Akoji — Thu, 14 May 2026 13:00:00 +0000

Day 23 of #100DaysOfSolana

Today I stopped staring at raw terminal output and built something actually useful: a CLI tool that takes any Solana address and prints a clean summary of the account balance, owner, data size, and whether it's executable.

Think of it as your own mini Solscan, no browser required.

What I built

A Node.js script (explorer.mjs) that:

Accepts any Solana address as a CLI argument
Fetches balance via getBalance and account metadata via getAccountInfo
Converts lamports to SOL (divide by 1,000,000,000)
Maps owner addresses to friendly names (System Program, Token Program, etc.)
Truncates large data fields so your terminal doesn't explode

Stack: @solana/kit, ES Modules, devnet RPC

The core insight

Every single account on Solana — wallets, token accounts, deployed programs — is described by the same 5 fields:

Field	What it tells you
`balance`	How much SOL (in lamports)
`owner`	Which program controls this account
`data`	Custom bytes stored in the account
`executable`	Is this account a runnable program?
`rent_epoch`	When rent was last collected

The difference between a wallet and a smart contract is literally one boolean: executable.

What surprised me

Block explorers like Solscan and SolanaFM aren't doing anything special. They call the same getBalance and getAccountInfo RPC methods I used today — they just wrap the output in a web UI.

Building the raw version yourself gives you a mental model that no tutorial skips to.

Try it yourself

node explorer.mjs TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Run it against the Token Program address. You'll see executable: true and the System Program listed as owner.

Then try your own devnet wallet — executable: false, zero data, System Program owner.

Day 23 down. Still shipping daily

solana #web3 #blockchain #100daysofcode #javascript

Inspecting Raw Account Data with the Solana CLI

Samuel Akoji — Thu, 14 May 2026 10:01:23 +0000

Day 22 of #100DaysOfSolana

Today I went under the hood. No code just the Solana CLI and three account inspections that changed how I see the whole network.

Inspection 1 — My own wallet

solana account $(solana address)

Output:

Balance: 2 SOL
Owner: 11111111111111111111111111111111
Executable: false
Length: 0 bytes

Owned by the System Program. Not executable. Zero bytes of custom data. Just a balance.

Inspection 2 — The SPL Token Program

solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Executable: true
Owner: BPFLoader2111111111111111111111111111111111
Data: [compiled program bytecode]

Same five fields — completely different values. This is a runnable program, loaded by the BPF Loader, with actual bytecode in the data field.

A native built-in program. The only one on Solana that can create new accounts. Compare its fields to both above and the pattern becomes clear.

The five fields every account shares

Field	What it means
`lamports`	SOL balance in the smallest unit
`data`	Arbitrary byte array (empty for wallets)
`owner`	The program that controls this account
`executable`	Is this account runnable code?
`rentEpoch`	Legacy field, no longer actively used

The key insight

On Solana, everything is an account. Wallets, programs, token balances, NFT metadata, game state — all accounts, all with the same five fields.

The difference between a wallet and a smart contract is:

One boolean: executable
One address: what sits in owner

This is different from Ethereum, where wallets and contracts are distinct concepts. On Solana, it's accounts all the way down.

The owner field is the security model

Only the owning program can modify an account's data or deduct its lamports. That's why:

The System Program handles SOL transfers → it owns wallets
The Token Program moves tokens → it owns token accounts
Your custom program controls its state → it will own the accounts it creates

Understanding this is foundational for everything that comes next.

Same fields, machine-readable. Useful for scripting or piping into other tools.

Day 22 down.

solana #web3 #blockchain #100daysofsolana

Solana Transactions Explained for Backend Developers

Samuel Akoji — Mon, 11 May 2026 08:01:59 +0000

I've sent hundreds of HTTP requests in my career. POST to an endpoint, get a 200 back, move on. When I started building on Solana, I assumed transactions would feel similar. They don't and understanding exactly why changed how I think about on-chain programming entirely.

The Web2 mental model (and where it breaks down)

In a typical backend system, you call an API: you send a payload, a server processes it, and you get a response. The server holds authority. Authentication is usually a session token that the server validates against its own database.

Solana transactions have a surface-level resemblance to this you send something to the network, it gets processed, you get a result. But three things make the comparison fall apart quickly:

1.The transaction itself is the authority: There's no session. There's no server checking a database. Authority comes from a cryptographic signature attached to the transaction computed with your private key, verifiable by anyone. If the signature is valid, the instruction runs. Period.

2.** Everything is atomic**: A transaction bundles one or more instructions, and they all succeed or all fail together. This isn't just a convenience it's a security guarantee baked into the runtime.

3.It expires: A transaction is only valid for roughly 60–90 seconds, anchored to something called a recent blockhash. No stale replays. No indefinitely reusable tokens.

The anatomy of a Solana transaction

Before writing any code, I found it useful to understand what a transaction is actually made of. There are four core pieces:

Signatures
Ed25519 signatures from every required signer. The fee payer always signs. Programs can require additional signers.

Recent blockhash
A hash of a recent block. Acts as a TTL transactions referencing an expired blockhash are rejected outright.
**
Instructions**
The actual work. Each instruction targets a program, specifies accounts, and passes instruction data.

Accounts
Every account the transaction will read or write declared upfront. Validators use this to parallelize execution.

If you're coming from backend development, the hardest part of Solana isn't the syntax it's unlearning the assumption that authority lives on a server. Once you internalize that signatures are the authority, the rest of the transaction anatomy follows naturally.

Day 20 of #100DaysOfSolana.
Devnet explorer is open in a permanent tab now.

I Made my First solana transfer

Samuel Akoji — Tue, 05 May 2026 13:53:32 +0000

Made my first SOL transfer on devnet today.
Not a big moment by most standards. 0.001 SOL, sent to a temporary wallet I spun up just to have somewhere to send it. But watching it actually land — seeing the balance update, the transaction confirm — made something click that reading docs never quite did.
A few things I had to get right before it worked:

Generate a fresh keypair and save it locally
Use --allow-unfunded-recipient because the destination account didn't exist yet
Make sure I was pointed at devnet and not somewhere else entirely

That last one would have cost me real money in a different context. Glad I learned it here.

Understanding transaction anatomy

Samuel Akoji — Tue, 05 May 2026 13:31:03 +0000

Today I stopped treating a Solana transaction as a black box and looked at what's actually inside one.
Every transaction is a signed message made up of four parts:

A header that defines permission groups for all accounts involved
A list of account keys the resources the transaction touches
A recent blockhash proof of freshness and protection against replay attacks
Instructions the actual operations, each pointing into the account keys array by index

Traditional Databases vs Solana Accounts

Samuel Akoji — Tue, 05 May 2026 12:45:47 +0000

Today on my learning journey i learnt about the difference between a solana account and the traditional database.

Key Difference
Accounts do not query each other.

There is no JOIN
No server-side filtering
Programs receive accounts as inputs to instructions
If you want to "query" data:

You do it off-chain via RPC
Then assemble the results yourself

My second Week Playing Around Solana

Samuel Akoji — Mon, 04 May 2026 11:54:19 +0000

I'll be honest before I started, I think I expected blockchain data to feel exotic. Like there'd be some kind of ceremony to accessing it. What I got instead was a JSON RPC endpoint. You call it, it talks back. That was the first surprise: how boring the infrastructure felt in the best possible way. It's just a database you can ask questions to. The "public ledger" framing stopped being an abstraction the moment I ran my first solana balance call and watched a real wallet's balance show in my terminal,or even request faucet and receiving it in my wallet in real time and the balance displayed on my terminal too.

What clicked fastest was the account model. Once it landed that everything on Solana is an account programs, token balances, even program state a lot of the weirdness started resolving itself. It's almost like a filesystem. Programs live at addresses. Data lives at addresses. You're mostly just reading from addresses. That felt intuitive once I stopped trying to map it onto how I thought blockchains were supposed to work.

What surprised me most about the SDK was how much the ecosystem leans on you knowing what you're looking for before you go looking. With a REST API, you usually get back something self-describing field names that hint at meaning, maybe some docs that walk you through a response shape. With Solana RPC, especially reading raw account data, you get back a base64-encoded blob and a polite shrug. You need the program's IDL to make sense of it. That's not a flaw exactly, it's just a different contract between the API and the developer one that assumes more context up front.

What's still fuzzy: the fee and priority fee model. I understand the mechanics loosely you attach a compute budget, you bid for inclusion but the intuition hasn't formed yet. One thing I did learn along the way: SOL isn't the smallest unit you're working with. That's lamports 1 SOL is made up of 1,000,000,000 lamports. So when amounts come back from the RPC, they're in lamports, and you have to divide by a billion to get back to SOL. It's a small thing but it catches you off guard the first time you see a balance and think someone is inexplicably wealthy. That's probably my next step.

You Already Understand Blockchain Identity (You Just Don't Know It Yet)

Samuel Akoji — Sun, 26 Apr 2026 16:32:59 +0000

If you've ever set up SSH access to a server, you already understand the core idea behind identity on Solana. You generated a keypair. You dropped the public key on the server. From that point on, you proved who you were not with a password but by signing challenges with your private key. The server trusted the math.
Solana works the same way, except instead of one server, the "server" is the entire global network, and your keypair is your identity everywhere on it at once.
The problem with Web2 identity
Think about how fragmented your identity actually is right now. You have a username on GitHub, an email address at work, a login at your bank, and an account on every SaaS tool your team uses. Each one is a separate record in someone else's database. Each one is granted to you by that company and can be revoked by them at any time. Forget a password? You depend on their reset flow. Get suspended? You're locked out entirely. Want to prove to a third party that you're the same person across two platforms? That's someone's API integration problem.
None of these identities are yours. They're access tokens that someone lends you.
A keypair is different
On Solana, your identity is a cryptographic keypair specifically, an Ed25519 keypair. That generates two things: a public key, which is your on-chain address and safe to share with anyone; and a private key, which you never share and which is the only proof of ownership the network recognizes.
Your public key looks like this: 14grJpemFaf88c8tiVb77W7TYg2W3ir6pfkKz3YjhhZ5
That's a 32-byte key encoded in Base58 a format chosen specifically to be human-readable. Base58 strips out visually ambiguous characters like 0 vs O and I vs l, so addresses can be read, copied, and verified without confusion. It's not a username someone assigned you. It's derived mathematically from your private key, and it exists independently of any company's database.
There is no account to create. There is no service to register with. You generate the keypair, and you have an identity.
What "ownership" actually means
In Web2, "owning" your account means a company stored your credentials and decided to give you access. They can change that decision. On Solana, ownership means something more precise: only the holder of the private key can produce a valid signature for that address. Every transaction on the network is cryptographically signed. The network checks the math. If the signature is valid, the transaction goes through. There is no admin panel, no customer support escalation, no override.
This is the tradeoff worth understanding clearly: you gain total control, and you take on total responsibility. Lose your private key or seed phrase and there is no recovery path. No one can help you. That's not a bug it's the same property that makes the ownership real.
Identity as infrastructure
Here's where it gets interesting for developers. In Web2, identity is mostly about authentication proving you're you so you can log in. On Solana, identity is the foundation for everything else.
Because your keypair is universal across the network, it's the same identity you use to hold tokens, interact with programs, participate in governance votes, and build up on-chain reputation. When you connect your wallet to a Solana app, you're not creating a new account with that app. You're presenting the same cryptographic identity you use everywhere else, and the app reads what's already associated with it on-chain.
No integrations needed. No OAuth handshakes. No, sign up with GitHub. Your identity is already there, and anyone building on the network can read it.
The mental shift
The shift from Web2 to on-chain identity is less about learning new technology and more about internalizing a different ownership model. You're used to identity being something a service grants you and can take away. On Solana, identity is something you generate, and it belongs to whoever controls the key.
That's unsettling; at first there's no help desk. But it's also the thing that makes every application on the network composable by default. Your address is the same everywhere. Your assets follow you. No one can revoke access.
It starts with a keypair. Everything else is built on top of that.

100daysofsolana #solana #web3 #blockchain and #beginners