Upgrade the organisation's system components in the DALP Console

System updates compares the contracts of the organisation's system with the release directory of the selected network and upgrades the ones that are behind. The release directory is the on-chain list of the contract versions in the latest DALP release, and the platform operator sets one for each network. The organisation chooses only whether and when to run the upgrade. The page applies to the system as a whole and has no per-token setting. System Version explains how a component falls behind and what an upgrade changes.

Upgrading the platform itself is a separate task: the platform operator runs it with Helm, as Upgrades and migrations describes. System contracts, registries, factories and tokens stay on the versions they run until a System updates run upgrades them. Identity contracts do not: they take their code from the platform's shared identity factory, so when the platform operator registers a new identity implementation, every identity on that network, the organisation identity included, runs it from the next call.

System updates page with the Release status figures, the Upgrade button and the components table — The “System updates” page under “Infrastructure”.

The “Release status” strip shows “Need an upgrade”, “Up to date”, “Tokens affected” and “Not verified”, the title row carries the Upgrade button, and the components table lists “Component”, “State”, “Tokens affected” and “Area”.

Before you start

Hold the Permission manager or System manager role on the system, on the wallet you sign with. The Roles and permissions screen calls the first role Permission manager. The You can't view System updates card lists it as Admin. Only an account that holds one of them sees the sidebar entry and the page.
Select the network whose system you want to upgrade. The page follows the network selected in the account menu's Network submenu and shows the network under the title as “On” followed by the network name.
Use a signing wallet that holds a management key on the organisation identity, the on-chain identity contract of the organisation. The run writes to that identity, and those writes fail without a management key, so the platform checks the key before it starts the run.
Have your wallet verification ready: your transaction PIN, or your transaction code when your account has an authenticator.

Steps

Read the figures and the table

The Release status strip counts the components that “Need an upgrade”, how many verified components are “Up to date” out of all components, the “Tokens affected” that “Move to a new version”, and the components that are “Not verified”.

The system and release directory addresses sit in a collapsed Contract addresses section. The table lists each component. Component states explains what each state means.

Select Upgrade

The Upgrade button on the title row names how many components it upgrades, for example “Upgrade 3 components”. Select it. When you cannot, the reason shows next to the button: Why Upgrade is unavailable lists the reasons.

Confirm in the sheet

The sheet is titled “Upgrade 3 components?” and reads “Upgrades them to the latest DALP release.” It lists the components under What the upgrade changes, marks a component the run installs with “Installs new”, and counts the tokens that move.

The count on the button also includes internal data steps that have no row, and a line such as “2 more internal data steps are included.” counts them. A line starting “Not included:” names the components left out and why.

Read the consequence. Every change is written to the network and cannot be undone. If a later step fails, the steps already applied stay. When tokens move their stored data to the new version, that step cannot be interrupted once it starts.

The sheet also says which wallet case applies: “Your organisation keeps standard wallets. The upgrade prepares Advanced accounts infrastructure but does not switch any wallet.” or “Your organisation stays on Advanced accounts. The upgrade brings its Advanced accounts infrastructure up to date.” The switch to smart wallets belongs to the Wallet type row of Transaction funding.

On an organisation on Advanced accounts, the run also grants each smart wallet the system and token roles that its custody account's signing wallet holds, and registers the smart wallet under the member's identity. A member has one smart wallet per network.

When none of a member's custody accounts is registered, the run moves the roles of the custody account that controls that smart wallet, or, before it exists, of their primary custody account, or of their only one once it is active. Any other unregistered custody account keeps its roles on its own signing wallet, and the run moves nothing for it.

When none of a member's custody accounts is registered and their identity is registered only on another wallet of theirs that no custody account holds, the run registers the member's smart wallet under that identity.

When those other wallets hold more than one identity, the run registers that smart wallet under none of them, finishes its other steps, and then fails with an error that names the participant and the identities. Have an identity manager remove the wrong registration with Remove registration on the participant's page, then run the upgrade again.

