The onboarding and authentication process in your app as a web3 developer is a big deal, and designing it properly should be a top priority. It cannot be neglected.

In this post, I’ll share the differences between web2 and web3 application authentication setups and some best practices to consider when building an application for public users.

For traditional platforms like social media or productivity tools, authentication is centralized: Google sign‑in, username or email/password, and similar methods. These approaches are standard and highly recommended in web2 because you typically can’t rely on onchain methods; the underlying web3 infrastructure is too complex for most mainstream users.

The same pattern appears in onchain apps, where users connect their wallet and that wallet serves as their core identity.

The key shift is how people think about “onchain applications.” For an application to truly be onchain, it must have some correlation with the Blockchain. The closest touchpoint between you and the blockchain is your wallet address, and any onchain app talks to the blockchain on your behalf through that address. That is your identity.

Recently, there was a post where the author argued against forcing users to connect their wallet to use an onchain app. That perspective can be both valid and invalid, depending on what you are building.

Keep in mind: for an app to be onchain, it has to connect a user to the blockchain through a wallet. Your job as a developer is to make that connection work as smoothly as possible, and the “right” approach depends heavily on your product.

For starters, if your app does not need a user’s past onchain interactions and activity, having them connect a self‑custodial wallet as the primary authentication method may not be ideal. In such cases, you can still offer wallet connection as an optional step for power users, but your main flow should use secondary web3 authentication methods like Privy or other embedded‑wallet solutions. These allow users to sign in with email or social accounts while automatically generating a wallet for them behind the scenes. This pattern is mostly applicable to onchain social apps, games, and consumer apps.

The second option is when there are flows in your app where results cannot be predicted in advance. For example, your app or your wallet‑as‑a‑service provider cannot generate the exact wallet address you need to target.

A good example is my app, Shield, which requires users to connect their wallet because there’s a step where you must upload the receiver’s wallet address for the content you’re sharing. If a service like Privy is used in that flow, the receiver will not be able to access the content, because Privy cannot guarantee generating the exact same account for the wallet address the sender uploaded. So in Shield, the main flow focuses on requiring users to connect their own wallet.

If this is the type of app you’re building, or something similar, then requiring users to connect their wallet is perfectly valid. This is most applicable in token minting apps, DeFi dashboards and asset management tools, P2P apps, and similar products.

Define the main user persona and the architecture of what you are building:

web3 native vs normie vs mixed

Web3 natives → “Connect wallet” first, email/social optional.

Normies → Email/social + embedded wallet first, “Connect external wallet” as an advanced option.

Pure web3 flow: connect EOA wallet, sign message, done.​

Web2‑style + embedded wallet: sign in with email/social, background wallet, optional “connect wallet” later.​

Hybrid / progressive: start with embedded wallet, let users later “upgrade” by linking a self‑custodial wallet and migrating permissions/assets.

The landing page should focus on the value of the app first, not on wallets or crypto jargon. Show what the user can do (share content, play a game, manage assets) before asking them to connect anything.​

When the user clicks “Get started”, offer a clear choice:

A “continue with email / Google / X” path that creates an embedded wallet in the background for non‑crypto‑native users.

An “I already have a wallet” path that lets experienced users connect MetaMask, Coinbase Wallet, Phantom, etc.​

The first in‑app action should be low friction and low risk, but onchain if possible. For example: mint a free item, post once, follow someone, or save a simple piece of content. This helps users immediately feel the benefit of being onchain instead of just seeing a signature popup.​

Briefly explain what “connect wallet” means whenever you show that button: make it clear you are not asking for seed phrases and you cannot move funds without explicit transactions. Small one‑line explanations near the button or in a tooltip work well.​

Introduce basic concepts like signatures, gas fees, and scams exactly at the point where the user encounters them for the first time, not all at once in a long tutorial. This makes the flow feel natural while still protecting new users.

Overall, building an onchain app requires you putting a lot of things into consideration including user experience and your personal experience in building what you intend to build. As time goes on, more people will be familiar with the web3 tech and understand the way the system works.

At the same time, as a web3 dev your focus should also be to bring non-crypto users onchain the most frictionless way possible which demands deep skills and attention to detail in your onboarding and authentication design.

If you’ve read this far, you’re clearly serious about building better onchain products. I’ll be sharing more deep‑dive contents like this soon.

