Asset detail workspace

The asset detail workspace is the operating view for one issued asset. Start here to confirm the token's status, holder state, configured features, compliance controls, and documents. Check the available operator workflows before you mint, transfer, pause, update pricing or fees, or change control records.

Open the workspace from Asset management. Choose an asset class, open the asset type or template, and select the issued asset.

Use the page in this order:

1. Confirm the asset name and status in the header. Verify the breadcrumb matches the asset you intend to service.
2. Use the tabs to review holder balances, workflow history, compliance, documents, feeds, permissions, and denomination details.
3. Open Manage Asset only after the review tabs show the current state.

Manage Asset is context-sensitive. DALP hides menu items that the current asset or system configuration does not support. Visible but unavailable items are disabled, and their tooltip names the permission, feature, or asset-state check that blocks submission.

View-only access

If you can open an asset but hold no management role on it, DALP shows a View only access banner at the top of the asset detail. The banner reads "You don't have management access to this asset. You can view its details, but not manage or configure it." It stays in view across every tab, so the read-only state is clear before you go looking for a workflow that is not there.

View-only access means:

• You can review every tab the asset exposes: token information, holders, actions, compliance, documents, and any feature tabs the asset configures.
• Management and configuration workflows stay disabled. You will not be able to mint, transfer on the asset's behalf, pause, update pricing or fees, change control records, or edit token settings.
• Holder actions you are entitled to as a holder, such as transferring, approving, or redeeming your own balance, still work. Those follow your holdings, not a management role.

To act on the asset's configuration, ask an administrator to assign you the matching token-level role. Review current assignments on the Permissions tab, then see change asset admin roles for how roles are granted.

What the workspace shows

The default tab summarizes the issued asset before you move into a specific workflow. It helps you answer four questions:

Feature tiles link to detail pages when a feature has its own workflow. Maturity, yield, conversion, AUM fee, events, verifications, and metadata open as full pages instead of staying inside the tab frame.

Token tabs

The tab bar is generated from the asset configuration. The common workspace tabs are Token information, Holders, Actions, Compliance, and Documents. Feeds appears only when the feeds directory is installed. Permissions and Denomination asset appear only when the token has the matching extension.

Token documents, metadata, and verification routes

The documents route is /token/{assetClassSlug}/{templateSlug}/{tokenAddress}/documents. Open it from the Documents tab to review and manage files associated with the asset.

The metadata detail route is /token/{assetClassSlug}/{templateSlug}/{tokenAddress}/metadata. Metadata opens from the metadata capability tile and uses a full detail page rather than the tab frame. To add, update, or remove on-chain metadata entries from this page, see manage on-chain token metadata.

The verification route is /token/{assetClassSlug}/{templateSlug}/{tokenAddress}/verifications. Open it from the verifications tile to review the identity claims attached to the token's own on-chain identity. These claims can let the token act as a verified party in compliant transfers. Like metadata, the page opens as a full detail page rather than inside the tab frame, so the workspace tab row is replaced by its own breadcrumb while you review claims. The page shows claims only. Topic schemes and trusted issuers have their own detail pages, which you open from the Trust Registry tile on the Token information page.

When the asset has no token identity yet, the verification page shows an empty state instead of a claims list. Attach a token identity first when you expect verification data. Adding a claim from this page is role-gated. Claim issuance stays disabled when your permissions or the token's identity do not allow it, while the existing claims remain visible for review.

This page reviews the claims a token already holds. To require holders to carry a verified-identity claim before they can transact, configure the identity verification compliance module.

Compliance tab details

The Compliance tab opens with a details grid so you can confirm the token's compliance wiring before you read individual modules. The grid shows:

• Compliance contract address: the on-chain contract that hosts this token's compliance modules.
• Identity registry address: the on-chain registry that controls which addresses are eligible to hold the token.
• Compliance expression, read-only, shown only when an expression is configured on the token's identity registry.

The compliance expression is the native verification rule the identity registry evaluates before a transfer. The expression gates the token's transfers directly, separately from any list-based or policy module shown lower on the tab. You change the expression through the API, not from the Console. The Console shows the configured value read-only so you can confirm what is in force without risking an accidental edit.

When no expression is set, the grid shows no expression row. An unset expression is permissive: every address with an accepted identity that is not marked as lost passes the native verification gate, so holder eligibility then depends on the compliance modules and trusted-issuer claims you configure elsewhere. To require a verified-identity claim before holders can transact, configure the identity verification compliance module. For the expression model, evaluation order, and failure behavior, see Identity Verification.

Compliance lists and frozen holders

Allowlist and blocklist behavior is represented through compliance configuration rather than separate public tabs in the current workspace.

