FastAuth onboards users in seconds with any Auth0 method — email, social, passkey, or enterprise SSO — no seed phrases, no extensions, no wallet popups. One Auth0-backed identity, shared across every wallet and dApp in the NEAR ecosystem that integrates FastAuth.
01 What is FastAuth
FastAuth is an account-abstraction layer for NEAR, powered by Auth0. Users sign in with the credentials they already have, and the same identity resolves to the same NEAR account in every dApp that integrates FastAuth.
Four sign-in methods, all routed through Auth0: Google, Apple, email/password, and passkeys. We provision a real NEAR account in the background — no seed phrase, no extension, no wallet popup. Whatever the user already trusts, that's how they sign in.
The user's MPC-controlled NEAR account is derived deterministically from their Auth0 identity. Sign into one FastAuth-integrated dApp, sign into the next with the same login — same account, same balance, no re-onboarding.
Your dApp pays gas through the FastAuth relayer. Users authenticate with whichever Auth0 method they chose, and the action lands on NEAR mainnet wrapped as a NEP-366 meta-transaction.
02 How it works
What the user sees, and what's happening on chain. From login to confirmed transaction — without the user ever holding a key.
The user logs in with email/password, a passkey, Google, or Apple. Auth0 returns a JWT whose sub claim uniquely identifies them. Every transaction reuses this login — a fresh JWT is issued for each one, with the action embedded in the payload.
The FastAuth contract routes the JWT to the matching guard (Auth0, Firebase, custom issuer) for cryptographic verification. On success it builds a deterministic path — {guard_id}#{sub} — and asks NEAR's MPC network to sign for it. The nodes derive the same key for the same identity every time, and produce the signature collaboratively. No single party ever holds the full key — and the user holds no key material at all.
The MPC signature wraps the user's action as a NEP-366 DelegateAction. Your dApp's relayer pays gas, the action is bound to the JWT's payload (so it can't be re-used), and the call lands on NEAR mainnet through the relayer.
03 For developers
React SDK or vanilla JS — pick your stack. The Auth0-backed JavaScript provider handles login; the FastAuth relayer pays gas. You write the dApp.
FastAuthProvider.Wrap your app once. useFastAuth exposes the client for login / logout; useSigner exposes the signer for transactions and gas-free delegate actions.import { FastAuthProvider } from "@fast-auth-near/react-sdk";
import { JavascriptProvider } from "@fast-auth-near/javascript-provider";
import { Connection } from "near-api-js";
// Start on testnet (no approval needed). Switch to "mainnet" once your
// app has been whitelisted and approved Auth0 credentials issued.
const connection = new Connection({
networkId: "testnet",
provider: { type: "JsonRpcProvider", args: { url: "https://rpc.testnet.near.org" } },
});
export default function App() {
const providerConfig = {
// Auth0 tenant — Google · Apple · Email/password · Passkey live here.
provider: new JavascriptProvider({
domain: "your-tenant.auth0.com",
clientId: "YOUR_AUTH0_CLIENT_ID",
audience: "https://your-api.example.com",
}),
};
return (
<FastAuthProvider
providerConfig={providerConfig}
connection={connection}
network="testnet"
>
<Wallet />
</FastAuthProvider>
);
}04 Live network
10,184,045
↑ 15,601 today328,907
109,292 active in 7d429,279
across 1 relayer100.0%
18,675 sigs · 24h05 FAQ
If you don't see what you're looking for, the docs go deeper. Or open an issue — we read all of them.
NEAR Protocol mainnet. FastAuth is built and operated by Peersyst as a public-good account-abstraction layer for the NEAR ecosystem. Accounts are real NEAR named accounts you can inspect on nearblocks.io.
Through Auth0 — Google, Apple, email/password, or passkey. The user's MPC-controlled NEAR account is derived deterministically from their Auth0 identity, so the same login always resolves to the same account no matter which FastAuth dApp they sign into.
Auth0 is the identity layer. Each FastAuth-integrated dApp gets its own approved Auth0 credentials (domain, clientId, audience), but the user's `sub` claim deterministically derives the same MPC-controlled NEAR account across every dApp that uses the Auth0 guard — so the same login reaches the same wallet.
User signs in. Auth0 issues a JWT. The MPC network derives the user's key from their JWT. The FastAuth contract routes the JWT to the matching guard (Auth0, Firebase, custom issuer) for cryptographic verification. On success it builds a deterministic path — {guard_id}#{sub} — and asks NEAR's MPC network to sign for it. The nodes derive the same key for the same identity every time, and produce the signature collaboratively. No single party ever holds the full key — and the user holds no key material at all.
No single party holds the user's signing key. The key is derived inside NEAR's MPC network from the user's Auth0-verified identity each time a signature is needed — no node ever reconstructs the full key. The gating credential is the user's Auth0 login: every transaction requires a fresh, verified JWT, and FastAuth cannot sign without it.
Through the FastAuth relayer. When your dApp calls signAndSendDelegateAction, the relayer wraps the user's signed delegate action as a NEP-366 meta-transaction, pays gas on chain, and returns the result — the user pays nothing. The relayer URL is configured per-network in the SDK. For a regular (non-delegate) transaction, the user's account pays gas directly.
Build on testnet first — no approval required, free credentials. When you're ready for production, submit your application (name, description, expected volume, use case, contact) to the FastAuth team. Once approved, you receive production Auth0 credentials (domain, clientId, audience) and access to the mainnet FastAuth contracts. Mainnet usage is whitelisted to keep the shared infrastructure healthy.
Partially. The FastAuth contract, the JWT Guard Router, and NEAR's MPC network are shared infrastructure deployed on mainnet (fast-auth.near, jwt.fast-auth.near, v1.signer) — you integrate with them, you don't redeploy them. You can self-host the auth side: deploy your own guard contract that implements the JwtGuard trait, or run an off-chain issuer whose JWTs are verified by CustomIssuerGuard. Both extension points are documented.
Yes. The FastAuth smart contracts and signing infrastructure have been audited by Halborn, an independent security firm specializing in Web3. The full security report is publicly available.
Four, all routed through Auth0: Google, Apple, email/password, and passkeys. Because the user's NEAR account is derived deterministically from their Auth0 `sub` claim, the same login resolves to the same account in every FastAuth dApp. For providers Auth0 doesn't cover, you can deploy a custom guard contract or run a custom issuer service that issues JWTs verified on chain.