Type the organisation's name in the confirmation field, which reads “Type” followed by the name and “to confirm this applies to your organisation”, then select Upgrade 3 components at the bottom of the sheet. “Keep current versions” closes the sheet and changes nothing.

Upgrades that touch custodied tokens

When a custodian organisation holds tokens that a factory deployed, the run refuses to upgrade that factory until an upgrade was scheduled for it and its notice period has ended. The run stops and states when the upgrade may run, or that none was scheduled. The system's organisation schedules the upgrade through the Platform API, and an emergency upgrade skips the wait. Custodian watch explains the notice and who receives it.

Verify the upgrade

Confirm with your wallet verification: your transaction PIN, or your transaction code when your account has an authenticator. The sheet asks for it once. A toast reads The upgrade started, and the progress card takes the place of the figure strip.

Follow the progress

The progress card replaces the figure strip while the upgrade runs. Its title and status line tell you where the run is:

Title and status line	Meaning and controls
“Upgrade in progress”, “Starting the upgrade…”	The run has started and its step list is loading.
“Upgrade in progress”, a line that starts “Every stage runs in order”	The step list follows the step that runs. A stage with nothing to change finishes at once, and you can leave the page.
“Upgrade in progress”, “Connection lost, reconnecting. The upgrade keeps running.”	The live view dropped and reconnects on its own. The run continues on the platform.
“Upgrade in progress”, “We lost the live view of this upgrade. It may still be running.”	The live view ended without a result. Reload progress reads the run again, and Dismiss hides the card.
“Upgrade complete”, “The upgrade finished. Your organisation still uses standard wallets.”	Every step succeeded. The line ends “Your organisation stays on Advanced accounts.” for an organisation on Advanced accounts. Done returns to the summary and reloads the comparison.
“Upgrade stopped”, the step and “stopped”	A step failed. The card reads “The steps before it stay applied. Try again continues from this step.”, shows the error and an error reference, and offers Try again and Dismiss.

Reload the page while the upgrade runs and the running upgrade comes back, and Upgrade stays unavailable with “An upgrade is already running.”

After a failure, Try again reopens the sheet. The new run continues from the failed step, because the steps before it stay applied and finish at once. “Dismiss” hides the failure. A failed run does not reappear after a reload, and the table shows what is still pending. The page does not show the result of a finished run after a reload. Only an upgrade in flight is read back.

Read a component's details

Select a component's name to open its detail sheet. It has these sections:

Summary shows the “State”, the “Identifier”, “What it does”, the “Change”, “Why” and the “Area”. For a global compliance module replacement, the “Change” reads “Replaces a retired version. Your rules stay as they are.”
Factory and “Token versions” appear for token factories and per-token components. A version the platform could not read shows “Could not be read”.
Versions shows “Running now” and “Latest release”.
A component the run leaves out because your signing wallet lacks the compliance manager role reads “Your signing wallet does not hold the compliance manager role. Ask a compliance manager to run System updates, or switch to a wallet that holds the role.” with an Open Roles and permissions button.

The organisation wallets row adds an Organisation wallets section that lists each wallet and why it is held back: “Not registered under the organisation identity.”, “Its registration awaits acceptance.” or “Registered under another identity.” Wallets the upgrade creates itself show under “Not created yet”, and the “Deploying admin” line says when the upgrade has no country to register them with. An identity manager fixes each case in the Console: registering the deploying admin with a country or changing its country under Participants › Users, accepting a pending registration under Participants › Entities, or removing a registration from the holder's page.

Component states

The components table has the columns “Component”, “State”, “Tokens affected” and “Area”. A row also carries a “Global” or “Experimental” badge where it applies, and a reason line under the name. Each row has one of these states:

