Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getpara.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Wallet Pregeneration allows you to create wallets before a user authenticates with Para. Your application controls the wallet’s user share until the wallet is claimed. After a successful claim, Para rotates the key material and protects the user share with the user’s authentication method. Pregenerated wallets can be associated with an email address, a phone number, a third-party account identifier, or a custom ID of your choosing. If you create a wallet with a custom ID and later want a user to claim it with email or phone auth, update the pregenerated wallet identifier before returning the user share to the client.
  • For email or phone, the user will need to have the same email address or phone number linked to their account.
  • For Discord or Twitter, the user will need to have authenticated via those services on your application with the same username.
  • For a custom ID, your application is responsible for mapping that ID to the user who should be allowed to claim it.

​
Creating a Pregenerated Wallet

Before creating a wallet for a user, it’s a good practice to check if one already exists.

​
Check if a pregenerated wallet exists

const hasWallet = await para.hasPregenWallet({
  pregenId: { email: "user@example.com" },
});

​
Create a pregenerated wallet if needed

if (!hasWallet) {
  await para.createPregenWallet({
    type: "EVM",
    pregenId: { email: "user@example.com" },
  });
}

​
Method Parameters

​
PregenAuth Type Definition

The identifier can be an email or phone number, a third-party user ID (for Farcaster, Telegram, Discord, or X), or a custom ID relevant to your application. Choose an identifier that works best for your application architecture.

​
Storing and Managing User Share

After creating a pregenerated wallet, it’s crucial to securely store the user share. This share is part of Para’s 2/2 MPC protocol and remains the application’s responsibility until the wallet is claimed. To retrieve the user share for a pregenerated wallet, use the getUserShare method: 
const userShare: string = await para.getUserShare();
You must securely store this user share in your backend, associated with the user’s identifier. If this share is lost, the wallet becomes permanently inaccessible.

​
Best Practices for Storing the UserShare

While temporarily managing the UserShare, it’s important that you take extra care with how you store this information. If you ever face a situation where data becomes compromised across your systems, reach out to the Para team so we can work on possible key rotation. However, keep in mind that Para does not store backups of this share in case of data loss. To mitigate this category of risks, we’ve compiled a few best practices:
  • Encrypt UserShares in-transit and at-rest.
  • Ensure your database has backups and periodic replicas to mitigate against data deletion risks.
  • Complete a fire drill prior to going live, testing scenarios such as:
    • You are unable to access your DB
    • Your DB is deleted
    • An internal team member’s credentials are compromised
Para is happy to offer pre-launch security reviews for teams in the Growth tier or above. Let us know if you need help!
This share management is temporary - once the user claims their wallet, Para will handle the share security through the user’s authentication methods.

​
Using a Pregenerated Wallet

Before using a pregenerated wallet for signing operations, you must first load the user share into your Para client instance. Retrieve the UserShare from your secure storage and load it into Para using the setUserShare method: 
await para.setUserShare(userShare);
Once the share is loaded, the wallet becomes available for signing operations, just like any other Para wallet: 
const messageBase64 = btoa("Hello, World!");
const signature = await para.signMessage({
  walletId,
  messageBase64,
});
You can perform this operation using either @getpara/server-sdk or @getpara/react-sdk/@getpara/web-sdk depending on your application architecture. The Para client that has the user share loaded is the one that can perform signing operations.

​
Using with Ecosystem Libraries

Once the userShare is set, your Para client functions like any standard wallet. You can now easily integrate with popular blockchain libraries to perform transactions and other operations. For detailed integration guides with blockchain ecosystems, see:

​
Claiming a Pregenerated Wallet

Claiming pregenerated wallets must be done client-side with the Para Client SDK. The Server SDK does not support the key rotation operations required for wallet claiming.
Claiming transfers ownership of a pregenerated wallet to a user’s Para account. This process requires:
  1. The wallet’s user share is loaded into the Para client before the claim runs
  2. The wallet’s identifier matches the authenticating user’s identifier
  3. The claim runs from a client-side Para SDK instance

​
Claiming with the modal

Configure fetchPregenWalletsOverride before opening the Para modal. During authentication, Para calls this function with the identifier the user is authenticating with. Your backend uses that identifier to find the stored user share and returns it to the SDK.
If you created the wallet with a custom ID, update the pregenerated wallet identifier to the authenticating identifier before returning the user share. The returned share must describe the wallet with the same identifier Para is claiming.
async function fetchPregenWalletsOverride(opts: { pregenId: PregenAuth }) => Promise<{ userShare?: string }> {
  const email = "email" in opts.pregenId ? opts.pregenId.email : undefined;

  if (!email) {
    return { userShare: undefined };
  }

  const response = await fetch("/api/pregen/share", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email }),
  });
  const data = await response.json();

  return { userShare: data.userShare };
}
Pass the callback when you create the Para client used by your provider. 
import ParaWeb, { Environment, ParaProvider } from "@getpara/react-sdk";

