Skip to content
Prividium

User Onboarding (Backend-Assisted)

On permissionless EVM chains, a user can connect a wallet and interact with any public contract. Prividium™ chains use a different model. A wallet proves control of an address, but it does not grant network access by itself.

Prividium™ requires each user to pass three checks before they can use an application:

  1. Identity: The user authenticates with OpenID Connect (OIDC) or Sign-In with Ethereum (SIWE).
  2. Wallet association: The wallet address belongs to the authenticated Prividium™ user.
  3. Authorization: The user's roles allow the requested RPC method, contract, function, or event.

This distinction matters most for browser wallet applications. Users expect to connect a wallet and start using the app, but application developers must register users and assign roles first.

Onboarding Models

Choose the onboarding model that matches who controls user admission.

Admin-Managed Onboarding

Use admin-managed onboarding when the network operator controls user admission and approves access case by case. This model fits internal tools, closed pilots, and deployments that rely on manual access review.

Administrators can complete this setup directly from the Prividium™ Admin Panel, assign roles, and associate one or more wallet addresses. For OIDC-backed deployments, users may be able to authenticate and reach the User Panel before an administrator assigns any roles. In that case, the administrator still controls access by assigning the roles that allow the user to do anything useful.

Browser applications should treat these users as pre-approved and only handle sign-in.

Backend-Assisted Browser Wallet Onboarding

Use backend-assisted onboarding when users arrive through your application and connect a browser wallet. The browser collects a wallet signature, but your backend decides whether to create the Prividium™ user.

The backend performs these steps:

  1. Ask the browser wallet to sign an application-specific registration message.
  2. Verify the signature, domain, nonce, and expiration.
  3. Decide whether the user is allowed to onboard and which Prividium™ roles the backend may assign.
  4. Authenticate to Prividium™ with admin privileges.
  5. Create or update the Prividium™ user and attach the wallet address.
  6. Assign only the necessary roles.

The browser must never receive admin credentials. Treat role assignment as a server-side decision. A client request may identify the requested product or access tier, but it must not choose Prividium™ roles directly.

This document describes the admin-backed flow. Other registration models can use different server-side principals, such as M2M apps.

Relevant Prividium™ APIs:

  • POST /api/users
  • PUT /api/users/{id}

Use these APIs only from a trusted server environment. Keep admin sessions short-lived and store credentials with the same controls you use for other privileged infrastructure secrets.

What Onboarding Creates

Onboarding creates identity and account linkage in Prividium™. It does not make a contract callable by itself.

After onboarding, the user should have:

  • A Prividium™ user.
  • At least one wallet address associated with that user.
  • A role assigned to the user. A role is a named set of permissions assigned to a user.

These steps establish identity. They do not grant full application access on their own.

What Admins Still Need To Configure

Before a user can interact with a contract, administrators or trusted automation must still configure:

  • Contract metadata for the target contract.
  • Function permissions for the user's role.
  • Event permissions for logs or event-based indexing.
  • Required system permissions for RPC methods outside contract-specific access. A system permission is a network-level permission for RPC or other privileged capabilities.

Prividium™ denies access by default. If any layer is missing, reads or writes can fail even when wallet authentication succeeds.

Browser Wallet Sign-In

After onboarding, browser wallet users sign in with SIWE. The user signs a Prividium™ SIWE message with an associated wallet. Prividium™ exchanges the signed message for a user session.

Relevant APIs:

  • POST /api/siwe-messages
  • POST /api/auth/login/crypto-native
  • GET /api/profiles/me
  • GET /api/auth/current-session

After login, load GET /api/profiles/me and verify that the connected wallet belongs to the authenticated user. Do not continue if the browser wallet and Prividium™ profile disagree.

After Onboarding

After sign-in, the application can read chain state and submit transactions through the standard Prividium™ web app flow. This onboarding guide only covers the access prerequisites.

For implementation details, see:

For Per-User RPC token lifecycle and transaction authorizations, see Per-User RPC and Transaction Authorizations.

A browser wallet app guides the user through these stages:

  1. Connect wallet: Ask the user to connect their browser wallet.
  2. Register if needed: Send a signed registration message to your backend.
  3. Sign in: Request a Prividium™ SIWE message and exchange the signed message for a session.
  4. Verify profile: Load GET /api/profiles/me and confirm the wallet association.
  5. Configure Per-User RPC: Add the per-user Prividium™ RPC URL to the browser wallet.
  6. Read chain state: Use the authenticated read pattern from Building Web Applications.
  7. Submit transactions: Use the transaction authorization pattern from Building Web Applications.

Security Notes

  • Never expose admin credentials to the browser.
  • Do not trust roles or organization IDs supplied by the client.
  • Bind registration signatures to your application domain and a short-lived nonce.
  • Treat wallet association as part of authorization, not only identity.
  • Treat duplicate wallet registration as an expected state and continue with sign-in when policy allows it.
  • Do not use the Per-User RPC URL for application reads.
  • Do not assume public Ethereum RPC behavior applies to Prividium™.
  • Avoid broad permissions such as full_sequencer_rpc_access unless the user needs them.