# Overview

Source: https://docs.settlemint.com/docs/architects/components/capabilities
Capabilities are optional system addons for asset operations. They add focused
workflows for 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 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](/docs/architecture/concepts/claims-and-identity). Asset rules are defined in the [asset policy model](/docs/architecture/concepts/asset-policy).

## How capabilities fit [#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.

<Mermaid
  chart="`flowchart TB
  Operator[Operator or application]
  Platform[DALP platform services<br/>API, CLI, Console]
  Asset[Governed asset contract<br/>roles, claims, compliance checks]
  Subject[Workflow subject<br/>data subject]

  subgraph Capabilities[Capability instances]
    XvP[XvP settlement<br/>atomic exchange]
    Feed[Issuer-signed scalar feed<br/>signed value updates]
  end

  Operator --> Platform
  Platform --> XvP
  Platform --> Feed
  XvP --> Asset
  Feed --> Subject

`"
/>

## What each addon owns [#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                                                                          |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Settle token legs atomically between parties | [XvP Settlement](/docs/architects/components/capabilities/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       |
| Publish issuer-signed numeric values         | [Issuer-Signed Scalar Feed](/docs/architects/components/capabilities/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 [#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 [#choose-the-right-capability]

Start from the workflow outcome, not from the contract name.

| If the operating question is...                                     | Start with...                                                                                   |
| ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| How can two or more parties settle local token legs atomically?     | [XvP Settlement](/docs/architects/components/capabilities/xvp-settlement)                       |
| How can a trusted issuer publish signed numeric values for a topic? | [Issuer-Signed Scalar Feed](/docs/architects/components/capabilities/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 [#next-pages-by-review-question]

* Atomic token-leg settlement: [XvP Settlement](/docs/architects/components/capabilities/xvp-settlement).
* Issuer-attested numeric data: [Issuer-Signed Scalar Feed](/docs/architects/components/capabilities/issuer-signed-scalar-feed).

Security and compliance reviews should pair the relevant capability page with [SMART Protocol integration (ERC-3643)](/docs/architects/components/asset-contracts/smart-protocol-integration) and the [infrastructure reference](/docs/architects/components/infrastructure). Those pages cover the transfer checks and services each addon relies on.

## Related [#related]

* [Component catalog](/docs/architects/components) for the full platform inventory
* [Asset contracts overview](/docs/architects/components/asset-contracts) for the base token layer
* [SMART Protocol integration (ERC-3643)](/docs/architects/components/asset-contracts/smart-protocol-integration) for the compliance framework
* [Infrastructure layer](/docs/architects/components/infrastructure) for the services each addon depends on
* [Key flows](/docs/architects/flows) for end-to-end sequences involving capabilities