System addons overview
System addons extend DALP environments with optional factories for settlement, distribution, income, fee, data, conversion, and infrastructure workflows.
System addons are Directory-registered factories for settlement, distribution, income, fee, data, conversion, and infrastructure workflows. Platform administrators own addon installation from Settings > Add-ons. Operators own the addon workspace actions that their roles permit, while asset, custody, compliance, and network controls stay with the systems that govern each submitted transaction.
Addon operating model
System addons are registered at the system level, not on each asset. The platform reads the on-chain Directory, enriches known addon types with UI categories and labels, and separates addon setup from day-to-day addon instances.
| Layer | What it controls | Reader action |
|---|---|---|
| Directory registration | Which addon types exist in the environment | Confirm the addon type is registered before installation |
| UI enrichment | Category, icon, label, hidden status, and feature grouping | Use the Add-ons settings filters to find the right addon family |
| System installation | Whether an addon factory is deployed for the platform | Install visible addon types with administrator permission |
| Addon workspace | Factory address, instance list, and addon-specific operations | Review instances and open detail pages for settlement, offering, or feature operations |
Scope and ownership
System addons add optional platform factories. They do not move ownership of the underlying asset, custody model, compliance rules, network operation, or treasury approval flow.
| Area | Owner | Out of scope for system addons |
|---|---|---|
| Addon registration | Platform environment and Directory configuration | Registering unsupported addon types or enabling hidden contract capabilities from the Add-ons installer |
| Addon installation | Platform administrator | Bypassing administrator permissions or installing an addon before Directory registration |
| Addon workspace actions | Authorized operator for the installed factory or instance | Changing token compliance rules, custody approvals, or network settlement finality |
| Asset and transaction controls | The relevant asset, compliance, custody, and network systems | Replacing KYC checks, custody-provider decisions, off-platform execution behaviour, reserve accounting, or legal approvals |
| Read-side visibility | Indexing and UI state for the environment | Guaranteeing immediate display of a factory or instance before the source transaction is indexed |
Available addon families
The current addon registry groups visible addon types into five functional categories. Vault is intentionally hidden from the Add-ons settings installer and remains a contract-level treasury capability.
| Family | Visible addon types | What they are for |
|---|---|---|
| Distribution | Push airdrop, vesting airdrop, time-bound airdrop, token sale, historical balances, voting power, permit | Token distribution, offering, holder-history, governance, and permit-related workflows |
| Income and fees | Fixed yield schedule, maturity redemption, transaction fee, transaction fee accounting, external transaction fee, fixed treasury yield, AUM fee | Yield, redemption, fee, and treasury-income behaviour for assets that need those controls |
| Exchange | XvP settlement, conversion, conversion minter | Asset exchange, settlement, and conversion workflows |
| Data | Scalar feed aggregator adapter, issuer-signed scalar feed, price resolver | Price, NAV, feed, and valuation data used by platform workflows |
| Infrastructure | Paymaster signer | Platform support for account abstraction gas sponsorship |
Vault boundary
Vault is a contract-level multi-signature treasury capability. It is not listed as a visible Add-ons settings installer. See the Vault architecture reference for its contract boundary, roles, and transaction lifecycle.
Feeds: platform settings and APIs
Feed-related addon types support data workflows. Feeds can also be reviewed from platform settings and managed through the feed APIs. See the Feeds developer guide for API-level feed operations.
Discovery and installation states
The Add-ons settings page separates addon types by current environment state.
| State in the UI | Source condition | What it means |
|---|---|---|
| Enabled add-ons | The system already has an installed factory for the addon type | Authorized users can open its workspace and use the supported workflows |
| Registered add-ons | The addon type is known to DALP and registered in the Directory, but not installed | An administrator can install the addon factory |
| Unregistered add-ons | The addon type is known to DALP, but not registered in the Directory for the environment | The addon cannot be installed until the environment registers it |
The Add-ons page also supports type and category filters. Type filters distinguish regular addons, token feature factories, and feed factories. Category filters group addon types by distribution, income and fees, exchange, data, and infrastructure.
Installation path
Administrators can install visible addon types from Settings > Add-ons. During system onboarding, DALP shows the system-addons step to administrators so they can choose platform add-ons before the environment is fully configured.
After installation, an addon factory becomes available through an addon workspace. That workspace gives operators the factory address, the instance list, and the detail page for supported instance types such as XvP settlements or token sales.
Production boundaries
System addons expose platform capabilities, but they do not replace the controls that govern each operation.
| Boundary | What to check before production |
|---|---|
| Access control | Administrator rights install addon factories. Contract roles and user permissions still decide which instance actions are available. |
| Registry state | A known addon type must be registered in the Directory before the UI can install it. |
| Instance configuration | Each settlement, sale, feed, fee, or feature instance keeps its own configuration and lifecycle. |
| Asset and compliance rules | Token rules, compliance checks, custody decisions, and network execution still apply to submitted transactions. |
| Read-side freshness | Addon workspaces depend on indexed state. Recently deployed factories or instances can take time to appear after the source transaction completes. |
Next steps
Install addons
Install visible addon types from the Add-ons settings page or during onboarding.
Review addon workspaces
Open an installed addon, review its instances, and move into settlement or offering detail pages.
Paymaster gas sponsorship
Review when the paymaster signer addon can sponsor EVM account abstraction transactions.
XvP settlement
Coordinate asset exchange workflows after the XvP settlement addon is installed.
Yield schedule
Review automated yield distribution for bonds and other yield-bearing assets.
Replace or remove a feed
Change the feed address for an existing subject and topic, or remove a feed registration from the Feeds Directory.
Install addons
Learn how to discover and install system addons from the on-chain Directory registry. The Add-ons settings page shows addon types that are visible for administrator installation.