> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://docs.prividium.com/api/mcp` to find what you need.
>
> **Have feedback?** Use `submit_feedback` on the same MCP server.

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](/configuring/users/authentication).

### 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 registered as admin users when
  they first request a wallet sign-in challenge. A listed wallet that already belongs to a user gets no extra role.

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

At sign-in:

* Users with OIDC subjects listed in `OIDC_ADMIN_SUBS` are assigned the `admin` role each time they sign in through the
  zone's OIDC provider.
* Wallets listed in `CRYPTO_NATIVE_ADMIN_WALLETS` that are not yet linked to a user are registered as admin users when
  they request a wallet sign-in challenge. This only works while `AUTH_METHODS` includes `crypto_native`.

## 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](/configuring/users/managing-users).

## 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](/configuring/users/roles).

### 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](/configuring/users/system-permissions).

### 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](/configuring/chain/organizations).

## Where can I read more about how users, roles, permissions, and organizations work together?

Use the [Access Model](/getting-started/introduction/access-model) doc to understand how users, roles, organizations, wallets, zones, and more all fit together.

## 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 contract permissions in
the [contract permissions section](/configuring/contracts/permissions).

### 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](https://docs.openzeppelin.com/contracts/5.x/erc20) and contracts
deployed from a
[contract factory](https://www.quicknode.com/guides/ethereum-development/smart-contracts/how-to-create-a-smart-contract-factory-in-solidity-using-hardhat).

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](/configuring/contracts/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](/configuring/contracts/system-contracts).

### 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](/configuring/chain/bridging).
Use the [ERC-20 bridging guide](/developers/how-to/bridge-erc-20-tokens) for step-by-step instructions for building a frontend with ERC-20 bridging functionality.

### 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](/configuring/contracts/selective-disclosure).

## 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](/configuring/applications/web-applications).

### 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](/configuring/applications/m2m-applications).

### 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](/developers/webhooks/overview).

## 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](https://etherscan.io/). 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.