Feature constraints

Token feature constraints keep an instrument template deployable before an asset reaches issuance. DALP validates the selected token features as a set: dependencies must be present, mutually exclusive pairs cannot be enabled together, and template-driven feature closure can add directly implied features when a selected feature requires its counterpart.

Use this reference when you design an instrument template. It also helps when you review an Asset Designer selection or build an API integration that submits template-backed feature configuration.

Scope and validation surfaces

This page covers the current DALPAsset token-feature registry used by template validation and deployment: the Asset Designer, template publishing, token-creation API preflight, deployment workflow, and SMART Protocol feature attachment on EVM networks. It does not describe non-EVM assets or future feature availability.

The UI, API, and deployment workflow all read the same feature IDs and constraint rules. Smart contracts receive the final ordered feature configuration during deployment. They attach the features atomically and then execute the feature hooks exposed by each contract module. There is no separate on-chain template-rule registry that rechecks Asset Designer dependencies after deployment starts.

Current feature set

DALP recognizes these token feature IDs for DALPAsset templates:

The list is the supported token-feature vocabulary for template selection and validation. Feature availability still depends on the target environment. Confirm the required asset type and feature factories before using a template in production.

Configurable value ranges

Token configuration combines feature selection with numeric and pricing fields from the selected template. Keep these ranges aligned across the Asset Designer, API payloads, and contract-facing values:

The API rejects values outside their configured field type. The Asset Designer should prevent the same invalid values before submission.

Smart-contract validation is narrower and later in the flow. Deployment receives the feature set only after template validation has accepted dependencies and mutually exclusive pairs. Contract modules then validate the parameters they own, such as fee, collateral, yield, or lifecycle-hook inputs. Treat UI validation as operator guidance, API validation as the template gate, and contract validation as the final module-level guard during deployment and execution.

Dependency rules

Feature dependencies state that one feature only makes sense when another feature is also selected.

When a template or request lists conversion-minter without conversion, DALP treats the feature set as invalid. Update the template's required features before publishing or creating assets.

Mutually exclusive rules

Mutually exclusive pairs prevent two features from owning the same economic behavior in different ways.

The rule is symmetric. If either feature is selected, the other option is unavailable for the same template-backed asset.

Feature-closure expansion

DALP uses feature-closure expansion when it needs the complete set of features implied by a template selection. The closure keeps the selected order, removes repeated inputs, and appends directly implied dependent features at the end.

For the current registry, selecting conversion implies conversion-minter because the conversion flow needs both sides of the pair:

Expansion does not pull missing prerequisites into an invalid dependent-only selection. If a selected feature has an unmet dependency, DALP reports the dependency problem instead of guessing the operator's intent.

Expansion is intentionally direct. It adds dependents whose own dependencies are already satisfied by the selected set. It does not chase newly added features through a transitive chain. There are no transitive dependency chains in the current feature registry.

Asset Designer constraint display

The Asset Designer and template-management screens use the same constraint rules as the API validation layer. When an operator edits required features:

• incompatible options are disabled when their pair is already selected,
• dependent-only choices show the missing required feature,
• the expanded feature set is stable when the input has not changed,
• feature descriptions stay attached to the same feature IDs used by API requests.

This keeps the UI from presenting a feature combination that the template publish or asset creation path would later reject.

UI, API, and smart-contract validation

The same feature registry drives the Asset Designer and API validation, but each layer has a different job:

For DALPAsset creation, templateId is required. DALP reads the selected template, combines the template's required features with submitted featureConfigs, validates dependency and incompatibility rules, and then passes the valid feature set into deployment.

Use these rules when building API requests:

1. Select a published instrument template that already includes the token behaviors required for the asset.
2. Submit featureConfigs only for template-enabled features that need operator-provided settings.
3. Do not submit settings that imply a mutually exclusive feature pair on the same asset.
4. Treat unmet dependencies as template configuration errors, not as runtime deployment errors.

Production checklist

Before publishing a template or issuing an asset, confirm:

• the required feature IDs match the intended asset behavior,
• conversion-minter is paired with conversion when conversion behavior is needed,
• transaction-fee and transaction-fee-accounting are not enabled together,
• base-price, fee-rate, metadata, collateral, and yield values use the accepted ranges for their field types,
• feature order is intentional because lifecycle hooks execute in the configured order,
• required feature factories are enabled in the target environment,
• any configurable settings that operators may edit during asset creation are explicitly marked editable on the template,
• the deployment target has the contracts and roles required to enforce the selected feature set.

For the operator workflow, see Instrument templates. For how features run during token operations, see Token Features.