Go Live with SocketFi: Production Readiness Checklist

Shipping to production means real users, real wallets, and real assets on MAINNET. Before you flip that switch, work through every item on this checklist. Each section covers a specific failure mode that is easy to overlook in development but critical to get right before launch.

Serve your application over HTTPS

Passkeys require a secure context. The WebAuthn standard — which powers SocketFi authentication — will not work on plain http:// origins in production. Every page that calls authenticate() or requestTransaction() must be served over HTTPS with a valid TLS certificate.

http://localhost is the only non-HTTPS origin browsers allow for passkey operations, and only during local development. Any staging or production environment must use HTTPS.

Move all configuration to environment variables

Your Client ID and network target must come from environment variables — never from hardcoded strings in source code. Verify your production build reads from the correct variables.

# Vite
VITE_SOCKETFI_CLIENT_ID=sf_live_xxxxxxxxxxxxxxxxx

# Next.js
NEXT_PUBLIC_SOCKETFI_CLIENT_ID=sf_live_xxxxxxxxxxxxxxxxx

Also confirm your production SocketFi instance targets MAINNET:

export const socketfi = new SocketFi({
  clientId: import.meta.env.VITE_SOCKETFI_CLIENT_ID,
  network: "MAINNET", // not "TESTNET"
});

Log into the SocketFi Developer Portal and confirm that every domain your production application runs on is listed under Allowed Origins. Include your apex domain, www subdomain, and any CDN or preview URLs if applicable.

https://yourapp.com
https://www.yourapp.com

Any request from an origin not on this list will fail with an “Origin not allowed” error at runtime — even if your Client ID is correct.

Verify every access token on your backend

Client-side authentication state can be spoofed. Before granting access to protected data, wallet operations, or sensitive API routes, always verify the socketfiAccessToken server-side using the @socketfi/server SDK.

import { verifyAuth } from "@socketfi/server";

app.use("/api/protected", async (req, res, next) => {
  const token = req.headers.authorization?.replace("Bearer ", "");

  if (!token) return res.status(401).json({ error: "Missing token" });

  const auth = await verifyAuth(token);

  if (!auth.valid) return res.status(401).json({ error: "Unauthorized" });

  req.user = auth.user;
  req.wallet = auth.wallet;
  next();
});

Never trust a wallet address or user ID supplied by the client without verifying it against verifyAuth(). Use auth.wallet from the verified server response as the canonical wallet identity.

Handle authentication and transaction errors gracefully

Both authenticate() and requestTransaction() can throw — users can cancel, sessions can expire, and network errors happen. Every call must be wrapped in a try/catch, and your UI must communicate failures clearly without exposing raw error messages.

try {
  const session = await socketfi.authenticate();
  setSession(session);
} catch (error) {
  // Show a user-friendly message, not a raw stack trace
  setErrorMessage("Sign-in was cancelled or failed. Please try again.");
  console.error(error);
}

try {
  const result = await socketfi.requestTransaction({ contractId, method, args });
  onSuccess(result.transactionHash);
} catch (error) {
  onError("Transaction was declined or could not be completed.");
  console.error(error);
}

Handle expired sessions and re-authentication

socketfiAccessToken values expire. If your application stores tokens across page loads (for example in localStorage), you must handle the case where a stored token is no longer valid and prompt the user to authenticate again.

const auth = await verifyAuth(storedToken).catch(() => null);

if (!auth?.valid) {
  // Token is expired or invalid — clear it and prompt re-login
  localStorage.removeItem("socketfi_access_token");
  redirectToLogin();
}

Run your full integration on TESTNET staging before MAINNET

Before pointing your production environment at MAINNET, run your entire integration end-to-end on a staging environment that mirrors production as closely as possible but still uses network: "TESTNET". Confirm the following flows work correctly:

New user registration (passkey creation)
Returning user sign-in (passkey assertion)
Transaction approval and rejection
Backend token verification
Error handling for cancelled and failed flows
Session expiry and re-authentication

Only after all of these pass on TESTNET should you switch to MAINNET in your production environment variables.

Enable monitoring and logging for auth and transaction events

Production issues are much easier to diagnose when you have structured logs around authentication and transaction outcomes. At a minimum, log:

Successful and failed authentication attempts (user ID, timestamp)
Transaction requests and their outcomes (contract ID, method, result or error)
Backend token verification failures (with sanitised request context)

Avoid logging the raw socketfiAccessToken or any user-identifying data you’re not required to retain.

Review the SocketFi security model

Confirm that your integration aligns with SocketFi’s security principles before launch:

Non-custodial — SocketFi never holds user funds. Confirm you have no code paths that could inadvertently expose user wallet control to your own servers.
No client-side secrets — No private keys, signing credentials, or server-only tokens appear in your frontend bundle.
Origin enforcement — Your allowed origins list is locked down to only the domains you actually operate. Remove any wildcard or development origins before going live.
Policy controls — If you have configured smart wallet spending policies, verify they behave correctly under edge cases (zero amounts, maximum amounts, repeat transactions).

Once you’ve confirmed all items above, update your SocketFi client to network: "MAINNET", deploy your production environment variables, and submit a final end-to-end smoke test before opening to users.

Quick reference

Area	What to verify
HTTPS	All pages served over TLS in production
Environment variables	Client ID and `MAINNET` target set correctly
Allowed origins	All production domains registered in Developer Portal
Backend verification	Every protected route calls `verifyAuth()`
Error handling	`authenticate()` and `requestTransaction()` wrapped in try/catch
Session expiry	Expired tokens trigger re-authentication, not silent failures
Staging tests	Full auth and transaction flows verified on TESTNET before MAINNET
Monitoring	Auth and transaction events logged with structured context
Security review	No client-side secrets, non-custodial guarantees preserved

Get Started

Authentication

Embedded Wallets

Transactions

Smart Wallet

Security

Go Live with SocketFi: Production Readiness Checklist

Quick reference

​Quick reference

Quick reference