Typical web and mobile development often starts with a few familiar questions:
- What's the data model going to look like?
- How am I going to handle user accounts and auth?
- Where am I going to host this thing?
Web3 development has its own set of "how do I start?" questions but they're not the same as what you'd expect if you're coming from a Web2 background.
Arc 1 of 100 Days of Solana was all about learning those fundamentals.
What are the Solana equivalents of user accounts, dev/prod environments, data storage, and so on?
Identity starts with a keypair
Identify works differently in the Web3 world. It starts with a keypair, rather than an account someone creates for you.
But the similarities with typical user accounts break down once you look at the detail.
A Solana keypair is created on your own computer.
There is no signup request, no account creation API, and no backend service issuing you an identity. Your machine generates two linked pieces of data:
- a public key
- a private key
The public key is your Solana address. You can share it freely, paste it into a faucet, or look it up in a block explorer.
The private key proves that you control that address. You keep it secret, just like you would keep an SSH private key secret.
The important thing to understand is this:
Creating a keypair gives you a valid Solana address, but it does not automatically create anything on-chain.
That can feel strange if you are coming from Web2. In a normal web app, a user account usually appears only after a row is inserted into a database. On Solana, the address can exist before the network has stored any data for it.
So there are two related ideas:
The address:
This exists as soon as your keypair exists. It is just derived from your public key.
The on-chain account:
This exists on a specific Solana cluster only once the network starts storing state for that address. For example, that might happen when you receive devnet SOL from a faucet.
That means a brand-new address can be completely valid, even if Solana Explorer shows no account data for it yet.
It is a bit like generating an SSH key. You can create the key locally before any server knows about it. The public key is real immediately, but it only becomes useful on a specific server once that server has been told about it. On Solana, your address is real immediately, but a particular cluster only stores account state for it once something happens there.
This is one of the first places where the usual Web2 mental model starts to shift. In a Web2 app, an account usually begins as something a service creates and stores. On Solana, control is cryptographic: you control the wallet because you hold the key that can sign for it. No company needs to store your credentials before the address exists, and no admin panel can recover the private key for you.
That is not the whole story of Solana, but it is one of the foundations everything else builds on. If you do not understand what controls an address, transactions, accounts, tokens, and programs all feel more mysterious than they need to.
From generated key to funded address
If you know one thing about Web3, it might be that each blockchain has its own currency. On Solana, that currency is SOL.
SOL is what pays for activity on the network. In Arc 1, though, we did not start by spending real money. We started with devnet SOL: free test tokens used on Solana’s developer network.
A few lines of @solana/kit produced a brand-new keypair. The important call was small: generateKeyPairSigner() created a signer and returned an address that we could print straight to the terminal.
That first step is intentionally plain. Before there is a wallet app, login screen, dashboard, or account setup flow, there is just a keypair:
a public key, which gives you a Solana address
a private key, which proves you control that address
We then funded that address with free devnet SOL from the Solana faucet. More precisely, the faucet sent lamports to the address. Lamports are the smallest unit of SOL, a bit like cents are to dollars, except 1 SOL equals 1,000,000,000 lamports.
After that, a balance check showed that the address now had account state on devnet.
That is a useful break from the usual Web2 sequence.
In a typical web app, the user account usually starts as a row in a database. The app creates the account, stores the user record, and then the user can do things.
On Solana, the address can exist first. It is valid as soon as the keypair is generated. The network only starts storing account state for that address on a particular cluster once something happens there, such as receiving lamports.
Arc 1 also introduced devnet, one of the most important environments for learning Solana. We were not using local mocks or screenshots of a production system. We were using a real Solana cluster with the same core APIs and concepts as mainnet, but with tokens that have no real-world value.
Persistence makes the key useful
Generating a keypair is only the first step.
If the keypair lives only in memory, it disappears when the script exits. That is fine for a quick demo, but it is not enough if we want to keep using the same Solana identity.
So the next step was persistence. We saved the keypair to a local JSON file, then loaded it again each time the script ran.
That gave us the same address across multiple runs.
This is the point where Solana identity starts to feel less abstract. In a Web2 app, your identity is usually tied to something recoverable: an email address, a password reset flow, maybe a login provider.
With a keypair, the private key is the thing that matters.
If someone has the private key, they can sign transactions for that address. They do not need your password. They do not need your email account. They do not need approval from a backend service.
For devnet, storing a keypair in a local JSON file is fine. There is no real value at stake. But the same approach would be a serious mistake for mainnet funds or production users.
Arc 1 made that visible early:
- Key storage affects security.
- Address reuse affects privacy.
- Signing is how authorization works.
Lamports make value precise
Arc 1 also introduced the unit Solana programs actually work with: lamports.
Wallets usually show balances in SOL because that is easier for humans to read. But Solana code works in lamports because programs need exact whole-number values.
One SOL is 1,000,000,000 lamports.
This should feel familiar if you have worked with payments APIs. Stripe does not ask you to send $19.99 as a decimal amount. It asks for 1999 cents, because money should not be handled with floating point arithmetic.
Solana follows the same basic idea. The network needs every validator to calculate the same result exactly. That means balances, transfers, and fees are represented as integers, not rounded decimal values.
So there are two units to keep straight:
- SOL is the readable display unit.
- Lamports are the exact unit used by the network.
That small distinction teaches a bigger Solana lesson. What humans see is not always what programs store, sign, or verify. As a developer, you need to know when you are dealing with a friendly display value and when you are dealing with the precise value the network will actually use.
The app gets an address, not your private key
After working with raw keypairs in scripts, we connected a real browser wallet.
Using the Wallet Standard and @wallet-standard/app, we built a browser app that could detect installed wallets such as Phantom, Solflare, and Backpack. The app requested a connection, then displayed the selected address and its devnet balance.
That is the important distinction: the app could show the address and read the balance, but it never handled the private key.
The wallet kept custody of the key. The app only received the public address.
For Web2 developers, this is closer to using an external identity provider than asking users to type their password into every app. The app delegates key management to the wallet. When it needs proof that the user controls an address, it asks the wallet to sign something.
But connecting a wallet is not the same as a full login session.
A wallet connection gives the app an address. It tells the app, “This is the address the user has chosen to share.” It does not automatically prove that the user should stay logged in, access a private account, or perform sensitive actions.
For that, an app usually needs a separate signing step. The wallet signs a message or transaction, and that signature proves control of the address. The wallet should ask the user before signing anything meaningful.
That is why real Solana apps should not ask users to paste secret keys into a form. The private key stays in the wallet. The app asks the wallet for addresses and signatures.
Arc 1 covered both raw keypair management and browser wallet connection because they teach different parts of the same model:
Raw keypairs show what is happening underneath.
Wallet connections show how users should normally interact with apps.
If you come from Web2, connecting a wallet can look a bit like “Sign in with Google.”
Your app does not handle the user’s Google password. The user approves access through Google, and your app receives enough information to recognize them.
A Solana wallet plays a similar role in the app experience. It holds the user’s keys, asks for approval, and gives the app a public address to work with.
But the comparison only gets you so far.
Google is an identity provider. It can reset access, suspend accounts, enforce policies, and sit between the user and the apps they use.
A non-custodial wallet is different. It manages keys and asks the user to approve signatures, but it cannot recreate a lost private key. It also cannot invalidate a private key that still exists somewhere else.
That changes the shape of identity.
In a typical Web2 app, identity often starts with a database row. The app creates a user account, stores profile data, and provides recovery flows if something goes wrong.
On Solana, the address is the durable identifier. A signature is the proof that someone controls that address.
Your app can associate data with an address, but it does not own the user’s identity.
That can feel like losing control if you are used to backend-owned accounts. But it is one of the tradeoffs Solana asks developers to understand. Users can bring the same address to different Solana apps. They can connect, approve, disconnect, and move on.
That portability is powerful, but it has a privacy cost. If someone reuses the same address across many apps, their activity may be easier to link together.
That is why the Web2 analogies in Arc 1 are useful, but only up to a point:
- SSH keys help explain keypairs.
- Payments APIs help explain lamports.
- OAuth-style login helps explain wallet connection.
None of those comparisons maps perfectly. But each gives Web2 developers a foothold before the Solana model starts to feel natural.
There is no ordinary password reset
Arc 1 also introduced one of the harder parts of the Solana mental model:
If you lose the private key, there is no ordinary password reset.
In a typical Web2 app, the service controls the account system. That is why it can offer recovery flows. You can reset a password, verify an email address, contact support, or use an identity provider to get back in.
That convenience comes with a tradeoff. The same service can also lock you out, leak credential data, change the rules, or shut the account down.
Solana works differently.
On Solana, control comes from signing. If you can sign with the private key for an address, you control that address. If you cannot sign, the network does not know that you are “really” the owner.
That makes key storage a real product decision, not just a technical detail.
Different approaches make different tradeoffs:
- Browser wallets are convenient, but connected to everyday devices.
- Hardware wallets add protection, but introduce more friction.
- Custodial services can offer recovery, but someone else holds or manages the keys.
- Multisig tools can share control across multiple people or devices.
- Cold storage can improve security, but is less practical for frequent use.
The rule for real apps is simple:
Do not ask users to paste secret keys or seed phrases into your app.
A Solana app should connect to a wallet and ask for signatures. The wallet keeps the private key. The user approves or rejects the request. The app receives only what it needs.
Recovery also has to be designed deliberately. It is not a default support flow you get for free. Seed phrases, hardware wallets, multisig setups, and custody providers all exist because key loss, key theft, and shared control are real product problems.
Once that clicks, self-custody stops sounding like a slogan. It becomes a set of design choices about security, usability, and recovery.
You are building around a different foundation: control is proven by signatures, not granted by a service.
What Arc 1 sets up
By the end of Arc 1, we had worked through the core Solana fundamentals that everything else builds on:
- generating a keypair in code
- understanding public keys and private keys
- funding an address on devnet
- seeing the difference between an address and account state
- saving and reloading a keypair from a local file
- converting between SOL and lamports
- reading raw lamport balances in logs
- connecting a browser wallet to a web app
- understanding that connecting a wallet and signing are separate actions
- explaining Solana identity in our own words
For Web2 developers, some of this should feel familiar.
If you have generated an SSH key, you already have a starting point for understanding keypairs. If you have used “Sign in with Google,” you already have a rough analogy for wallet connection. If you have handled money in cents through a payments API, you already understand why Solana uses lamports instead of decimal SOL values in code.
None of those comparisons is perfect. But they give us useful footholds.
Want to see the full thing? Check out the 100 Days of Solana daily challenge series.
