If you come from Web2, identity usually means something managed by a platform. It might be a username on GitHub, an email address tied to your company account, or a password stored in a product database. In all of those cases, identity exists because a service stores it, recognizes it, and decides how authentication works.
This post is my attempt to explain how that changes on Solana in a way a Web2 developer would understand.
Why this felt unfamiliar at first
That is why Solana identity felt unfamiliar to me at first. I kept trying to understand wallets as if they were just another version of app accounts. That mental model was useful for getting started, but it was also misleading. After working through the first five days of 100 Days of Solana, the idea started to make much more sense.
The biggest shift was realizing that a wallet is not really the identity itself. It is the interface for managing the identity. The underlying identity is the keypair.
The SSH analogy that made it click
A Solana keypair feels a lot like an SSH keypair. You have a public key that can be shared, and a private key that stays with you. You prove control by signing with the private key. The basic mechanism is very similar. The difference is that SSH usually proves access to one server, while a Solana keypair works across a whole network.
That distinction matters because it changes what identity actually means. In Web2, identity is usually granted by a platform. A company stores your account, your profile, and your login credentials. If needed, it can lock you out, reset your password, or suspend the account. On Solana, identity is not granted by a company. It is proven cryptographically. If you control the private key, you control the account.
This also makes a public key very different from a username. A username is selected by a user, stored in a company database, and limited to a specific service. A public key is generated cryptographically, portable across applications, and not controlled by one company. The same keypair can be used to hold assets, sign transactions, interact with programs, and participate in governance without creating a separate identity for every app.
What the first five days helped me understand
That idea became much clearer to me because the first week of the challenge forced me to work with the same identity model through different tools.
On Day 1, I generated a keypair and funded it on devnet. That was the first time I really saw a wallet address as something produced from cryptographic keys rather than from account registration. On Day 2, I created a persistent wallet and saved it locally, which made the relationship between the keypair and the wallet feel much more concrete. On Day 3, I looked at balances in both SOL and lamports, which reminded me that the user-friendly wallet experience is only one layer on top of lower-level data structures. On Day 4, I connected Phantom in the browser and saw that my app could read the public address and balance without ever touching the private key. On Day 5, I compared CLI, browser, and mobile wallets and realized that even though their user experience feels very different, they are all ultimately managing the same thing.
The wallet types also made the tradeoffs easier to see:
- The CLI wallet felt the most direct and scriptable, which made it great for development and testing, but it also felt the least secure because the private key was just a file on disk.
- The browser wallet added a much better user experience, with password protection and approval popups, which made it feel more suitable for dApp interactions.
- The mobile wallet felt more natural for personal use because it could rely on device-level protections and a more familiar everyday interface.
What changed in my mental model
What changed across those experiences was the interface and security model. What stayed the same was the identity model.
I think that is the part that makes Solana identity different from the Web2 model many developers are used to. In Web2, identity is usually defined inside a platform boundary. On Solana, identity starts from a cryptographic keypair and can move across applications without asking each one to create or approve a new account. That is why ownership feels different too. The network does not ask whether a company recognizes you. It only checks whether the signature is valid.
If I had to summarize it simply for another Web2 developer, I would say this: on Solana, identity is not a username stored by a platform. It is a cryptographic keypair that you control. Once that idea clicked for me, wallets, ownership, and on-chain interaction all started to make much more sense.
For me, that was the point where Solana identity stopped feeling abstract and started feeling practical.
Top comments (0)