Skip to main content
Token Factory is three running pieces and one package on the ledger. A choice context is a preparation. The Registry returns it and stops there. The admin context is how mint, burn, pause, freeze, compliance burn, and seizure are prepared. Token App is the component that submits them.

​
Default deployment

Three places. Your network runs Token App and the participant that hosts the parties you control. Cantor8 runs the Registry and the participant that reads as the observer. Wallets sit with the holders, apart from both: they take a public context from the Registry and submit the transfer on the holder’s own participant. All three participants join the same synchronizer.
Three zones: Your network contains Your services, Token App, PostgreSQL, and Your participant. Your services call Token App; Token App connects to PostgreSQL and submits to Your participant. Token App requests admin context from the Registry in Cantor8. The Registry reads from the Cantor8 Participant. Holders contain Wallets and Holder participant: Wallets request public context from the Registry and submit to Holder participant. All three participants join the same synchronizer.
Three zones: Your network contains Your services, Token App, PostgreSQL, and Your participant. Your services call Token App; Token App connects to PostgreSQL and submits to Your participant. Token App requests admin context from the Registry in Cantor8. The Registry reads from the Cantor8 Participant. Holders contain Wallets and Holder participant: Wallets request public context from the Registry and submit to Holder participant. All three participants join the same synchronizer.
What crosses the internet:
Token App is a ClusterIP service. Publishing it on the internet is outside this design. The public surface is the Registry’s instrument and transfer API.
The organization prefix is part of the Registry URL, /api/{prefix}/.... Cantor8 assigns it. Wallets and Token App both use it.

​
How a mint moves

Six messages in order: Your service to Token App: Mint, with your OIDC token. Token App to Registry: Ask for the choice context. Registry to Token App: Context, read from the observer. Token App to Your participant: Submit as your admin. Your participant to Token App: Committed. Token App to Your service: Command id and status.
Six messages in order: Your service to Token App: Mint, with your OIDC token. Token App to Registry: Ask for the choice context. Registry to Token App: Context, read from the observer. Token App to Your participant: Submit as your admin. Your participant to Token App: Committed. Token App to Your service: Command id and status.
The Registry sees the new holding because the observer was written onto it at creation. Its ledger user reads as that observer. The mint was submitted by Token App. Pause, freeze, compliance burn, and seizure use the same two steps. Token App fetches the admin context with its M2M credential, then submits on your participant as your admin. The Registry’s ledger user reads as the observer.

​
Where the validator sits

Token App stays in your network. Cantor8 runs the Registry.

​
Validator

A Cantor8-operated validator is a participant Cantor8 runs and you connect to. The parties that mint, burn, pause, and freeze stay yours, and so do their keys. Hosting one of those parties on the Cantor8 participant is available. The participant operator is then Cantor8. The key is still yours.

​
Private synchronizer

A private synchronizer is a domain you operate, Cantor8 operates, or you operate together. Participants join that synchronizer instead of, or as well as, the public one. Cantor8’s observer participant joins it, so the Registry can read the instrument. The token model is the same: factory, instruments, parties you control, and Token App. Activity-marker rewards are a program of the public Canton network. On a private synchronizer the instrument still issues, transfers, and settles. Markers and network rewards apply when the featured-app right lives on a network that pays them. Rewards covers that choice.

​
What has to be true for the picture to work

  • Your participant and the validator’s participant both vet the same suite DAR. So does every participant that will submit a transfer of the instrument, including holders’ participants.
  • The parties you control are hosted on your participant and are known to the validator’s participant before bootstrap.
  • The synchronizer id is the same one in bootstrap, in the Registry, and in Token App.
  • The observer is named in the bootstrap transaction.
  • Token App runs as one process. The ledger poller and the marker batches assume a single writer.
  • The participant that submits has traffic available. Submissions consume it.

​
Lifecycle of a package

Cantor8 delivers one suite DAR per release, with release notes. You vet that file. A later release is a new file, vetted the same way on every participant that submits. Holdings already on the ledger stay in place across that vetting. The factory and the instruments continue. You vet before you depend on the new package. Bootstrap, the Registry configuration, and Token App all refer to the release you vetted. An upgrade is coordinated: vet, then roll the configuration Cantor8 ships for that release.