Control who can mint, burn and pause your token.

Minting, burning, pausing and admin changes go through roles, a waiting period and a separate approver — for the life of the asset, not just on launch day.

Map an issuance workflow Bloxchain Protocol

Where control breaks today

Launch gets a process. The years after often don’t.

Issuing an asset is treated as an event. Administering it is ongoing — and that’s where privileged keys linger.

One admin key for everything

Minting, pausing and upgrades often sit behind the same key, so one compromise reaches all of them.

Privileged keys that outlive the launch

The key that minted at launch can usually still mint a year later — with nothing standing between one person and new supply.

Policy that lives only in documents

A policy in a memo doesn’t stop a transaction. Rules need to apply at the moment of action.

Evidence rebuilt after the fact

Who minted, paused or moved admin rights is pieced together from logs and threads.

In practice

Approve every mint before it happens.

New tokens are requested, wait, and are approved separately — only then does supply change.

What you set up

The account as your token’s minter
Mint and burn added as actions
Your token on the allowed list
Requester and approver roles

Govern minting and burning, step by step (opens in a new tab)

Issuer admin
requests a mint

Approver
signs off

Supply
changes

Unlisted
contract

Refused

Illustrative

The approach

Make the account your asset’s administrator.

Every privileged call then goes through its rules. Or build the same controls into your own contracts with the open-source Protocol.

Rules on every privileged action

Minting, burning, pausing and admin changes can each have their own roles, wait and approver.

Only the calls you allow

The account calls only the contracts and functions on its list — mint on your token, and nothing you haven’t added.

Evidence stays with the change

Who minted, paused or moved admin rights is recorded as part of the operation, not reconstructed later.

In the Platform or your own stack

Run it in the Platform, or integrate the open-source contracts. The same policy model applies either way.

Before you issue

What the account enforces — and what it doesn’t claim.

Governed execution for programmable assets. You keep the keys and the account. We don’t hold assets — and this isn’t a securities certification.

Enforced by the account

Which roles may request and approve each privileged action
The waiting period on privileged actions approved on-chain
The contracts and functions the account may call
An on-chain record of every privileged change

Your responsibility

Legal structure, licensing and regulatory status
Choosing roles, the waiting period and approvers
Key management for every privileged role
Your token contract itself, and its own security review

Start with one privileged action.

Bring one privileged action — a mint, a pause, an admin change — and we’ll map it with you.

Talk to us Read the issuance guide (opens in a new tab)