> For the complete documentation index, see [llms.txt](https://docs.t-rex.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.t-rex.network/guides/journeys/j1.-issuer-journey-launch-an-asset.md).
# 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
| # | Stage | Flow | Who acts | Outcome |
| - | --------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
| 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 | [01 Deploy a token suite](/guides/issuer/01.-deploy-a-token-suite.md) | Deployer | Token, eligibility registry, identity storage, compliance and access manager exist, commissioned. The token is paused, with no supply |
| 3 | Grant roles | [25 Commission a suite and grant roles](/guides/issuer/25.-commission-a-suite-and-grant-roles.md) | Issuer | The Issuer's operators hold the roles of the Issuer's domain that they need |
| 4 | Set what an investor must prove | [03 Configure required claim topics](/guides/issuer/03.-configure-required-claim-topics.md) | Issuer | The asset has its required claim topics, by default and per identity type |
| 5 | Decide whose attestations count | [04 Add a trusted Claim Issuer](/guides/issuer/04.-add-a-trusted-claim-issuer.md) | Issuer | The Claim Issuers the asset trusts are listed, each for its topics |
| 6 | Set the rules of the asset | [11 Add a compliance rule](/guides/issuer/11.-add-a-compliance-rule.md) | Compliance Owner | The modules that enforce the terms of the asset are bound and configured |
| 7 | Decide which spenders the asset accepts | [26 Authorize spenders](/guides/issuer/26.-authorize-spenders.md) | Compliance Owner | The asset has a spender policy. Optional |
| 8 | Mint the first positions | [08 Mint a position to an investor](/guides/positions/08.-mint-a-position-to-an-investor.md) | Token Agent | The first investors hold their positions |
| 9 | Open the asset | [16 Pause and unpause a token](/guides/agents/16.-pause-and-unpause-a-token.md) | Token Agent | Holders can transfer |
## Overview
```mermaid
flowchart LR
S1["1. Right to deploy"] --> S2["2. Deploy
01"]
S2 --> S3["3. Grant roles
25"]
S3 --> S4["4. Claim topics
03"]
S4 --> S5["5. Trusted Claim Issuers
04"]
S5 --> S6["6. Compliance rules
11"]
S6 -.-> S7["7. Spender policy
26"]
S6 --> S8["8. First mints
08"]
S7 -.-> S8
S8 --> S9["9. Lift the pause
16"]
```
## 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](/guides/journeys/j2.-investor-journey-from-onboarding-to-secondary-transfer.md). 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](/guides/issuer/25.-commission-a-suite-and-grant-roles.md).
* **Eligibility is set at deployment.** `deployTREXSuite` accepts 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](/guides/issuer/27.-upgrade-a-suite.md).
* **Some holders cannot link their own addresses.** A Registry Agent registers those addresses for the asset: [06](/guides/agents/06.-register-an-investor-for-an-asset.md).
* **The asset is distributed on other chains.** The Issuer opens each satellite explicitly: [J4](/guides/journeys/j4.-cross-chain-journey-distribute-and-reconcile.md).
* **The terms change after launch.** A rule is added or removed with [11](/guides/issuer/11.-add-a-compliance-rule.md) and [12](/guides/issuer/12.-remove-a-compliance-rule.md), and a Claim Issuer is removed with [20](/guides/issuer/20.-remove-a-trusted-claim-issuer.md).
## Related journeys
* [J2 Investor journey: from onboarding to secondary transfer](/guides/journeys/j2.-investor-journey-from-onboarding-to-secondary-transfer.md) : what the first investors do before stage 8
* [J3 Transfer agent journey: operations on a live asset](/guides/journeys/j3.-transfer-agent-journey-operations-on-a-live-asset.md) : what the Issuer's agents do once the asset is live
* [J4 Cross-chain journey: distribute and reconcile](/guides/journeys/j4.-cross-chain-journey-distribute-and-reconcile.md) : taking the asset to satellites
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.t-rex.network/guides/journeys/j1.-issuer-journey-launch-an-asset.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.