const para = new ParaWeb(Environment.BETA, process.env.NEXT_PUBLIC_PARA_API_KEY!, {
  fetchPregenWalletsOverride,
});

<ParaProvider paraClientConfig={para}>
  {children}
</ParaProvider>
Your backend should return the stored share only after it has prepared the wallet for the authenticating identifier. 
import { Para as ParaServer } from "@getpara/server-sdk";

export async function POST(request: Request) {
  const { email } = await request.json();
  const wallet = await getPregenWalletByEmail(email);

  if (!wallet) {
    return Response.json({ userShare: undefined });
  }

  const para = new ParaServer(process.env.PARA_API_KEY!);
  const userShare = await decryptUserShare(wallet.encryptedUserShare);

  await para.setUserShare(userShare);
  await para.updatePregenWalletIdentifier({
    walletId: wallet.walletId,
    newPregenId: { email },
  });

  return Response.json({ userShare: await para.getUserShare() });
}
Use a fresh server-side Para client for request handlers that call setUserShare. Reusing one client across requests can mix wallet shares from different users.

​
Claiming manually

If you are not using the modal flow, authenticate the user first. Then retrieve the prepared user share from your backend, load it into the client, and claim the wallet. 
const response = await fetch("/api/pregen/share", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email: user.email }),
});
const { userShare } = await response.json();

await para.setUserShare(userShare);

const recoverySecret = await para.claimPregenWallets({
  pregenId: { email: user.email },
});
You can also claim every pregenerated wallet whose loaded share and identifier match the authenticated user. 
const recoverySecret = await para.claimPregenWallets();
In the modal flow, you usually do not call claimPregenWallets directly. When the callback returns a matching user share during authentication, Para loads the share and claims the wallet as part of the auth flow.

​
Controlling When Wallets are Claimed

You have control over when users claim their pregenerated wallets:
  • Delayed Claiming: Only load the userShare and update the identifier when you’re ready for the user to claim the wallet. This allows your application to continue using the wallet on behalf of the user.
  • Immediate Claiming: If you want immediate claiming upon user authentication, load the userShare before authentication and ensure the identifiers match.
  • No Claiming: Keep using different identifiers for the wallet than the user’s actual identifier to prevent automatic claiming.
This flexibility lets you design the optimal user experience for your application.

​
Core Pregeneration Methods

​
Best Practices and Considerations

Pregenerated wallets are app-specific until claimed. Before claiming, they can only be used within your application through the UserShare. After a user claims the wallet, it becomes part of their Para account, allowing them to use it across different Para-integrated applications. This transition from app-managed to user-managed is a key consideration in your implementation strategy.
Choose identifiers that align with your application architecture: - Email/Phone: Most common for user-facing applications - OAuth Identifiers: Useful for social login integrations (Discord, Twitter) - Custom IDs: Ideal for internal user management systems Consider your user onboarding flow when choosing identifiers. If you use custom IDs initially, you’ll need to update them to match the user’s actual identifier (email/phone) before claiming can occur.
The user share is critical security information that must be protected: - Encryption: Always encrypt user shares both in transit and at rest - Database Security: Implement proper access controls for your share database - Backups: Maintain regular database backups to prevent data loss - Disaster Recovery: Create processes for handling compromise scenarios - Key Rotation: Have a plan for working with Para if key rotation becomes necessary Consider implementing a fire drill before launching to test scenarios like database loss, access issues, or credential compromise. Para offers security reviews for teams on Growth tier and above.
Plan your user experience around wallet claiming: - Delayed Claiming: Keep control of wallets until users are ready for full ownership - Automatic Claiming: Configure for immediate claiming during authentication - Progressive Onboarding: Start users with app-managed wallets, then transition to self-custody - Educational Elements: Help users understand the transition from app-managed to self-custody The claiming process should feel seamless and intuitive to users while giving you flexibility in your application architecture.
Be deliberate about the wallet types you create:
  • Match Blockchain Needs: Select wallet types (EVM, Solana, Cosmos, Stellar) based on your application’s blockchain requirements
  • Multiple Types: Consider creating multiple wallet types if your application spans multiple blockchains
  • Default Selection: If your app supports multiple chains, create wallets for all required types during pregeneration
  • User Guidance: Provide clear information about which blockchain networks are supported by each wallet
Understand the operational boundaries:
  • Server-side: Create pregen wallets, store user shares, sign transactions (with loaded shares)
  • Client-side only: Create and claim wallets, load user shares, sign transactions
Design your architecture with these constraints in mind, especially when planning how user shares will flow from your server to client during the claiming process. Implement secure methods to transfer the user share from your server to the client when needed for wallet claiming.

​
Reference Example

For complete examples demonstrating the usage of pregeneration methods, refer to our examples repository:

Server-Side Pregeneration

Client-Side Claiming