Skip to main content

Networks

Turn on multi-network support for an organisation, add networks from the platform catalogue, follow each network's deployment, and create its bundler wallet.
Open it fromInfrastructureNetworksRoles:OwnerPlatform administratorConsole address: /org-settings/networks

Networks lets an organisation work on more than one network. An owner turns on multi-network support, adds a network from the platform's catalogue, and the platform deploys the organisation's system on that network and shows its progress. A platform administrator curates the catalogue and its node connections for the DALP Instance on Platform networks.

Every organisation starts with one network. Onboarding offers a choice when a platform administrator has turned on Offer network choice at onboarding, and otherwise starts the organisation on the default network. That first network is the organisation's default network and does not change.

The organisation holds one system per network: the registries, permissions and compliance rules it deploys there. Members and organisation settings stay shared across all of its networks.

On-chain roles do not: the deployment grants the Permission manager, System manager, Asset manager, Compliance manager, Verification policy manager, Identity manager and Verification issuer roles on the new system to the wallets of the person who added the network, and every other member's roles there are granted on Roles and permissions.

Turning on multi-network support does not deploy anything. Adding a network starts a deployment.

The “Networks” heading with the “Add network” button, the “Multi-network support” row with its value and its “Turn on” or “Turn off” button, and the “Your networks” table listing each network with its status, chain ID and bundler wallet.

Steps

Turn on multi-network support

On the “Multi-network support” row, which reads “Deploy your organisation to networks beyond its default network.”, select Turn on. The change applies at once, the Console confirms “Multi-network support turned on”, and the toast offers “Undo” for a few seconds. A later change to the setting, including “Undo”, replaces that toast, so only the latest outcome shows. Until support is on, the page reads “Turn on multi-network support first.” under the title, and “Add network” stays disabled.

Add a network

Adding a network starts the deployment at once, and there is no draft to come back to. Select Add network. The “Add a network” dialog reads “Choose a network enabled for this deployment. Deployment starts immediately and you can watch its progress here.” Choose a network in “Network”, which opens as “Select a network”, then select “Add network”. The Console confirms “Network deployment started”.

The picker lists the enabled catalogue networks the organisation has not added, other than its default network, for which you have a way to sign. When it lists none, the dialog reads “No additional networks available yet” and “Only networks your current custody coverage supports can be added.” A hint under the field reads “Networks need an eligible custody account or a healthy managed provider. Add network coverage in Custody.” and links to Custody.

The new system uses the organisation's stored default currency, currencies and wallet kind. An owner sets who pays gas on that network on Transaction funding.

Follow the deployment

A network moves from “Pending” to “Deploying” to “Active”. While it deploys, a panel before the table shows its steps. The deployment runs on the server, so leaving the page does not stop it, and the page shows the reached state when you come back. Network states shows the path.

Only one network deployment runs at a time for an organisation. Wait for it to finish before you add another.

Retry a failed deployment

When a deployment does not finish, the row reads “Failed”, and a notice before the table reads “Deployment to” and the network's name and “failed”. Its description is the failure reason, or “The deployment did not finish. Open the row for the steps that failed.” when there is none. Open the row to see the steps that failed. Select Try again on the notice. The retry starts a new attempt for that network, which returns the row to “Pending”. It is refused like an add while another network deployment runs.

Create the bundler wallet

The bundler wallet submits smart-account requests on a network. The deployment creates it, and its address shows in the “Bundler wallet” column once the network is “Active”. When an active row has no bundler wallet, owners and platform administrators see Create bundler wallet on it.

Selecting it creates the wallet, or reuses the one that exists, and the row then reads “Bundler wallet created” or “Bundler wallet already exists”. It also reports the funding state: “The wallet is funded.” or “The wallet needs funds. A funding request is open.” On a network that charges gas, a balance below the wallet's top-up level opens a funding request for that level, which you settle on Transaction funding. The level comes from the network's live fee quote. When the network has no fresh fee quote, or the request cannot be recorded, the action fails and you can select it again later.