The onboarding and authentication process in your app as a web3 developer is a big deal, and designing it properly should be a top priority. It cannot be neglected.

In this post, I’ll share the differences between web2 and web3 application authentication setups and some best practices to consider when building an application for public users.

For traditional platforms like social media or productivity tools, authentication is centralized: Google sign‑in, username or email/password, and similar methods. These approaches are standard and highly recommended in web2 because you typically can’t rely on onchain methods; the underlying web3 infrastructure is too complex for most mainstream users.

The same pattern appears in onchain apps, where users connect their wallet and that wallet serves as their core identity.

The key shift is how people think about “onchain applications.” For an application to truly be onchain, it must have some correlation with the Blockchain. The closest touchpoint between you and the blockchain is your wallet address, and any onchain app talks to the blockchain on your behalf through that address. That is your identity.

Recently, there was a post where the author argued against forcing users to connect their wallet to use an onchain app. That perspective can be both valid and invalid, depending on what you are building.

Keep in mind: for an app to be onchain, it has to connect a user to the blockchain through a wallet. Your job as a developer is to make that connection work as smoothly as possible, and the “right” approach depends heavily on your product.

For starters, if your app does not need a user’s past onchain interactions and activity, having them connect a self‑custodial wallet as the primary authentication method may not be ideal. In such cases, you can still offer wallet connection as an optional step for power users, but your main flow should use secondary web3 authentication methods like Privy or other embedded‑wallet solutions. These allow users to sign in with email or social accounts while automatically generating a wallet for them behind the scenes. This pattern is mostly applicable to onchain social apps, games, and consumer apps.

The second option is when there are flows in your app where results cannot be predicted in advance. For example, your app or your wallet‑as‑a‑service provider cannot generate the exact wallet address you need to target.

A good example is my app, Shield, which requires users to connect their wallet because there’s a step where you must upload the receiver’s wallet address for the content you’re sharing. If a service like Privy is used in that flow, the receiver will not be able to access the content, because Privy cannot guarantee generating the exact same account for the wallet address the sender uploaded. So in Shield, the main flow focuses on requiring users to connect their own wallet.

If this is the type of app you’re building, or something similar, then requiring users to connect their wallet is perfectly valid. This is most applicable in token minting apps, DeFi dashboards and asset management tools, P2P apps, and similar products.

Define the main user persona and the architecture of what you are building:

web3 native vs normie vs mixed

Web3 natives → “Connect wallet” first, email/social optional.

Normies → Email/social + embedded wallet first, “Connect external wallet” as an advanced option.

Pure web3 flow: connect EOA wallet, sign message, done.​

Web2‑style + embedded wallet: sign in with email/social, background wallet, optional “connect wallet” later.​

Hybrid / progressive: start with embedded wallet, let users later “upgrade” by linking a self‑custodial wallet and migrating permissions/assets.

The landing page should focus on the value of the app first, not on wallets or crypto jargon. Show what the user can do (share content, play a game, manage assets) before asking them to connect anything.​

When the user clicks “Get started”, offer a clear choice:

A “continue with email / Google / X” path that creates an embedded wallet in the background for non‑crypto‑native users.

An “I already have a wallet” path that lets experienced users connect MetaMask, Coinbase Wallet, Phantom, etc.​

The first in‑app action should be low friction and low risk, but onchain if possible. For example: mint a free item, post once, follow someone, or save a simple piece of content. This helps users immediately feel the benefit of being onchain instead of just seeing a signature popup.​

Briefly explain what “connect wallet” means whenever you show that button: make it clear you are not asking for seed phrases and you cannot move funds without explicit transactions. Small one‑line explanations near the button or in a tooltip work well.​

Introduce basic concepts like signatures, gas fees, and scams exactly at the point where the user encounters them for the first time, not all at once in a long tutorial. This makes the flow feel natural while still protecting new users.

Overall, building an onchain app requires you putting a lot of things into consideration including user experience and your personal experience in building what you intend to build. As time goes on, more people will be familiar with the web3 tech and understand the way the system works.

At the same time, as a web3 dev your focus should also be to bring non-crypto users onchain the most frictionless way possible which demands deep skills and attention to detail in your onboarding and authentication design.

If you’ve read this far, you’re clearly serious about building better onchain products. I’ll be sharing more deep‑dive contents like this soon.