> ## Documentation Index
> Fetch the complete documentation index at: https://docs.socket.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Go Live with SocketFi: Production Readiness Checklist

> Verify your SocketFi integration is secure, stable, and correctly configured before switching to MAINNET and opening your app to real users.

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.

<Steps>
  <Step title="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.

    <Warning>
      `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.
    </Warning>
  </Step>

  <Step title="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.

    ```env theme={null}
    # 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`:

    ```ts theme={null}
    export const socketfi = new SocketFi({
      clientId: import.meta.env.VITE_SOCKETFI_CLIENT_ID,
      network: "MAINNET", // not "TESTNET"
    });
    ```
  </Step>

  <Step title="Register all production origins in the Developer Portal">
    Log into the [SocketFi Developer Portal](https://portal.socketfi.com) 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.

    ```text theme={null}
    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.
  </Step>

  <Step title="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.

    ```ts theme={null}
    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();
    });
    ```

    <Warning>
      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.
    </Warning>
  </Step>

  <Step title="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.

    ```ts theme={null}
    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);
    }
    ```

    ```ts theme={null}
    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);
    }
    ```
  </Step>

  <Step title="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.

    ```ts theme={null}
    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();
    }
    ```
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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).
  </Step>
</Steps>

<Note>
  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.
</Note>

## 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         |