Use the Compliance tab to confirm whether the asset has a list-based compliance module, such as an address, identity, or country blocklist. The module detail shows the configured list values for that control. Use the Holders tab separately to review balances, frozen amounts, and fully frozen holders. Frozen holder state is a balance-control signal; it does not prove that a holder appears in a compliance blocklist.

Treat list changes and holder-freeze changes as compliance-sensitive operator workflows. Before changing either control, confirm the asset, address or identity, restriction reason, and the role permitted to submit the change. Keep supporting evidence in your institution's review and audit process outside DALP.

Manage asset workflows

Use Manage Asset for workflows that change the token or open an operator sheet. The menu is permission-gated and context-sensitive.

Depending on the asset and system configuration, the menu can include minting, transfers, pause or unpause, forced transfer workflows, verification, transfer approvals, price updates, collateral updates, and token-sale creation. The menu also includes View events so you can inspect event history from the same asset context.

For conversion assets, use forced conversion only when the configured conversion workflow and your custody role permit a custodian-controlled conversion. For servicing-provider transitions, use exit control portability to plan the role, policy, holder, document, and evidence records that need review prior to an authority change.

Transfer approvals

If the asset uses the TransferApproval compliance module, approval authorities can use Manage Asset to approve a specific sender, recipient, and amount before the holder submits the transfer. The approval sheet accepts source wallet, recipient wallet, and amount, then shows a confirmation summary before wallet verification. The platform records the approval against the sender and recipient identities used by the module.

Review existing approvals from the Compliance tab. The Transfer approvals table lists the sender identity, recipient identity, approved amount, expiry, and status. Pending approvals can be revoked from that table when your role permits revocation. Consumed and revoked approvals remain visible as review records; create a new approval when the transfer needs a different amount, counterparty, or operating evidence.

For API-driven transfer approval workflows, see Token holders and transfers. For the compliance model, see Transfer approval.

Recipient eligibility checks

Mint, transfer, and forced-transfer workflows check each recipient address for eligibility before you submit, so an ineligible recipient is caught in the Console instead of failing as an on-chain compliance revert. Granting a fee exemption for an account address checks that account the same way.

The recipient picker lists eligible addresses by default, so a recipient you select from the default list passes this check. Two paths can still present an ineligible address: typing or pasting one in manual entry, and using Show all in the picker to reveal addresses that the eligibility filter hides. In both cases the sheet verifies the chosen address against the token's eligibility before letting you continue. While that verification runs, the action stays disabled, and an ineligible recipient blocks the workflow with an inline message naming the address.

Eligibility here means the address holds an active, registered identity for the token, in the token's own identity registry or your organization's system registry. It is a pre-flight signal, not the final authority: the token contract still enforces every compliance module, claim, and amount, freeze, or pause control when the transaction executes, so a transfer can still revert on-chain even after the recipient passes the pre-check. For the integration-side endpoint and the exact verdict semantics, see Recipient eligibility check.

External transaction fee checks

If an asset uses an external transaction fee, mint, burn, and transfer confirmation screens check the connected wallet before you submit when that wallet is the fee payer. The screen shows whether the wallet has enough fee-token balance and enough allowance for the external fee feature to collect the fee.

The readiness check applies when you:

• mint to the connected wallet
• burn from the connected wallet
• transfer from the connected wallet

When the allowance is too low, use Approve fee allowance from the confirmation screen. The approval flow selects the required spender. Once approved, the readiness check updates so you can submit the original workflow.

When an operator workflow charges a different wallet, such as minting to another recipient or burning another holder, that third-party wallet is not preflighted in the confirmation screen. Confirm the fee-token balance and allowance with that holder before submitting.

When a workflow is missing or disabled, start with access and state. Check your token-level role assignments on the Permissions tab. Confirm the asset is not paused and that the required compliance module or token feature is configured. If the check still fails, review the system-level feature flag for that workflow.

First, confirm you hold a management role on the asset. A viewer with no role sees the view-only access banner and disabled controls.

Next, check wallet conditions. Your wallet needs enough balance for holder workflows. When the asset uses an external transaction fee, the fee-token balance and allowance must be sufficient. Confirm the system-level feature and permission for the workflow are enabled.

For verification workflows: the asset must have a token identity. For collateral updates: the collateral module must be configured and a token identity address must be available. For token-sale creation, four conditions apply. Token sales must be enabled. Your user must have token-sale creation permission. The asset must carry a registered token identity, and a token-sale addon factory must be available.

Related guides

• Create asset
• Register external tokens
• Review address book contacts
• Mint assets
• Set a token price
• Freeze and unfreeze holder balances
• Pause or unpause an asset
• Force convert holder principal
• Manage authorized converters
• Keep control records portable during an exit
• Verify identities and KYC data
• Change asset admin roles
• Token feature catalog