XKOVA Docs
Docs / XKOVA TAMS / Deploy and Mint

Deploy and Mint

Deploying a token is a short saga, not a single call. You name the token and supply its admin Safe, the platform relayer deploys the contracts and pays gas, XKOVA confirms the result on-chain, and supply changes (mint and burn) run through the Safe's signer quorum afterward.

Deploy

You deploy a token by its standard: an ERC20X fungible token, an ERC721X collection, or an ERC1155X multi-token contract. Deploying requires the tokenize_admin role (tenant admins inherit it) and a step-up authenticated session, and is gas-paid by the platform relayer. The request returns immediately with a token in pending_deploy.

You provide the token's admin authority as a multisig Safe you already control. That Safe becomes the contract's administrator: it holds the minter, pauser, and admin roles. The deploy does not provision a Safe for you; supply the address of one you own.

What happens after you call deploy

  1. A token factory deploys the token proxy, a roles contract bound to the admin Safe, and, when access control is configured, an access registry (allow list or deny list). All are relayed and gas-paid.
  2. XKOVA observes the new contract on-chain and records a deployment for it, with no extra call from you. A fungible ERC20X is additionally auto-registered onto the payment and treasury rails; an ERC721X or ERC1155X collection is recorded as a deployment only and is not added to those rails.
  3. A confirmation poller flips the token to active once both deploy transactions confirm on-chain success. A reverted-but-mined transaction is never treated as success.
  4. You poll the token until it resolves to active and carries its on-chain proxy address.
flowchart TD
  A[Call deploy] --> B[Token factory deploys proxy]
  B --> C[XKOVA observes the contract on chain]
  C --> D[Records a deployment, ERC20X auto registers onto the rails]
  D --> E[Poller confirms on chain success]
  E --> F[Token active]
  F --> G[Mint to holders, supply updated]
Deploys are idempotent. Send an Idempotency-Key so a retried deploy returns the original operation rather than starting a second one. See Idempotency.

Provisioning the admin Safe

The admin Safe is a required input to deploy, not something the deploy call creates. You pass the address of a multisig Safe you already control, and it must be a Safe already deployed on the token's chain. The service checks that the address is a valid checksummed address with on-chain code and rejects a plain wallet address or an undeployed counterfactual Safe. The Safe you supply becomes the contract's administrator, holding its admin, minter, and pauser roles, and it is the quorum that signs every later mint, burn, and recovery.

If you do not yet have a Safe, provision one through treasury. Creating a treasury vault deploys a Gnosis Safe multisig on-chain with the staff signers and threshold you choose; once it is active you can use its address as the admin Safe for a deploy. Using a treasury vault also means the same signer quorum and the same draft, collect, relay, settle path govern both your treasury transfers and your token's supply changes. See Treasury for creating a vault, managing signers, and how a quorum-signed transaction settles.

The admin Safe is chosen at deploy time and becomes the authority for the token's supply. Pick a Safe whose signers and threshold match how you intend to govern mint, burn, and recovery, all of which run through that Safe's quorum. See Token Authorities for the roles a token grants and who holds them.

Mint

Minting creates new supply and credits it to a recipient. A mint is built against the token's admin Safe, then the Safe's N of M owners sign the returned typed data and submit signatures until the threshold is met. At that point the platform relayer submits the mint and pays gas, and a poller flips the operation to confirmed once it confirms on-chain success.

  • The amount is a smallest-unit integer (the raw on-chain value, not a decimal).
  • The token must be active before it can be minted.
  • One mint per token is in flight at a time. Wait for it to confirm or fail before starting another.

Burn and supply

Burning reduces supply. A burn runs the same Safe-signed path as a mint and reduces both the executing Safe's balance and the total supply. The token's total supply is therefore always the net of confirmed mints and burns, reconstructed from on-chain state rather than tracked off chain.

There is also a compliance recovery action that moves a blocked account's balance to the admin Safe. It requires a dedicated recovery role on the Safe and is covered alongside the access controls on Access and Policy.

Mint, burn, and recover all go through the Safe quorum and the relayer. They are the same non-custodial pattern as the rails: the owner signs, the relayer submits, the chain settles. See the Non-custodial Model.

For exact shapes

The deploy request bodies, the mint and burn payloads, and the signing flow are in the interactive reference and the operations list under the tokenization tag.