> **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.

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:

1. **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).
2. **Permissions**: review the default permission rules that will be applied after deployment, then approve them.
3. **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.
4. **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:

1. **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.
2. **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.
3. **Register contract**: calls `POST /contracts` to record the deployed contract (address and ABI) in Prividium.
4. **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.