Overview
Capabilities are optional system addons for asset operations. They add focused workflows for orderbook trading, atomic settlement, and issuer-signed market data without putting every workflow into an asset contract.
Capabilities are contracts you deploy next to a governed asset or another operational subject. They handle orderbook trading, exchange-versus-payment settlement, and issuer-signed data feeds without moving every control into the base asset contract. Asset contracts own the token model, compliance checks, roles, and identity when a capability moves regulated tokens. Other capabilities own standalone workflow state without changing the base asset contract.
When you deploy a capability, you assign the role holders or participants for that workflow. 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
Each deployed capability sits beside the asset-contract layer or a non-token workflow subject. A factory deploys a dedicated contract instance that keeps its own on-chain state, so one settlement flow or price feed does not share state with another. You interact with them through the API, CLI, or Console; each contract enforces workflow state on-chain.
What each addon owns
Each addon owns one operational workflow. Asset contracts own the base token model, role setup, the identity registry, compliance modules, and the instrument profile.
| Task | Page | Capability ownership | Outside the capability |
|---|---|---|---|
| Trade listed token pairs on an orderbook | Trading Venue | Market listing, order intake, matching, reserved balances, fills, fees, and market halts | Fiat cash rails, broker or exchange legal role, and off-platform consent workflows |
| 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 |
| Distribute new tokens in a primary offering | Token Sale | Sale lifecycle, multi-currency pricing, presale whitelist, vesting, soft cap, refunds, and identity-gated eligibility | Secondary market trading, ongoing compliance monitoring, and asset servicing after the sale |
| 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 operations.
| 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 operations, 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 participants trade listed token pairs on an orderbook? | Trading Venue |
| How can two or more parties settle local token legs atomically? | XvP Settlement |
| How can an issuer distribute new tokens in a compliant offering? | Token Sale |
| 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 task concerns the extra operation the platform runs around it.
Next pages by review question
- Orderbook secondary trading: Trading Venue.
- Atomic token-leg settlement: XvP Settlement.
- Compliant primary distribution: Token Sale.
- 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 reference. Those pages cover the transfer checks and services each addon relies on.
Related
- Component catalog for the full platform inventory
- Asset contracts overview for the base token layer
- SMART Protocol integration (ERC-3643) for the compliance framework
- Infrastructure layer for the services each addon depends on
- Key flows for end-to-end sequences involving capabilities
Conversion feature for convertible instruments
How DALP models convertible instruments with a loan-side Conversion feature and target-side Conversion Minter feature, including how accrued interest settles on a full conversion.
Trading Venue for on-platform secondary trading
The Trading Venue capability provides a permissioned central limit orderbook per deployment: identity-registered participants trade listed platform token pairs with non-custodial reservation, deterministic matching, and failure-isolated on-chain settlement.