Lifecycle after issuance
How DALP operators manage an issued asset after deployment, from the asset detail workspace through supply, transfer, pause, role, compliance, feature, and audit operations.
After issuance, a DALP asset moves into an operating loop: read the current token state, decide whether a servicing action is allowed, submit the UI or API mutation, then reconcile the transaction status, events, holder balances, documents, and feature state. Operators use the asset detail workspace for day-to-day work, the Unified API for automation, and feature pages for token behavior that was attached to the asset.
DALP enforces token roles, compliance modules, enabled token features, wallet verification, holder balances, and the current asset state. The operator still owns the off-platform decisions: investor instructions, legal approvals, treasury funding, reserve evidence, and accounting records.
Related architecture pages: Tokenization modeling, Asset issuance, Asset detail workspace, and Token lifecycle API.
Lifecycle model
Operating loop
A safe post-issuance operation follows the same loop whether it starts in the UI or the API:
- Read the token, feature, holder, compliance, or action record that governs the operation.
- Confirm the caller has the required token role or signer condition.
- Confirm the asset state and feature state allow the mutation.
- Submit the mutation from the asset detail workspace or the matching token subresource endpoint, such as mint, burn, transfer, feature, metadata, or role routes under the token address.
- Poll the returned status link when the response is asynchronous.
- Re-read token events, action status, holder balances, transfer records, documents, or feature state before retrying or telling another system that the operation is complete.
Token events are the historical activity trail. They do not replace the current read model for token state, holder balances, treasury funding, or feature configuration.
Operating surfaces
| Surface | Use it for | Notes |
|---|---|---|
| Asset detail workspace | Review the issued asset, holder table, actions, compliance configuration, documents, feature tiles, and the Manage Asset menu. | The workspace only shows actions and tabs that apply to the current asset and system configuration. |
| Manage Asset menu | Start common operator workflows such as minting, pause or unpause, forced transfer, verification actions, collateral updates, transfer approvals, and token-sale creation when available. | Menu entries are permission-gated and can be hidden or disabled when the asset state, role, feature, or system check does not pass. |
| Token lifecycle API | Automate creation, minting, transfer, burn, feature, and reconciliation workflows. | State-changing calls return synchronous transaction metadata or async status links, depending on the operation. |
| Token feature pages | Operate feature-specific workflows such as maturity redemption, fixed treasury yield, conversion, AUM fees, transaction fees, and historical balance reads. | Read the token's attached features before submitting a feature mutation. |
Common post-issuance operations
| Operation area | What changes | Primary control |
|---|---|---|
| Supply servicing | Minting increases supply; burning decreases supply and can target one or more holder balances. | Supply-management token role, wallet verification, holder balance checks, and asset state checks. |
| Transfer control | Normal holder transfers must pass identity and compliance checks; forced-transfer workflows are custodian operations for exceptional servicing cases. | Token-holder balance and compliance checks for normal transfers; custodian permission for forced transfers. |
| Pause state | Pausing blocks selected token operations until an authorized operator unpauses the asset. | Emergency token role and current paused state. |
| Token roles | Role grants and revocations change which operators can administer, govern, manage supply, or run emergency workflows for the token. | Token admin role. |
| Compliance configuration | Operators can review and, where permitted, configure token-level compliance modules and parameters. | Compliance-manager or governance-controlled routes, depending on the operation. |
| Feature operations | Configured features add day-two actions such as maturity, redemption, yield claims, treasury top-ups, fee configuration, conversion, and historical balance reads. | The feature must be attached; each operation uses the role or signer condition for that feature. |
| Reconciliation | Operators review action status, token events, holder balances, transfers, documents, and feature status after transactions confirm. | Actions, events, holder, transfer, document, and feature reads. |
Feature-gated lifecycle actions
Not every issued asset has the same day-two operations. Feature actions should be treated as available only when the token reports the matching feature attached.
Examples of feature-gated operations include:
- maturity-redemption operations for maturing, early maturity, treasury top-ups, treasury updates, wallet-treasury allowance, and holder redemption;
- fixed-treasury-yield operations for treasury setup, top-ups, and holder yield claims;
- conversion operations for triggers, conversion windows, holder conversion, forced conversion, and authorized converters;
- fee operations for rate, recipient, exemption, freeze, collection, or reconciliation workflows, depending on the configured fee feature;
- historical balance reads for holder snapshots and reporting.
Treasury-backed feature operations depend on denomination-asset funding. A top-up funds the configured feature treasury or legacy redemption pool. Top-ups do not mint new payout assets.
Read before you mutate
Before running a lifecycle mutation, confirm:
- The token exists and the current user can see it in the asset detail workspace or token read endpoint.
- The caller has the token role or signer condition required for the operation.
- The asset is in the right state, such as unpaused for minting, sufficient holder balance before burning, or matured for redemption.
- The required compliance module, token feature, treasury, trigger, or collateral configuration is present.
- Wallet verification is current when the workflow signs a transaction.
- The resulting transaction status, action record, event, holder balance, or feature status has been reconciled before retrying.
Where to go next
| If you need to... | Read next |
|---|---|
| Review an issued asset in the UI | Asset detail workspace |
| Mint new supply | Mint assets |
| Burn outstanding supply | Burn assets |
| Pause or unpause an asset | Pause or unpause an asset |
| Change token-level administrators | Change asset admin roles |
| Review all API operation flows | Token lifecycle API |
| Understand configured token behavior | Token features |
| Understand transfer eligibility | Compliance transfer |
System context
System context for DALP architecture, including external actors, operating scopes, trust boundaries, and the contract layers that keep assets, identities, compliance rules, and factory registries separated by system.
Key flows
Index of the main DALP system flows, covering shared platform operations, asset lifecycle capabilities, feed updates, and settlement workflows with links to detailed walkthroughs.