State	Meaning
Upgrade available	The release directory holds a newer version of an installed component.
Not installed	The release directory has a component the system does not have. The run installs it.
Needs compliance manager	A global compliance module replaces a retired version, and that replacement needs the compliance manager role on the signing wallet. The run leaves it out.
Not verified	The platform could not read the version of the component's tokens. For the organisation wallets row, the system has no organisation identity indexed. Neither case means an upgrade is available.
Up to date	The deployed component matches the release directory.

The State filter hides up-to-date rows when the page opens. Remove the chip to see every row. With every row hidden the table reads “Every component is up to date” and “Remove the State filter to see all 12 components.” with the real count. When a search matches nothing it reads “No components match”.

“Search components” narrows the table by name, and the Area filter narrows it by group: “Core system”, “Identity”, “Token infrastructure”, “Compliance”, “Registries”, “Token factories”, “Add-ons”, “Pricing”, “Compliance modules”, “Advanced accounts” and “Reporting”.

Experimental components stay out of a run unless you switch on Include experimental, which also asks for the comparison again.

Why Upgrade is unavailable

Reason shown	What it means
“Checking the release directory…” or “Refreshing the comparison…”	The comparison is loading. Wait for it.
“An upgrade is already running.”	A run is in flight for this system. Follow it on the page.
“The remaining upgrades need the compliance manager role on your signing wallet.”	Only global compliance module replacements are left. Sign with a wallet that holds that role.
“Only experimental upgrades are left. Switch on Include experimental to add them.”	Only experimental components are pending.
“Nothing to upgrade, but 2 components could not be verified.”	No upgrade is pending, and the versions of some components could not be read.
“Every component runs the latest release.”	The system matches the release directory.

Troubleshooting

The page says you can't view System updates

Your account holds neither the Permission manager role (shown as Admin on that card) nor the System manager role on this system. Ask a member who holds one of those roles to run the upgrade.

The page says your roles could not be read

The Console could not read your roles. The page reads “Your roles could not be read” and “Check your connection and try again.” Select the retry button.

The page says your role is on another wallet

One of your other wallets holds the role. The page names that wallet. Switch to it and open the page again.

The page says there is nothing to upgrade on this network, or no release directory

Nothing to upgrade on this network means the organisation has no system on the selected network. An organisation owner deploys one from Networks, and “Open Networks” takes you there. A title that says the network has no release directory means the platform operator has not set one for that network, so nothing can be compared or upgraded.

The comparison could not be loaded

The network did not answer, so the versions could not be compared. Nothing was changed. Select Try again on the error card.

The upgrade did not start after the verification

The sheet shows the reason and an error reference, and nothing is written to the network. A signing wallet without a management key on the organisation identity is refused with DALP-14328. Switch to a wallet that holds the key. After a recent change to your wallet security, signing is held for a cooling-off period. Wait until it ends and start again.

The upgrade stopped partway

The failed step, its error and an error reference stay on the page. Fix the cause the error names, then select Try again. Steps that already finished stay applied.

API routes

The page calls these four routes of the Platform API, and each one answers 403 to a caller without the Permission manager or System manager role:

GET /api/v2/system/migration-comparison returns the comparison. Add includeExperimental=true to count experimental components.
POST /api/v2/system/migrations starts a run, with an optional includeExperimental in the body. A browser session sends walletVerification in the body. A request from an API key sends none and is refused only while the key holder is in the cooling-off period after a wallet security change. A new run answers 202 with its migrationId. When a run is already in flight, or you repeat a request with the same Idempotency-Key, the platform answers 200 with the existing run and starts nothing.
GET /api/v2/system/migrations/{migrationId}/stream streams the progress of a run in your organisation. A request from a browser session must show that it comes from the same origin as the Console, through its Sec-Fetch-Site, Origin or Referer header. Without that evidence the stream answers 403. A request from an API key needs no such evidence.
GET /api/v2/system/migrations/active returns the run in flight, or nothing.

The Platform API reference lists the first three routes.