Issuer workflow

1. Establish the issuer workspace

Prepare a personal wallet for testnet self-service, enough native ASSET for wallet-signed actions, the asset terms, and the intended owner and investor rules. Self-service requires a full-authority session with the personal wallet acting for itself. Existing Safe workflows are separate; a Safe or delegate session does not qualify for this personal-wallet onboarding path.

The source policy defaults to one workspace per account and five suite deployments per issuer. The deployment quota is configurable and was not read from a live administrative interface. Production KYB, admission requirements, fees, and service timelines remain unconfirmed; testnet registration does not settle them. An issuer workspace represents the organization operating its token suites. It has a primary wallet and members with administrator, operator, or viewer permissions. Workspace permissions and on-chain ownership are separate: the wallet executing an operation must also hold the required contract role.

The platform supports operator-reviewed issuer onboarding and a separately enabled testnet self-service path. The self-service path is for eligible personal-wallet accounts; it does not create a Safe, grant Business Validator admission, or replace production admission requirements.

Issuer registration must finish before automatic token deployment can begin. If registration is pending, creating another workspace or repeating the deployment request is not a substitute for completing it.

2. Define the token and its rules

New standard suites require KYC, AML, SANCTIONS_CLEARED, and JURISDICTION claims. The issuer-facing platform preserves that baseline. Check existing investors before adding another required topic: the change can immediately affect their eligibility. See identity and eligibility. Prepare the token name, symbol, precision, and the asset it represents. Decide which investor requirements and supported compliance controls the suite needs, such as jurisdiction restrictions, a supply cap, or a maximum holding per wallet.

The token suite connects these settings to the contracts that enforce them. The asset's terms and supporting agreements remain the basis for the rights represented by the token.

3. Deploy and confirm control

In the operator-reviewed path, a suite request proceeds through approval before deployment. Where testnet automatic deployment is enabled, a registered issuer can submit a request within the environment's limits.

Deployment is a multi-step process. It creates the suite, configures the requested modules and roles, and hands the relevant ownership to the issuer wallet. Wait for the process to complete before treating the suite as ready.

New tokens start paused. Deployment does not admit investors, mint a supply, unpause transfers, or list the asset publicly.

4. Prepare the asset information

Create the asset description, classification, jurisdiction information, and public document set. Review the information before authorizing its on-chain association with the token.

Asset information and documents explains how stored files and on-chain records work together. Public directory listing is a separate platform decision.

5. Admit eligible investors

Investors can request access after establishing platform eligibility. The issuer reviews each request and authorizes registration in the suite's identity registry. Approval in a workflow is not complete admission until the required on-chain registration succeeds.

An issuer can also introduce investors it has independently verified. That path uses the issuer's own claim authority and leaves verification and ongoing screening responsibility with the issuer. It must not be described as platform verification.

6. Begin and maintain operations

Issue tokens only to recipients who meet the suite's requirements. Review the configuration and operational readiness before unpausing ordinary transfers. Maintain documents, investor access, and token controls as the asset changes.

If the asset uses an offering, its subscription, payment, and delivery process is a separate workflow. A deployed token alone does not constitute an open offering. Safe-controlled issuers must allow time for the required co-signatures and execution.

Open the testnet workspace

For primary issuance, continue with offerings and subscriptions. Check the payment window, agreement requirements, selected payment asset, and fee terms before opening an offering. A token deployment does not configure distributions, redemption, or corporate actions by itself; those workflows are not verified in this edition. Use the testnet issuer portal to explore the available workflow. If your wallet is not configured, first add Real Testnet.