Prerequisites
Have these in place before the steps. Architecture is the placement map. Roles is the party arrangement.Placement
Write down the synchronizer id and the observer party Cantor8 names. Bootstrap, the Registry, and Token App use that synchronizer id. The observer is named in the bootstrap transaction.
Instrument
One instrument needs a record you and Cantor8 both sign off before bootstrap:
One admin can issue further instruments later, on the same factory, by the same kind of signed step. Each new ticker is agreed the same way.
Parties
Allocate the parties that will act, on your participant. Which roles share a party, and how many approvers a key requires, is the decision in Roles. The validator’s participant must know those parties before bootstrap. Allocating them on your node is the first half; making them visible to the validator is the second. Cantor8 confirms that visibility when Cantor8 operates the validator. If you want network rewards, the featured-app party must already hold, or be ready to hold, a featured-app right on the network that pays rewards. That right is a network contract. It is separate from the suite DAR.Credentials
On your identity provider:
Grant the ledger user
CanActAs and CanReadAs for every party Token App will submit as: admin, issuer, and featured-app. That may be one party or several.
Cantor8 issues the Registry admin client to you. You store it as a cluster secret. You do not put it in the values file.
Suite DAR
Cantor8 sends one suite package and its release notes. Upload and vet that file, with its dependencies, on:- your participant
- the validator’s participant
- every participant that will submit a transfer or allocation of the instrument
Rewards, if you want them
Skip this to launch issuance and transfer only. For rewards, have the featured-app right, the batched-marker proxy, the beneficiary for the instrument, and the synchronizer id. Rewards explains them. They go into the Token App configuration when you deploy.The steps
Four steps. At the end you can mint through Token App, a wallet can transfer, and you have paused and unpaused once through Token App.1
Bootstrap the factory
Cantor8 prepares a validator offer. The offer names the admin, the featured-app party, the observer, and the instruments from the agreed record.You review the offer and accept it on your participant, as the parties the offer names. That acceptance creates, in one transaction:
- the factory
- the freeze configuration
- the instrument directory
- each instrument
When the roles are different parties
Each party signs its own consent before the factory exists: the featured-app party, the issuer, and the treasury. The admin then submits one transaction that consumes those consents and creates the factory, the instruments, and the treasury delegation together. Cantor8 sends one command per party. Each party submits its own.Treasury mint delegation
Include it in the acceptance when the offer carries the treasury consent. Otherwise create it as the next transaction: the treasury consents, and the issuer can mint to it from then on.The consent can also pre-approve transfers to the treasury, so a transfer back for a burn settles in one transaction.Create it at launch even when the treasury is your own party. A batch mint requires a mint delegation for every recipient. A single mint to a different party requires one too, unless that party signs the mint itself. A single mint to your own party is the one case the submitting party already satisfies, because it is both the issuer and the recipient.2
Cantor8 lists the instrument
Wallets see an instrument when the Registry lists it.Cantor8 adds the factory, the instruments, the parties, and the observer to the Registry, and sends you the public base URL. That URL answers the metadata and transfer routes in Operations.Confirm from outside your network:
- the instrument appears on the metadata API
- the observer can see a holding once one exists
3
Deploy Token App
Deploy Token App in your network against your participant, using the Helm chart or the same image run manually. Deployment is the procedure.PostgreSQL, the Docker Hub access token, and the ledger client are in the prerequisites. This step also needs the Registry URL and client from the previous step, and the configuration for your instrument. If you are posting markers, include the reward contracts from the prerequisites. Run one replica.
GET /healthz returns success before you mint.4
Prove the path
Do these in order. Each one fails for a different missing piece, so keep them separate.
Pause and unpause are admin operations. Token App fetches the context from the Registry admin API and submits it with the ledger user from the prerequisites. The actions are in Compliance.The instrument is live. A party you control authorized the mint, a wallet can move it, and you have stopped and resumed it through Token App.