# Asset Issuance

Source: https://docs.settlemint.com/docs/architecture/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 Asset 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[Asset Console or /api/v2/tokens]
  Engine[DALP Execution Engine]
  Workflow[Token creation workflow]
  Factory[Asset factory]
  Signer[Signing flow]
  Chain[SMART Protocol contracts]
  Indexer[Chain Indexer]
  Result[Asset 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/user-guides/asset-creation/create-asset): operator workflow in Asset Designer
* [Create an asset with the API](/docs/developer-guides/asset-creation/create-asset): `/api/v2/tokens` payload and troubleshooting
* [Asset Contracts](/docs/architecture/components/asset-contracts): token types and configurations
* [Signing Flow](/docs/architecture/flows/signing-flow): transaction signing sequence
* [Authorization](/docs/architecture/security/authorization): role assignments

***

## Flow boundary [#flow-boundary]

Asset issuance has two layers:

1. **Platform setup** creates the system, registries, compliance contracts, and factories that make issuance possible.
2. **Per-instrument creation** uses an asset template and factory to deploy one asset, grant its initial roles, issue identity claims, and prepare it for controlled operation.

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.

| 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 Execution 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. 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, and per-token access manager   | Automatic     |
| 3    | Workflow reads the `TokenAssetCreated` event from the transaction receipt | Automatic     |

**Output:** Token address, token identity, per-token access manager, 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.
* Global compliance modules apply to tokens automatically.
* Per-token compliance modules are additive to global modules.
* 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/architecture/flows/signing-flow).
* The Chain Indexer returns the deployed asset state to the Asset Console and API after chain confirmation.

***

## See also [#see-also]

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