Creating it needs your wallet to hold the “Permission manager” role on that network's system. A refusal shows “Bundler wallet not created” with the reason, such as “Account abstraction is turned off for this deployment.”

Turn off multi-network support

Select Turn off on the “Multi-network support” row. The organisation then works on its default network only. While any network other than the default is “Pending”, “Deploying” or “Active”, the button is disabled and the row says which network keeps support on. An “Active” network reads, for example, “local2 is added and in use, so multi-network support stays on. Turning it off first needs that network removed, and removing a network is not available yet.”

When every blocking network is still “Pending” or “Deploying”, the row reads, for example, “local2 is still being added, so multi-network support stays on. Turn off becomes available once that network finishes deploying or fails.” When both kinds block, the row names only the active networks. The server refuses the change with DALP-9169, naming the networks that block it. A “Failed” or “Disabled” network does not block it. This page has no control to remove a network once it is added, so an active added network keeps support on.

Read a network's details

The Your networks table has the columns “Network”, “Status”, “Chain ID” and “Bundler wallet”. The default network is marked “Default” beside its name. The toolbar has “Search networks…”, a “Status” filter with “Active”, “Pending”, “Deploying”, “Failed” and “Disabled”, and the view options. An empty table reads “No networks yet”. A failed read reads “The networks could not be loaded.” with “Check your connection and try again.”

Open a row to see its facts: “System”, the system address, “Native currency”, and “Explorer”, a link to the explorer's host. A network with none of these reads “No more details for this network yet”. A “Failed” row opens the deployment steps instead.

Network states

How an added network moves through its statesAdding a network starts it at Pending. It moves to Deploying and then to Active when the deployment finishes. A deployment that does not finish moves the network to Failed. Try again on a failed network starts a new attempt at Pending. Pending, Deploying and Active networks other than the default block turning multi-network support off. A failed network does not.How an added network moves through its statesAdding a network starts it at Pending. It moves to Deploying and then to Active when the deployment finishes. A deployment that does not finish moves the network to Failed. Try again on a failed network starts a new attempt at Pending. Pending, Deploying and Active networks other than the default block turning multi-network support off. A failed network does not.

An added network moves from “Pending” to “Deploying” to “Active”, and “Try again” restarts a “Failed” one at “Pending”.

Stay on one network or use several

Stay on one network

Assets deploy on one network, and there is one set of transaction history to reconcile. Choose this when every participant uses the same network.

Turn on multi-network support

The organisation adds systems on further networks, and members switch the network the Console works on. Each asset lives on the network where it was issued, and the organisation tracks activity on each network separately. Choose this when participants need different networks.

Two switches with similar names

Two separate settings decide whether an organisation can use more than one network. Their names differ only in letter case. Setting one does not set the other.

Switch
Scope
Who sets it
What it gates
multi_network_enabled
The whole platform. Read as meta.onboardingNetworkChoice at GET /api/v2/admin/networks.
A platform administrator, with the Offer network choice at onboarding switch on Platform networks.
The network that a new organisation's first system can deploy to. When the setting is off, a new organisation can deploy only on the platform default network.
MULTI_NETWORK_ENABLED
One organisation. Read at GET /api/v2/settings/MULTI_NETWORK_ENABLED.
An organisation owner or a platform administrator, when they select Turn on here.
Everything after onboarding: the Add network action, the Network submenu in each member's account menu, and requests that name a non-default network.

The platform setting decides which networks the platform lets an organisation start on. The organisation switch decides whether that organisation adds and uses networks beyond its default.

Set them in this order

  1. Set the platform setting first, and only if the first system of a new organisation must deploy to a network that is not the platform default. A platform administrator turns on Offer network choice at onboarding on “Platform networks” before that organisation completes onboarding.
  2. Complete onboarding. The organisation picks its first network, and that network becomes its default.
  3. Set the organisation switch after onboarding. An owner or a platform administrator selects Turn on in the “Multi-network support” row. Then add each further network with “Add network”.

