# Asset Issuance

Source: https://docs.settlemint.com/docs/architects/flows/asset-issuance
Architecture flow for issuing a new DALP digital asset, from platform setup
through Asset Designer or API submission, token deployment, role grants,
identity claims, optional price feed submission, and first operations.




## System context [#system-context]

Asset issuance turns an approved instrument configuration into deployed SMART Protocol contracts, registered roles, identity claims, and an initial operating state. Operators can start from the Asset Designer in the Console, while API clients submit the same templated creation flow through `/api/v2/tokens` with `type: "dalp-asset"` and a `templateId`.

<Mermaid
  chart="`flowchart LR
  Entry[Console or /api/v2/tokens]
  Engine[DALP Workflow Engine]
  Workflow[Token creation workflow]
  Factory[Asset factory]
  Signer[Signing flow]
  Chain[SMART Protocol contracts]
  Indexer[Ledger Index]
  Result[Console and API status]

  Entry --> Engine --> Workflow --> Signer --> Factory --> Chain
  Chain --> Indexer --> Result`"
/>

This explanation page describes the architecture and state transitions behind issuance. For step-by-step operating instructions, use the console and API guides linked below.

## Related [#related]

* [Create an asset in the console](/docs/operators/asset-creation/create-asset): operator workflow in Asset Designer
* [Create an asset with the API](/docs/developers/asset-creation/create-asset): `/api/v2/tokens` payload and troubleshooting
* [Asset Contracts](/docs/architects/components/asset-contracts): token types and configurations
* [Signing Flow](/docs/architects/flows/signing-flow): transaction signing sequence
* [Authorization](/docs/compliance-security/security/authorization): role assignments

***

## Flow boundary [#flow-boundary]

Asset issuance has two layers. Platform setup creates the organisation-level system once. Per-instrument creation then uses the registered factories inside that system to deploy each asset separately.

| Layer                   | What is created                                                                                                         | When it runs                   | What it controls                                                                             |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------ | -------------------------------------------------------------------------------------------- |
| Platform setup          | System proxy, system access manager, identity registry, compliance contract, token factory registry, and addon registry | Once for a platform deployment | Shared system services and the factories that later create assets                            |
| Per-instrument creation | Token contract, token identity, per-token access manager, per-token compliance, and token-scoped identity registries    | Once per new instrument        | The roles, metadata, compliance modules, registry checks, and operating state for that asset |

The two layers are connected, but they do not have the same scope.

The System Factory creates the platform system and its access manager. System bootstrap creates and wires the registries and shared compliance services. Later, the DALP asset factory uses a selected template to deploy one token, its on-chain identity, its own access manager, its token-scoped compliance contract, and token-scoped identity registries. The per-token access manager controls the asset's roles; it is not the same contract as the system access manager created during platform setup.

The current product taxonomy exposes seven deployable base asset types: bond, equity, fund, stablecoin, deposit, real estate, and precious metal. The templated Asset Designer path routes these through the DALP asset factory, where the selected template supplies the asset class, required features, metadata schema, and compliance controls.

***

## Deployment phases [#deployment-phases]

Asset issuance spans seven phases. Phases 1-3 execute once for a platform deployment. Phases 4-7 repeat for each new instrument.

<Mermaid
  chart="`flowchart TB
  subgraph ONCE[&#x22;One-time platform setup&#x22;]
    P1(Phase 1: Infrastructure)
    P2(Phase 2: System bootstrap)
    P3(Phase 3: Identity and compliance setup)
  end

  subgraph REPEAT[&#x22;Per instrument&#x22;]
    P4(Phase 4: Asset configuration)
    P5(Phase 5: Factory deployment)
    P6(Phase 6: Post-deploy setup)
    P7(Phase 7: Initial operations)
  end

  P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7`"
/>

***

## Phase details [#phase-details]

![Asset issuance begins in the Asset Designer](/docs/screenshots/asset-designer/asset-designer.webp)

### Phase 1: Infrastructure deployment [#phase-1-infrastructure-deployment]

The platform deploys the implementation contracts and system factory needed by the DALP system. On SettleMint networks with genesis allocations, these implementation contracts may already be available, so execution can begin at system bootstrap.

| Step | Transaction                                                                         | Sender   |
| ---- | ----------------------------------------------------------------------------------- | -------- |
| 1    | Deploy implementation contracts for system, token, addon, and compliance components | Deployer |
| 2    | Deploy the system factory with implementation addresses                             | Deployer |

**Output:** System factory address.

### Phase 2: System bootstrap [#phase-2-system-bootstrap]

System bootstrap creates the organisation's platform system instance and registers the factories used by later asset creation. The system access manager governs this shared layer. Asset roles are assigned later on each token's own access manager.

| Step | Transaction                                                             | Role required |
| ---- | ----------------------------------------------------------------------- | ------------- |
| 1    | `createSystem()` on the system factory                                  | Deployer      |
| 2    | `bootstrap()` on the system proxy                                       | Deployer      |
| 3    | Register token factories for supported base asset types                 | Deployer      |
| 4    | Register addon factories used by asset features and operating workflows | Deployer      |

**Output:** System proxy, access manager, identity registry, compliance contract, and factory registries.

### Phase 3: Identity and compliance setup [#phase-3-identity-and-compliance-setup]

Identity and compliance setup defines which actors and assets can participate in regulated token operations.

| Step | Transaction                                                       | Role required        |
| ---- | ----------------------------------------------------------------- | -------------------- |
| 1    | Grant identity and compliance administration roles                | System admin         |
| 2    | Create identities for actors                                      | Each actor           |
| 3    | Register identities in the identity registry                      | Identity manager     |
| 4    | Add trusted claim issuers                                         | Claim policy manager |
| 5    | Issue KYC or AML claims to identities                             | Claim issuer         |
| 6    | Add global compliance modules such as country or address controls | Compliance manager   |

### Phase 4: Asset configuration [#phase-4-asset-configuration]

The operator or API client selects an instrument template and submits the asset configuration. In the console, this happens in Asset Designer. API clients send the selected `templateId`, identity fields, valuation fields, metadata values, compliance module pairs, optional feature configuration, and wallet verification to `/api/v2/tokens` with `type: "dalp-asset"`.

| Input                   | What it controls                                                                    |
| ----------------------- | ----------------------------------------------------------------------------------- |
| Template                | Asset class, base asset type, required features, and metadata schema                |
| Metadata values         | Instrument-specific fields such as issuer, classification, or reference identifiers |
| Compliance module pairs | Per-token compliance controls, including template-expanded controls                 |
| Feature configuration   | Feature-specific settings that the factory encodes for deployment                   |
| Wallet verification     | The signing authorisation used for the on-chain create transaction                  |

### Phase 5: Factory deployment [#phase-5-factory-deployment]

The Workflow Engine routes the submitted configuration to the matching token creation workflow. For templated assets, the workflow resolves the template, expands the required feature set, encodes metadata and compliance parameters, and calls the DALP asset factory.

The factory deploys a fresh per-token access manager before it deploys the token. For the templated DALP asset path, it also creates token-scoped compliance and token-scoped identity registries for the deployed token. Two assets in the same platform system can therefore have different asset-level role assignments and isolated token compliance state. Legacy typed creation paths still dispatch to their matching handlers for base types such as bond, equity, fund, stablecoin, deposit, real estate, and precious metal.

| Step | Transaction                                                                                         | Role required |
| ---- | --------------------------------------------------------------------------------------------------- | ------------- |
| 1    | Submit the factory create transaction through the signing flow                                      | Token manager |
| 2    | Factory deploys the token, token identity, per-token access manager, compliance, and registry layer | Automatic     |
| 3    | Workflow reads the `TokenAssetCreated` event from the transaction receipt                           | Automatic     |

**Output:** Token address, token identity, per-token access manager, per-token compliance, token-scoped registries, and transaction hash.

### Phase 6: Post-deploy setup [#phase-6-post-deploy-setup]

After deployment, DALP completes the setup that makes the asset manageable and auditable.

| Step | Transaction                                                                                                          | Role required          |
| ---- | -------------------------------------------------------------------------------------------------------------------- | ---------------------- |
| 1    | Grant initial per-token roles; if no custom permissions are supplied, the submitting wallet receives `governance`    | Token admin            |
| 2    | Issue asset identity claims to the token identity                                                                    | Claim issuer           |
| 3    | Submit an initial price feed when the organisation has the feed addon installed and the asset input includes a price | Feed submission signer |
| 4    | Optionally unpause the asset when `unpauseOnCreation` is requested                                                   | Emergency role         |

By default, assets remain paused after creation. A creation request can ask DALP to unpause the asset only when the required role grant is present. A paused asset is visible for review, but issuance and transfers stay disabled until an authorised operator unpauses it.

### Phase 7: Initial operations [#phase-7-initial-operations]

Initial operations prove that the deployed asset is ready for controlled use.

| Step | Operation                                                               | Role required     |
| ---- | ----------------------------------------------------------------------- | ----------------- |
| 1    | Review the asset details, roles, metadata, and compliance configuration | Governance        |
| 2    | Unpause the asset if it was intentionally created paused                | Emergency         |
| 3    | Mint tokens to initial holders                                          | Supply management |
| 4    | Transfer between verified holders                                       | Token holders     |
| 5    | Confirm blocked transfers fail when compliance rules reject them        | Not applicable    |

***

![Review and deploy confirmation](/docs/screenshots/asset-designer/asset-designer-review-and-deploy-1.webp)

## Key dependencies [#key-dependencies]

* Identity registration must complete before token operations.
* Shared compliance services provide the platform-level baseline.
* Templated DALP assets receive token-scoped compliance and token-scoped identity registries during factory deployment.
* Per-token compliance modules are additive to the shared baseline.
* Template-selected compliance controls must be submitted as module pairs; DALP rejects a templated create request that selects a compliance template but submits no controls.
* All on-chain writes execute through the [Signing Flow](/docs/architects/flows/signing-flow).
* The Ledger Index returns the deployed asset state to the Console and API after chain confirmation.

***

## See also [#see-also]

* [Create an asset in the console](/docs/operators/asset-creation/create-asset) for the operator workflow
* [Create an asset with the API](/docs/developers/asset-creation/create-asset) for request payloads and API errors
* [Deployment Architecture](/docs/architects/components/asset-contracts/deployment-architecture) for factory deployment patterns
* [Authorization](/docs/compliance-security/security/authorization) for role definitions
* [Lifecycle after issuance](/docs/architects/overview/lifecycle-after-issuance) for what happens after an asset is deployed