Skip to content
Prividium

Introduction for Admins

This guide will provide an overview of initializing system administrators and the fundamental features of using the admin panel.

How are admins initialized?

The ZKsync Prividium™ system implements a role-based access control mechanism where administrators are designated through a configurable admin role.

  • Admin initialization can be done through env variables pre-deployment.
  • Once initialized, the admin role can be assigned to users through the admin panel.

Admins must be signed in to their admin account in order to access the admin panel.

How is authentication configured?

The system supports two authentication methods. Admins can be configured using:

  1. OIDC: Admins can be configured using OIDC subject IDs.
  2. Crypto Native: Uses wallet-based authentication for admin roles.

Before configuring OIDC authentication, the only option for signing in to Prividium is by using an Ethereum wallet such as Metamask.

By configuring OIDC authentication, users and admins can sign in to Prividium with an OIDC provider such as Okta or Keycloak. This enables you to build a wallet-less experience for users and integrate into your existing organization authentication system.

You can find step-by-step instructions for configuring OIDC authentication in the authentication section.

Env variable admin setup

Admin configuration is managed through environment variables in the permissions-api service:

  • OIDC_ADMIN_SUBS: Comma-separated list of OIDC subject IDs that are automatically granted admin privileges when using OIDC authentication.
  • CRYPTO_NATIVE_ADMIN_WALLETS: Comma-separated list of wallet addresses that are automatically granted admin privileges when using Crypto Native authentication.

Runtime initialization

During application startup:

  1. Database migrations run automatically in production
  2. The built-in zone admin role is created (or its permissions synced) with the fixed id admin
  3. Users with OIDC subjects listed in OIDC_ADMIN_SUBS or wallets listed in CRYPTO_NATIVE_ADMIN_WALLETS are assigned the admin role when they first call GET /api/profiles/from-jwt

How can I view and manage users?

You can see all registered Prividium users, their roles, associated wallets, and profile information in the admin panel's "Users" tab. You can also add or delete users, edit their roles and wallet addresses, and more.

You can find step-by-step instructions for managing users in the manage users section.

What are roles?

Roles allow you to group special permissions for users together to easily grant or remove user-based permissions. For example, the admin role allows certain users to access the admin panel and make changes to other user profiles. You can also create custom roles for special purposes, such as a token_minter role that allows any wallet with that role to mint a specific token, or an auditor role that can read the state of certain contracts.

By default users added to Prividium do not have any roles.

You can find more details about managing roles in the manage roles section.

System permissions

Roles can be configured with access to different system permissions, such as the ability to deploy contracts, manage users inside a certain organization, and more. You can find more details about system permissions in the system permissions section.

Organizations

Organizations group users together and apply a shared set of default roles automatically. By default only admins can add or delete organizations. You can learn more about managing organizations in the manage organizations section.

How do I view and manage contract permissions?

The contracts tab in the admin panel allows you to view and manage contract permissions.

By default, a contract deployed on Prividium has no permissions configured, which means no one can make any read or write calls to the contract unless they have full_sequencer_rpc_access. In order to read or write to a contract, that contract must be configured by an admin.

Contract permissions are customizable and granular. For example, you can configure users to only be able to read the balance of a token for their own address unless they are an admin. You can find more details about system permissions in the contract permissions section.

Contract templates

Contract templates enable you to create a reusable permissions configuration for a contract ABI. This is very helpful for contract types you know will be used many times and you expect them to all have the same permissions configurations. Common examples for this include ERC20 tokens and contracts deployed from a contract factory.

Beyond reusing a permissions configurations, using a contract template also groups like-contracts together in the contracts tab for better organization.

Admins can create a new contract template by going to the "Contracts" tab in the admin panel, clicking on "Contract Templates" in the upper right corner, and then selecting "Create Template".

Deployable templates

Deployable templates are pre-configured contract definitions that administrators can deploy directly from the Admin Panel. Each deployable template bundles a contract type (for example, a standard ERC-20 token) with a default permissions configuration so the deployed contract is ready to use immediately.

The Deployable Templates section is only visible when VITE_TOKEN_DEPLOYMENT_ENABLED is set to true for the Admin Panel (see Contract Deployment). To deploy a contract, open the Deployable Templates section, select a template, fill in the required parameters, and sign the deployment transaction with a connected wallet.

System contracts

System contracts are contracts that are pre-deployed on all Prividium networks as they are part of the ZKsync protocol. They cannot be created, edited, or deleted. System contracts can be identified in the "Contracts" tab by a blue badge with a check mark.

Permissions (function and event access rules) work exactly like regular contracts. Administrators can assign, modify, and remove permission rules on system contracts without restriction. You can learn more about the default system contracts in the system contracts section.

Bridging

Users bridge ETH and ERC-20 assets between Ethereum L1 and your network through the user panel. Bridging relies on the L2 bridge system contracts, so it needs explicit permission rules — deposits and withdrawals fail without them, even when the user panel enables the feature. You can learn what to configure in the bridging section.

Selective disclosure

Selective disclosure is a privacy feature that allows specific pieces of information about certain contracts to be publicly accessible while maintaining the confidentiality of all other contract data.

For example, you could configure a token contract to allow anyone, including someone who is not registered as a Prividium user, to see the total supply of the token. You can learn more about selective disclosure in the selective disclosure section.

How do I view and manage applications and services?

User apps

Frontend applications that authenticate users with Prividium must be authorized by an admin. These applications can be configured in the "User apps" tab of the admin panel. You can learn more about managing user applications in the manage applications section.

M2M apps

Backend applications that authenticate programmatically with Prividium must be authorized by an admin. These applications can be configured in the "M2M apps" tab of the admin panel. You can learn more about managing user applications in the manage M2M applications section.

Webhooks

Webhooks enable you to create services with real-time notifications about onchain activity. By default, only admins have permissions to enable a webhook. You can find detailed steps for using webhooks in the webhooks section.

How does the block explorer work?

The block explorer works a lot like other Ethereum block explorers you may be familiar with, such as Etherscan. The main difference is that the Prividium block explorer also integrates role-based permissions for reading transaction details.

By default, admins can see all transactions and accounts in the block explorer, while users can only see transactions that directly involve their wallet.

In order to access the block explorer, an account must have at least one Ethereum wallet associated with it.