Skip step 1 when the organisation starts on the platform default network. Adding a network after onboarding needs only the organisation switch. The platform setting never replaces step 3.

Troubleshooting

The page shows Off, although the platform offers a network choice at onboarding

The platform setting multi_network_enabled and the organisation setting MULTI_NETWORK_ENABLED are separate. The organisation setting stays off until an owner or a platform administrator selects Turn on. Read it at GET /api/v2/settings/MULTI_NETWORK_ENABLED to see the value for the active organisation.

A network is missing from the picker

The picker lists only enabled catalogue networks that the organisation has not added and that you can sign on. Ask a platform administrator to confirm the network is enabled on Platform networks. If it is, check custody coverage: the picker needs an active, eligible primary managed custody account of yours on that network, or a healthy managed custody provider of the organisation that covers it.

The dialog refuses to add a network

The dialog shows one of four messages:

  • “This network is already part of your organisation.” covers a network the organisation has added, including a row that reads “Disabled”.
  • “This network is still being set up. Wait for the deployment to finish, then check its status.” means its setup is “Pending” or “Deploying”.
  • “This is your organisation's default network and cannot be added again.” names the default network.
  • “This network is not enabled for your deployment. Choose another network.” means the platform catalogue does not offer it.

The server returns DALP-14111 with the network and a reason: already-added, deploying, default-network or not-enabled.

Adding a network is refused because another deployment is running

Only one network deployment runs at a time per organisation. The server refuses a second one with DALP-14357. Wait for the running deployment to reach “Active” or “Failed”, then add the network.

Adding a network is refused because no custody provider covers it

The server refuses with DALP-14069 when you hold no usable managed account on the network and no healthy managed custody provider of the organisation covers it. The dialog reads No custody provider can open an account on this network. under the Custody hint. On Custody, add the network's EVM chain ID to a provider, enable account creation, or restore the provider's health, then add the network again. Adding coverage keeps the provider's existing networks.

Adding a network is refused because the network has no system factory

The network is in the catalogue, but the contract that creates an organisation's system is not deployed on it. The server refuses with DALP-14308. Ask a platform administrator to prepare the network.

Adding a network is refused because your account cannot sign there

Your custody account on that network cannot send the deployment, for example because it no longer exists. The server refuses with DALP-14321. Check your custody account and the organisation's provider for that network, then add it again.

A member cannot select a network you added

The Network submenu of the account menu shows only when multi-network support is on and the organisation has more than one active network. Check that the added network reads Active. A network that is “Pending”, “Deploying” or “Failed” is not offered.

Frequently asked questions

Does turning multi-network support on or off change the default network?

No. The default network is fixed at onboarding. Turning support on adds networks next to it, and turning it off limits the organisation to the default network.

Can I remove a network once it is added?

No. This page has no control to remove a network. Try again on a failed network starts a new deployment attempt for that same network. A platform administrator manages which networks the platform offers on Platform networks.

API routes

Over the API, a request names its network in the X-Chain-Id header. A request without the header acts on the organisation's default network. A header that is not a whole number in range is refused with DALP-9084, CHAIN_ID_HEADER_INVALID. A request for a network the organisation cannot use is refused with the reason, never sent to another network:

  • With multi-network support off, a request for any network other than the default is refused with DALP-9085, CHAIN_NOT_AVAILABLE_FOR_ORGANIZATION.
  • A request for an added network whose status is anything other than Active is refused with DALP-9086, CHAIN_NOT_READY, which carries the network's status.
  • A request for a network the organisation has not added is refused with DALP-9085.

An organisation that existed before multi-network support keeps its system as its default network. Nothing changes for it until an owner turns support on. The organisation switch is read at GET /api/v2/settings/MULTI_NETWORK_ENABLED, and the platform setting at GET /api/v2/admin/networks, as meta.onboardingNetworkChoice.

Was this page helpful?