Contract Deployment

The Admin Panel includes a one-click ERC20 deploy flow. In a single guided session an administrator deploys a permissioned ERC20 token, registers it with Prividium, and applies a default set of permission rules, without leaving the panel or using a CLI.

The feature is hidden by default and becomes visible when VITE_TOKEN_DEPLOYMENT_ENABLED is set to true at build time.

Configuration

Set the following environment variables when building the Admin Panel:

Variable	Purpose	Required
`VITE_TOKEN_DEPLOYMENT_ENABLED`	Set to `true` to enable the deploy flow. Hidden when false (default).	Yes (to enable)
`VITE_REOWN_PROJECT_ID`	Reown AppKit project ID. Enables the Reown wallet modal.	No

The chain identity used by the deploy flow (chain ID, display name, and native token) is read from the network's /.well-known/prividium endpoint, so no per-panel chain configuration is needed.

When VITE_REOWN_PROJECT_ID is unset, the deploy flow falls back to the browser's injected wallet (MetaMask or equivalent).

Who can deploy

The deploying administrator needs all of the following:

A wallet associated with their account (added from the User Panel).
A role that grants the contract_deployment permission. Without it the proxy rejects the deployment transaction.
Enough gas in that wallet to cover the deployment, unless the network is gas-free.

The wizard checks the wallet association and permission once the wallet is connected, and blocks the deploy button until both are satisfied.

Deploy flow

Navigate to Contract Templates in the Admin Panel. When the feature is enabled, a Deployable templates section appears with a Deploy new token entry point.

The wizard walks through four steps:

Configure: enter the token name, symbol, and initial supply. Inputs are derived from the contract's constructor and validated before you continue (for example, the symbol must be alphanumeric and the supply a positive number).
Permissions: review the default permission rules that will be applied after deployment, then approve them.
Deploy: connect the deploying wallet and sign a single transaction. The wizard adds the Prividium network to the wallet (using a per-user RPC token) before broadcasting, so the signed transaction reaches the authenticated proxy.
Token deployed: see the deployed contract address and transaction hash, with links to the block explorer and the contract detail page.

Under the hood

A single click drives four phases. Each runs in order, and the wizard reports progress per phase:

Add network: registers the Prividium network in the connected wallet using the administrator's personal RPC token, then switches to it. This is what lets the wallet broadcast through the permissioned proxy rather than a public RPC.
Deploy contract: broadcasts the ERC20 constructor transaction. This phase is irreversible once the transaction is confirmed: the token exists on-chain regardless of what follows.
Register contract: calls POST /contracts to record the deployed contract (address and ABI) in Prividium.
Apply permissions: calls POST /contract-permissions once per default rule.

If a phase after the deploy fails, the token is already on-chain, so the wizard never re-deploys. It offers a retry that resumes from the failed phase (re-running only the registration or the permission rules that did not yet succeed), plus a fallback link to the contract page where registration can be completed manually.

If the browser session is lost after the deploy confirms (for example the tab is closed), the deployment is still recorded server-side and can be listed via the GET /contract-deployments API; recover the contract address from there or from the wallet's transaction history, then register the contract manually from the Contracts page.

Default permissions

The default rules are defined in the Admin Panel frontend and mirror the canonical permissioned-ERC20 setup. They are not "open to everyone": on a permissioned chain a user should only see and move their own balances.

Methods	Default rule
`name`, `symbol`, `decimals`, `totalSupply`, `owner`	Public reads. Token metadata is visible to everyone.
`balanceOf`, `allowance`	Caller-restricted reads. A user can only query the address of the wallet making the call.
`transfer`, `approve`, `burn`	Public writes. These already act on the caller's own balance, so no restriction is needed.
`transferFrom`, `burnFrom`, `mint`	Caller-restricted writes. The source (or mint target) address must be the wallet making the call.

Owner-only methods such as mint, pause, and transferOwnership are also enforced on-chain by the contract's onlyOwner guard. Non-owner calls revert at the contract regardless of the permission rule, so the permission layer and the on-chain guard reinforce each other.

Administrators can adjust any of these rules from the contract detail page after deployment.