Skip to main content

Command Palette

Search for a command to run...

Ship Email Login for NEAR Without Building Wallet Infrastructure

Updated
7 min read
Ship Email Login for NEAR Without Building Wallet Infrastructure
C
Behind the scenes of launching Peerfolio - the discovery platform for trustworthy crypto.

If you've been building consumer-facing apps on NEAR, you already know the problem. You want to offer email-based control of blockchain accounts. Your users expect it. But getting there has meant too much boilerplate code before you can write a single line of your actual product.

We built privy-near-connect to fix that, and we're open-sourcing it as a public good for developers.

The problem

Privy is one of the largest embedded wallet providers, offering web2-style account control via email, phone, or social login. Secured by their Threshold Signature Schemes infrastructure aka Multi-Party Computation key management – where signatures are produced collaboratively without revealing or centrally storing a complete private key.

Developers across the NEAR ecosystem were surveyed and wallet infrastructure kept coming up as one of the most cited pain points. At hackathons, teams were losing precious time to authentication boilerplate. That's the gap privy-near-connect fills.

Privy announced support for the NEAR Protocol in August 2025. The catch: NEAR is a Tier 2 chain on Privy, not natively supported like Privy’s Tier 3 chains: Solana and Ethereum. That distinction matters significantly.

Tier 2 means many of Privy's features do not work out of the box, and the documentation on how to adapt them for chains like NEAR is lacking. Every developer who wanted Privy with NEAR had to create an adapter layer that uses near-api-js to prepare messages and transactions for signing, while also orchestrating dual control flows between Privy and whatever other wallets they were using.


What we built

@peerfolio/privy-near-connect is a Privy wallet adapter for near-connect. It follows the injected browser wallet pattern, plugging into near-connect exactly the way any other wallet adapter would. Your users get a familiar web2-style login experience; your app gets a fully functional NEAR wallet adapter. With a few lines of configuration developers now have the ability to launch and distribute their own branded wallet experience.

What's included:

  • NEP-413 message signing

  • Transaction signing with user-controlled approval flows

  • A production-ready sign page with Radix UI theming

  • A transaction approval UI that hides technical details by default, expandable by choice

  • TypeScript throughout

  • 80%+ test coverage

  • A working React example app in /examples/react

  • MIT licensed, actively maintained for at least 12 months

What is not supported:

  • Privy Home private key export

  • Importing existing wallets to be Privy-managed

Getting started is three steps: install the npm package, create a Privy account for your App ID and Client ID (free up to 500 MAUs), and add a manifest JSON with the adapter permissions and sign page URL. That's it.


How it works

Message Flow Architecture

Although Privy's API allows a developer's backend to construct and sign transactions on behalf of logged-in users, our opinion is that users should always be explicitly prompted to sign transactions when interacting with dapps so that they maintain full control and security over their wallet.

This trades some UX friction — a popup with browser-blocking edge cases — against the security risks of implicit transaction signing. Thus we've built this version of privy-near-connect with the separate pop-up as a secure boundary between a developer's dapp and the wallet signing operations.

This architecture splits signing into two browser contexts: the dApp’s near-connect executor and a developer-hosted sign-page popup. The executor opens the sign page, waits for a READY postMessage, then sends a SIGN_REQUEST payload into the popup. The popup owns the Privy integration: it mounts Privy’s embedded wallet iframe, asks Privy to sign the payload, then posts either the signed result or an error back to the executor. The executor resolves or rejects the original wallet promise, while the popup closes.

Authentication and Account Creation

When a user logs in for the first time via email, Privy creates an implicit NEAR account — a key pair that hasn't yet been published on-chain. You'll need to account for this in your onboarding flow: the account won't appear on-chain until a transaction is published to it.

At Peerfolio, this constraint actually shaped our onboarding flow productively. A user isn't fully onboarded until they've deposited funds — either from another wallet or via our Coinbase on-ramp — which naturally publishes their account on-chain. The constraint became a feature of our flow whereby onboarding is not complete until a user funds their account. For developers using privy-near-connect, any token transfer to the account will publish it, including sending a tiny amount of NEAR or yoctoNEAR.

The Signing Experience

The sign page is designed for mainstream users. Raw transaction details are collapsed by default — readable if you want them, not in your face if you don't. We heard directly from users that seeing anything that looked like technical details was intimidating. We designed around that.

The UI is customizable with Radix Themes, so you can match your brand without rebuilding the component.

Security Considerations

Privy supports both access tokens and ID tokens for authenticating requests. At Peerfolio, we deliberately chose ID tokens to keep our backend blind to Privy's access token infrastructure — our server never has the ability to manage or interact with Privy directly. This felt like the right tradeoff for a non-custodial product where minimizing backend privilege is a design goal.

Other implementations may have no reason to make the same choice. If your backend needs to interact with Privy directly, access tokens may be the more natural fit.

Two things we'd flag regardless of which approach you take: registering your verified domains in the Privy dashboard (requests from unregistered domains are rejected even with a valid token) and aligning token lifetime to your session length. Both are standard session management practices that Privy makes straightforward to configure.

Multi-chain

A single Privy user record can link to NEAR, ETH, Solana, and any other chain Privy supports. If you're building cross-chain, this is a meaningful architectural advantage worth knowing about.


Production-tested at Peerfolio

This isn't a prototype. It's the hardened output of what we built to power Peerfolio's email-based onboarding in production.

Peerfolio is the multiplayer, non-custodial alternative to Coinbase — an automation platform that helps you discover and put on autopilot the crypto strategies used by your network, designed for people who want their money working for them without navigating the complexity and noise of crypto alone.

Email login isn't a nice-to-have for us, it's core to the product experience being as frictionless as possible. Every design decision in this library came from real user feedback and real onboarding friction we hit ourselves.


What's next

NEAR's Tier 2 status within Privy means some Tier 3 features aren't available yet — notably Privy Home, which lets users manage their wallet and export keys outside your app and customizable authorization policies. We've raised this with Privy directly. It's on their roadmap without a committed date.

If adoption grows, we’ll add whatever additional features the community needs. The best signal we have for prioritization is usage. So drop a star on the repo, open issues, and tell us what you need.


FastAuth is gone. This fills the gap.

If you've followed the NEAR Protocol ecosystem long enough to remember FastAuth, you know how long this community has needed a reliable email auth solution for consumer apps. privy-near-connect is that solution — open source, production-tested, and free to get started.

GitHub: https://github.com/beneviolabs/privy-near-connect


Your Protocol. Their First Investment.

If you're building in DeFi and want to bring in more users and liquidity by making your product easily accessible to mainstream consumers, reach out to discuss integrating with Peerfolio. You would be in good company - Peerfolio already supports Near Intents - the fastest growing decentralized exchange, and MetaPool the most robust decentralized liquid staking platform supporting NEAR, SOL, and ETH.

Email Login for NEAR Protocol Apps — privy-near-connect