J1. Issuer journey: launch an asset
The Issuer is the legal entity that issues the asset and answers for its terms. This journey starts when the Issuer has decided to issue and holds no contract yet. It ends with a live asset: a suite deployed, its roles granted, eligibility and compliance configured, the first positions minted and the pause lifted. At the end, the Issuer holds the root role of its suite, its operators hold the roles it gave them, and its first investors hold their positions.
Stages
1
Obtain the right to deploy
No guide. Network governance grants the platform role ASSET_DEPLOYER
Network governance
The Issuer, or the tokenization provider that deploys for it, can deploy suites
2
Deploy the suite
Deployer
Token, eligibility registry, identity storage, compliance and access manager exist, commissioned. The token is paused, with no supply
3
Grant roles
Issuer
The Issuer's operators hold the roles of the Issuer's domain that they need
4
Set what an investor must prove
Issuer
The asset has its required claim topics, by default and per identity type
5
Decide whose attestations count
Issuer
The Claim Issuers the asset trusts are listed, each for its topics
6
Set the rules of the asset
Compliance Owner
The modules that enforce the terms of the asset are bound and configured
7
Decide which spenders the asset accepts
Compliance Owner
The asset has a spender policy. Optional
8
Mint the first positions
Token Agent
The first investors hold their positions
Overview
What the persona sees and does
1. Obtain the right to deploy. Deployment through the TREXFactory is gated. The Issuer asks Network governance for the platform role ASSET_DEPLOYER, or works with a tokenization provider that holds it. The role lets its holder deploy an asset. It gives no authority over the factory, and none over a suite once it is deployed.
2. Deploy the suite. The Issuer decides the parameters of the asset: name, symbol, decimals, a salt that fixes its addresses, and the account that receives the root role of the suite. The Deployer submits one transaction, TREXFactory.deployTREXSuite, and the whole suite exists. The token is paused and has no supply. Neither the factory nor the Deployer keeps any authority.
3. Grant roles. The factory deployed the access manager and commissioned the suite in stage 2: every privileged function already answers to a role of the Issuer's domain. With the root role, the Issuer gives its operators the roles they need: minting, burning, freezing, forced transfers, recovery, pausing, registration, and the configuration roles. Until this is done, no operator can act. The Issuer protects the root role above every other key: it can remap any function and grant any role.
4. Set what an investor must prove. The Issuer translates the terms of the offering into claim topics: identity verified, accredited, resident of a permitted jurisdiction. It records them in the asset's TREXRegistry, as a default set and, where the terms differ for institutions, as a set for that type of identity. Before any holder exists, the order of stages 4 and 5 does not matter. On a live asset, a Claim Issuer is trusted for a topic before the topic is required.
5. Decide whose attestations count. The Issuer names the Claim Issuers it relies on, each for the topics it trusts them for. It has an agreement with each of them outside the protocol. From then on, an investor that holds a valid claim from one of them for a required topic satisfies that topic.
6. Set the rules of the asset. The Compliance Owner, usually the Issuer itself, binds the modules that enforce the terms that are not about who the investor is: for example a cap on what one investor may own. Each module is configured for this asset.
7. Decide which spenders the asset accepts. If the asset is meant to trade on venues or to be handled by custodians, the Compliance Owner sets a spender policy: spenders must be eligible like holders, or must be on a list of named operators. Without a policy, any spender a holder approves can execute for it.
8. Mint the first positions. Investors have by then been onboarded: each has an ONCHAINID and the claims the asset requires, as in J2. Once a subscription is settled under the Issuer's own process, a Token Agent mints the corresponding position. A mint passes the same two gates as a transfer, so it fails for an investor that is not eligible. A mint works while the token is paused.
9. Open the asset. When the Issuer decides the asset is ready, a Token Agent calls unpause. From that moment holders can transfer under the rules of the asset.
Where journeys diverge
The Issuer supplies its own access manager. The factory then writes nothing into it, and the Issuer commissions the suite itself: step 2 of 25.
Eligibility is set at deployment.
deployTREXSuiteaccepts up to five claim topics and five Claim Issuers as a starting configuration. Stages 4 and 5 are then adjustments.The Issuer does not want to follow the network's versions. It deploys an isolated suite and upgrades it itself: 27.
Some holders cannot link their own addresses. A Registry Agent registers those addresses for the asset: 06.
The asset is distributed on other chains. The Issuer opens each satellite explicitly: J4.
Related journeys
J2 Investor journey: from onboarding to secondary transfer : what the first investors do before stage 8
J3 Transfer agent journey: operations on a live asset : what the Issuer's agents do once the asset is live
J4 Cross-chain journey: distribute and reconcile : taking the asset to satellites