System Version
A System Version is how far an organization's on-chain components have advanced against the current module set; migrating repoints those that fell behind.
A component's type id is shared by the Directory's own catalog row and by this organization's own addon registry row for that id. Migrating calls a function named setAddonImplementation on the organization's row to repoint it in place, catching it up to what the Directory currently expects. It never adds a second row for the same id, and the change reaches only this organization's already-deployed instances.
A component keeps one fixed type id across every version; a new implementation repoints the existing registry row instead of registering a second, competing entry.
The Console compares each component it displays against the current module set and reports one of three states: up to date, update available, or new.
Starting a migration takes system-manager or admin authority and runs as a signed background workflow. Validate the upgrade against representative chain state before production.
In Build and Early Access are a different axis entirely: a badge beside a page's title marking how settled its design or interface is, independent of any component's system-version status.
Staying current is a repoint, not a rebuild
An organization's on-chain system version is how far its deployed components have advanced against what the platform currently expects for them. That expectation lives in the Directory, the platform's own on-chain catalog, one per chain. The module set is the bundle of implementation addresses the Directory currently holds as current across every component type. A chain's implementations are locked in at deployment; the Directory's addresses keep advancing with fixes, new capabilities, and, over time, compliance features that graduate from optional to standard. A chain that never migrates keeps the exact behavior it deployed with, including any defect that has since been fixed upstream, and misses out on later capabilities without anyone deciding to skip them.
Because a component's identity in the registry does not change across versions, staying current is a repoint, not a rebuild. The organization is not re-deploying its system or asking counterparties to trust a new contract address; it is pointing the same, already-integrated component at newer logic.
Test how the new logic behaves against the organization's existing state. A fork test can expose compatibility problems that a fresh deployment would miss; it does not prove every possible execution path.
Starting a migration takes explicit authority, and a second request joins the run already underway
The Console's system-updates page is where an operator reads and starts a migration. It groups registered components (token factories, addons, compliance modules) and shows an update count badge on any group that has one or more components behind the current module set. Expanding a group lists each component with its status. Compliance modules are shown read-only with an explanatory note rather than an update control, since a compliance module's version is managed as part of a broader compliance posture decision, not a routine component bump.
Starting a migration requires system-manager or admin authority and a wallet verification step (for example a PIN code) before anything on-chain is signed, because the migration submits transactions from the organization's own signing wallet. If a migration is already running for the organization, meaning it is running, waiting on a step, or suspended, a second start request joins the run already in progress rather than starting a competing one. The Console shows the same live progress either way. The migration proceeds as a background workflow, so an operator can navigate away and come back to see it still running, waiting on a step, or finished.
A version bump repoints one registry row; it never creates a second
Each organization holds its own addon registry, a contract on its own chain that the migration repoints. The Directory is a separate, platform-owned catalog on the same chain; the organization's registry does not repoint the Directory, it repoints itself to match what the Directory currently expects. Every component the Directory tracks is addressed by a stable type id: for example, the settlement addon's id is the fixed hash of the string "xvp-settlement". Every implementation of that same addon declares that identical id, because the id names the slot in the registry, not a specific version of the logic behind it. Installing a component in an organization's registry for the first time calls a function named registerSystemAddon, which reverts if the organization already has that type id registered. Shipping a new version instead calls setAddonImplementation, which requires the organization to already have that id registered and overwrites the implementation address stored at that row.
The distinction matters operationally. A "new version" of a component is never a new registry entry; it is the same entry pointed somewhere else. Every instance the organization has already deployed through that row resolves its logic through the row on every call, so it is upgraded the moment the row changes, with no separate migration step per instance.
Comparing an organization's registry against the Directory's module set is an address comparison, not a semantic one. For each component, the platform reads the address the organization's registry currently has and compares it to the address the Directory currently expects. A component's status follows directly from that comparison, as the table below shows.
Factory-style addons carry a second, independent comparison. The factory contract's own registry row can be current while the instance implementation it deploys, the logic that already-created instances run, still lags behind, since the two can be updated separately. Only the type id ties them together as one addon.
| Status | What it means |
|---|---|
| Up to date | The organization's deployed address matches what the Directory expects, or the Directory has no expectation for this component yet. |
| Update available | An address is deployed, but it differs from what the Directory expects. |
| New | The Directory expects this component, but the organization has nothing deployed for it yet. |
A status check reports what to repoint, never what changed
A migration comparison call returns components grouped the same way the Console displays them, each carrying a status of up to date, update available, or new. A component's status alone tells you whether a repoint is available; it does not tell you what changed in the new implementation, since the comparison is address-level, not a semantic diff of behavior. Reading the actual implementation change is a source-level exercise against the module set's release notes or diff, not something the compare endpoint answers.
Starting the migration itself is not a single transaction. It runs as a durable background workflow keyed to the organization, so a client that starts a migration and loses its connection can reconnect and resume watching the same run rather than losing state or accidentally starting a second one. A retry after a failed attempt starts a fresh execution rather than resuming the failed one; only the running, waiting, and suspended states count as an existing run that a second start request can join.
A migration moves through running, waiting, and suspended on its way to finishing or failing; a retry after a failure starts an entirely new run rather than resuming the one that failed.
The workflow signs its on-chain calls with the organization's own submission signer, resolved per network and system, according to the configured custody path. A signer that cannot be resolved degrades specific steps, such as feed backfill, rather than failing the whole run outright.
Two further details shape what a migration actually touches. First, an organization can opt in to migrating components the Directory marks experimental; left at its default, the migration skips them and they stay visible as pending rather than being repointed silently. Second, a small set of components sync without ever appearing as a row in the comparison or in the Console: they still repoint, but a reader watching only the visible list will not see them move. Separately, when a factory-style addon does not support the interface a factory-instance update needs, that one factory's instance update is skipped rather than failing the run. The skip is recorded in the workflow's own log rather than surfaced on the Console.
Authorize and validate an upgrade before production
Starting a migration requires system-manager or default-admin authority on the organization. The selected signing path applies its verification and approval requirements. An authenticated API caller can also start the workflow when authorized.
Validate the selected module set against the deployment's current state before a production upgrade. A local chain fork can expose assumptions that a fresh test deployment would miss. The migration API checks authorization and starts the workflow; it does not run or verify a deployment-specific fork test for you.
Validation is an operational step before the authorized migration request. Retain the results with the change approval.
On-chain implementation-change events record which components changed. Combine them with the workflow outcome, initiating actor, and your change-approval evidence. The chain and workflow journal do not replace that approval record.
Two labels mark how far a capability or page has settled
Documentation can show an In Build or Early Access badge beside a page title. These describe the page or capability; they do not report the version of an organization's deployed contracts.
In Build
The page describes a design under review. Treat its routes, fields, and controls as provisional until the published status changes.
Early Access
The capability is available, but its interface can still change. Review release notes before upgrading an integration that depends on it.
The Experimental marker in the system-component list serves a separate purpose. It controls whether a migration includes components marked experimental. A documentation badge does not authorize that migration or establish a support commitment.
Frequently asked questions
Does migrating change a component's address that other systems integrate against?
No. A migration overwrites the implementation address stored at the registry row; the row's own address, and the address of anything already deployed through it, stays exactly where it was. A counterparty or integration that already has that address saved keeps the same address. Review behavior and interface compatibility before upgrading; a stable address does not guarantee unchanged behavior.
Can a chain skip a version and jump straight to the latest?
The comparison and repoint mechanism does not require passing through every intermediate version: an organization's registry compares its current address directly against what the Directory expects and repoints once. What a specific module set's implementation is allowed to assume about the prior version it replaces is a source-level concern for that implementation, not a limitation of the repoint mechanism itself.
Do you have to start a migration just to see whether a component has an update available?
No, and checking carries no authority requirement at all: comparing reads the organization's current on-chain state and needs only that the caller can see the organization, the same session check any read of the organization's data goes through. Only the separate start call signs transactions, and that call is the one that requires system-manager or admin authority, so checking status commits an organization to nothing and asks nothing of the caller's role.
EVM Contract Set
The EVM Contract Set is the identity, compliance, custody, and settlement contracts DALP deploys around one composable security token, checked in one call.
Overview
Hold, issue, operate, and report on digital assets, scoped to your account, the participant you act as, your organisation, or the platform as a whole.