Overview
Capabilities are optional system addons for asset operations. They add focused workflows for token distribution, treasury control, settlement, primary sales, and issuer-signed market data without putting every workflow into an asset contract.
Capabilities are workflow contracts deployed next to a governed asset or another operational subject. Capability contracts handle distribution, treasury approvals, exchange-versus-payment settlement, primary sales, and issuer-signed data publication without moving every control into the base asset contract.
Asset contracts own identity, compliance checks, roles, and token behaviour when a capability moves or allocates regulated tokens. Other capabilities own standalone workflow state, such as treasury approvals or issuer-signed subject data, without changing the base asset contract.
The deploying operator owns each capability instance and assigns the role holders or participants for that workflow. Identity, claim topics, and trusted issuers are defined in the claims and identity model. Asset rules are defined in the asset policy model.
How capabilities fit
Capabilities sit beside the asset-contract layer or a non-token workflow subject. Each capability instance is deployed through a factory and keeps its own on-chain state, so one airdrop, vault, settlement, token sale, or price feed does not share state with another instance. DALP routes execution through platform services where an API, CLI, or Asset Console workflow is available, while the capability contract enforces the workflow state on-chain.
What each addon owns
Each addon owns one operational workflow. Asset contracts own the base token model, role setup, identity registry, compliance modules, and instrument profile.
| Task | Page | Capability ownership | Outside the capability |
|---|---|---|---|
| Distribute tokens to eligible recipients | Airdrop | Time-bound, vesting, or push distribution state, Merkle proof validation, claim tracking, and owner withdrawal | Token issuance, recipient identity setup, and off-chain Merkle tree generation |
| Control treasury movements with signer approvals | Vault | Proposals, confirmations, revocations, execution, pause, signer roles, and configurable thresholds | Token issuance, investor identity, and compliance verification |
| Settle token legs atomically between parties | XvP Settlement | Local flow definitions, sender approvals, expiration, hashlock reveal, cancellation requests, and all-or-nothing local execution | Price discovery, order matching, external-chain execution, and upstream compliance checks |
| Run a primary token offering | Token Sale (DAIO) | Sale timing, accepted payment currencies, buyer eligibility checks, purchase records, finalisation, refunds, vesting, and token withdrawal | Secondary trading, lifecycle servicing after the sale, and broader asset policy design |
| Publish issuer-signed numeric values | Issuer-Signed Scalar Feed | Signed value submission, signer verification, history mode, drift checks, fixed-point precision, and feed discovery | External price formation, external oracle operation, and the business decision behind the value |
Operating model
Capabilities follow the same high-level model, but they do not expose the same workflow.
| Operating question | Capability answer |
|---|---|
| Deployment | A factory creates a dedicated capability instance for the asset or workflow. |
| State ownership | The deployed instance owns workflow state, such as claims, approvals, sale status, settlement flows, or signed feed rounds. |
| Post-deployment changes | The relevant role holder or participant changes only allowed fields. Some configuration is immutable after creation. |
| When do compliance checks apply? | Token transfers still rely on the underlying asset and SMART Protocol compliance path when the capability moves or allocates regulated tokens. |
| What events can auditors inspect? | Contracts emit events for proposals, confirmations, claims, purchases, settlement actions, and feed updates. DALP services can index those events for APIs and operator surfaces. |
Choose the right capability
Start from the workflow outcome, not from the contract name.
| If the operating question is... | Start with... |
|---|---|
| How can an issuer distribute an already funded token allocation? | Airdrop |
| How can a treasury require signer approval before funds move? | Vault |
| How can two or more parties settle local token legs atomically? | XvP Settlement |
| How can eligible buyers participate in a primary token offering? | Token Sale (DAIO) |
| How can a trusted issuer publish signed numeric values for a topic? | Issuer-Signed Scalar Feed |
Use the asset lifecycle, identity, and policy pages first for token creation, investor onboarding, claim topics, trusted issuers, or transfer restrictions.
Use a capability page when the token or workflow subject already exists and the question is about the extra operation DALP runs around it.
Next pages by review question
- Distribution ownership: Airdrop.
- Treasury approval control: Vault.
- Atomic token-leg settlement: XvP Settlement.
- Primary buyer participation: Token Sale (DAIO).
- Issuer-attested numeric data: Issuer-Signed Scalar Feed.
Security and compliance reviews should pair the relevant capability page with SMART Protocol integration (ERC-3643) and the infrastructure layer. Those pages explain the transfer checks and execution services around each addon.
Related
- Component catalog for the full platform inventory
- Asset contracts overview for the base token layer capabilities build around
- SMART Protocol integration (ERC-3643) for the compliance framework capabilities build on
- Infrastructure layer for the services capabilities depend on
- Key flows for end-to-end operation sequences involving capabilities
Conversion
Convertible instrument pair for DALPAsset - Conversion (loan-side) and Conversion Minter (equity-side). Manages trigger types, executes holder-initiated and forced conversions, and coordinates cross-token burns and mints.
Airdrop
The Airdrop capability distributes funded tokens to eligible wallets through time-bound, vesting, or push strategies. Each strategy uses a Merkle root for eligibility and records claims on-chain so recipients cannot claim more than their allocation.