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
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.
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
- Create an asset in the console: operator workflow in Asset Designer
- Create an asset with the API:
/api/v2/tokenspayload and troubleshooting - Asset Contracts: token types and configurations
- Signing Flow: transaction signing sequence
- Authorization: role assignments
Flow boundary
Asset issuance has two layers:
- Platform setup creates the system, registries, compliance contracts, and factories that make issuance possible.
- 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
Asset issuance spans seven phases. Phases 1-3 execute once for a platform deployment. Phases 4-7 repeat for each new instrument.
Phase details
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
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
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
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
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
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
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 |
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.
- The Chain Indexer returns the deployed asset state to the Asset Console and API after chain confirmation.
See also
- Create an asset in the console for the operator workflow
- Create an asset with the API for request payloads and API errors
- Deployment Architecture for factory deployment patterns
- Authorization for role definitions
- Lifecycle after issuance for what happens after an asset is deployed
Signing Flow
How DALP moves an EVM transaction from a verified user or API request through compliance simulation, custody signing, provider policy review, and broadcast.
Compliance Transfer
Step-by-step sequence for how DALP validates token transfers through recipient identity checks, token-specific compliance modules, global compliance policy, and post-transfer state hooks.