{"slug": "arc-1-recap-keypairs-wallets-and-solana-fundamentals", "title": "Arc 1 Recap: Keypairs, Wallets, and Solana Fundamentals", "summary": "First part of the \"100 Days of Solana\" series, which introduces key Web3 fundamentals. It explains that a Solana identity begins with a locally generated keypair (a public and private key), not a server-created account, and that an address can exist without any on-chain data until it is funded. The recap also covers the use of devnet SOL and lamports to fund a new address for testing purposes.", "body_md": "Typical web and mobile development often starts with a few familiar questions:\n\n- What's the data model going to look like?\n- How am I going to handle user accounts and auth?\n- Where am I going to host this thing?\n\nWeb3 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.\n\nArc 1 of [100 Days of Solana](https://mlh.link/solana-100) was all about learning those fundamentals.\n\nWhat are the Solana equivalents of user accounts, dev/prod environments, data storage, and so on?\n\n## Identity starts with a keypair\n\nIdentify works differently in the Web3 world. It starts with a keypair, rather than an account someone creates for you.\n\nBut the similarities with typical user accounts break down once you look at the detail.\n\nA Solana keypair is created on your own computer.\n\nThere is no signup request, no account creation API, and no backend service issuing you an identity. Your machine generates two linked pieces of data:\n\n- a public key\n- a private key\n\nThe public key is your Solana address. You can share it freely, paste it into a faucet, or look it up in a block explorer.\n\nThe private key proves that you control that address. You keep it secret, just like you would keep an SSH private key secret.\n\nThe important thing to understand is this:\n\nCreating a keypair gives you a valid Solana address, but it does not automatically create anything on-chain.\n\nThat 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.\n\nSo there are two related ideas:\n\n**The address:**\n\nThis exists as soon as your keypair exists. It is just derived from your public key.\n\n**The on-chain account:**\n\nThis 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.\n\nThat means a brand-new address can be completely valid, even if Solana Explorer shows no account data for it yet.\n\nIt 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.\n\nThis 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.\n\nThat 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.\n\n## From generated key to funded address\n\nIf you know one thing about Web3, it might be that each blockchain has its own currency. On Solana, that currency is SOL.\n\nSOL 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.\n\nA 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.\n\nThat first step is intentionally plain. Before there is a wallet app, login screen, dashboard, or account setup flow, there is just a keypair:\n\na public key, which gives you a Solana address\n\na private key, which proves you control that address\n\nWe 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.\n\nAfter that, a balance check showed that the address now had account state on devnet.\n\nThat is a useful break from the usual Web2 sequence.\n\nIn 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.\n\nOn 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.\n\nArc 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.\n\n## Persistence makes the key useful\n\nGenerating a keypair is only the first step.\n\nIf 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.\n\nSo the next step was persistence. We saved the keypair to a local JSON file, then loaded it again each time the script ran.\n\nThat gave us the same address across multiple runs.\n\nThis 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.\n\nWith a keypair, the private key is the thing that matters.\n\nIf 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.\n\nFor 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.\n\nArc 1 made that visible early:\n\n- Key storage affects security.\n- Address reuse affects privacy.\n- Signing is how authorization works.\n\n## Lamports make value precise\n\nArc 1 also introduced the unit Solana programs actually work with: lamports.\n\nWallets 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.\n\nOne SOL is 1,000,000,000 lamports.\n\nThis 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.\n\nSolana 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.\n\nSo there are two units to keep straight:\n\n- SOL is the readable display unit.\n- Lamports are the exact unit used by the network.\n\nThat 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.\n\n## The app gets an address, not your private key\n\nAfter working with raw keypairs in scripts, we connected a real browser wallet.\n\nUsing 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.\n\nThat is the important distinction: the app could show the address and read the balance, but it never handled the private key.\n\nThe wallet kept custody of the key. The app only received the public address.\n\nFor 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.\n\nBut connecting a wallet is not the same as a full login session.\n\nA 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.\n\nFor 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.\n\nThat 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.\n\nArc 1 covered both raw keypair management and browser wallet connection because they teach different parts of the same model:\n\nRaw keypairs show what is happening underneath.\n\nWallet connections show how users should normally interact with apps.\n\nIf you come from Web2, connecting a wallet can look a bit like “Sign in with Google.”\n\nYour app does not handle the user’s Google password. The user approves access through Google, and your app receives enough information to recognize them.\n\nA 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.\n\nBut the comparison only gets you so far.\n\nGoogle is an identity provider. It can reset access, suspend accounts, enforce policies, and sit between the user and the apps they use.\n\nA 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.\n\nThat changes the shape of identity.\n\nIn 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.\n\nOn Solana, the address is the durable identifier. A signature is the proof that someone controls that address.\n\nYour app can associate data with an address, but it does not own the user’s identity.\n\nThat 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.\n\nThat 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.\n\nThat is why the Web2 analogies in Arc 1 are useful, but only up to a point:\n\n- SSH keys help explain keypairs.\n- Payments APIs help explain lamports.\n- OAuth-style login helps explain wallet connection.\n\nNone of those comparisons maps perfectly. But each gives Web2 developers a foothold before the Solana model starts to feel natural.\n\n## There is no ordinary password reset\n\nArc 1 also introduced one of the harder parts of the Solana mental model:\n\n*If you lose the private key, there is no ordinary password reset.*\n\nIn 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.\n\nThat convenience comes with a tradeoff. The same service can also lock you out, leak credential data, change the rules, or shut the account down.\n\nSolana works differently.\n\nOn 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.\n\nThat makes key storage a real product decision, not just a technical detail.\n\nDifferent approaches make different tradeoffs:\n\n- Browser wallets are convenient, but connected to everyday devices.\n- Hardware wallets add protection, but introduce more friction.\n- Custodial services can offer recovery, but someone else holds or manages the keys.\n- Multisig tools can share control across multiple people or devices.\n- Cold storage can improve security, but is less practical for frequent use.\n\nThe rule for real apps is simple:\n\n**Do not ask users to paste secret keys or seed phrases into your app.**\n\nA 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.\n\nRecovery 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.\n\nOnce that clicks, self-custody stops sounding like a slogan. It becomes a set of design choices about security, usability, and recovery.\n\nYou are building around a different foundation: control is proven by signatures, not granted by a service.\n\n## What Arc 1 sets up\n\nBy the end of Arc 1, we had worked through the core Solana fundamentals that everything else builds on:\n\n- generating a keypair in code\n- understanding public keys and private keys\n- funding an address on devnet\n- seeing the difference between an address and account state\n- saving and reloading a keypair from a local file\n- converting between SOL and lamports\n- reading raw lamport balances in logs\n- connecting a browser wallet to a web app\n- understanding that connecting a wallet and signing are separate actions\n\n- explaining Solana identity in our own words\n\nFor Web2 developers, some of this should feel familiar.\n\nIf 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.\n\nNone of those comparisons is perfect. But they give us useful footholds.\n\nWant to see the full thing? Check out the [100 Days of Solana daily challenge series](https://mlh.link/solana-100).", "url": "https://wpnews.pro/news/arc-1-recap-keypairs-wallets-and-solana-fundamentals", "canonical_source": "https://dev.to/100daysofsolana/arc-1-recap-keypairs-wallets-and-solana-fundamentals-2hkj", "published_at": "2026-05-22 10:16:13+00:00", "updated_at": "2026-05-22 10:34:31.524275+00:00", "lang": "en", "topics": ["web3"], "entities": ["Solana"], "alternates": {"html": "https://wpnews.pro/news/arc-1-recap-keypairs-wallets-and-solana-fundamentals", "markdown": "https://wpnews.pro/news/arc-1-recap-keypairs-wallets-and-solana-fundamentals.md", "text": "https://wpnews.pro/news/arc-1-recap-keypairs-wallets-and-solana-fundamentals.txt", "jsonld": "https://wpnews.pro/news/arc-1-recap-keypairs-wallets-and-solana-fundamentals.jsonld"}}