A system, the set of DALP contracts an organisation runs on one network, creates assets and add-ons through factories, the contracts that deploy new instances of one type. Until a factory of a type is registered on the system, nothing of that type can be created there. Factories lists the token and add-on factories a system has and registers the ones it lacks.
A token factory deploys tokens. The “DALP asset” factory deploys every asset issued from an instrument template. The type-specific factories, such as “Bond”, “Equity” or “Fund”, serve existing assets of those legacy types. The sheet offers them for registration only when the platform operator has turned legacy asset creation on. An add-on factory deploys instances of one add-on type, such as an airdrop, a fixed yield schedule, an XvP settlement or a token feature.
The “Factories” page under “Infrastructure”.
The header carries the page description, the network chosen in the sidebar and Register factory, and reads “Every type this deployment can register already has a factory.” when no type is left to register. The table lists the factories with the columns “Name”, “Kind”, “Type” and “Address”, and “Kind” reads “Token” or “Add-on”.
Steps
Open Register factory
Choose Register factory in the page header. The sheet says “Requires the System manager role.” When every type the deployment can register already has a factory, “Register factory” cannot be selected and the header reads “Every type this deployment can register already has a factory.”
Choose the kind, type and name
- Choose the Kind, “Token” or “Add-on”.
- Pick a Type. The list offers only system directory types that have no factory yet, so a type never appears twice. While the platform runs with legacy asset creation off, it offers no legacy token type.
- Type a Name. The field notes “Current registries do not store the name. The factory list shows each factory under its type.” Only a version 1 registry stores it.
Review and register
Select “Review”. The confirmation step repeats the “Type” and the “Name”. Select Register, then confirm with your wallet verification in “Verification code”. The sheet reports “Token factory registered” or “Add-on factory registered”, and the row appears in the table.
Read the factory list
The page is one table of both kinds of factory, with the columns “Name”, “Kind”, “Type” and “Address”. “Kind” reads “Token” or “Add-on” and doubles as a filter. “Type” shows the name of the asset or add-on type in the language of the viewer.
The toolbar has Search factories… and the view options. The list refreshes as blocks arrive, so a factory registered a moment ago appears without a reload. A system with no factories says “No factories registered yet”. A failed read shows “The factories could not be loaded.” with “Check your connection and try again.” and a retry button, which reads both lists again.
The table does not open the add-on a factory created. Airdrops lists where each add-on type opens. A factory is one contract among the contracts a deployment runs, which EVM contract set lays out.
Where a missing factory shows
A missing factory shows in the Console in four places:
- Issue asset offers no instrument template while the system has no “DALP asset” factory, because every template deploys through it.
- The Classification step of the instrument template wizard warns “Deploy the Configurable Asset under Factories before creating templates.” The Configurable Asset in that warning is the “DALP asset” factory.
- Issue asset disables an instrument template, or a structure, when one of its features has no feature factory on the system. The row reads “Needs a feature factory”, and its details name the features and, for a system manager, offer “Open Factories”.
- Under Asset lifecycle in the sidebar, an airdrop family without a factory still appears. A system manager reads “Push airdrop is not deployed. Open Factories to deploy it.” and the entry opens Factories. Anyone else reads that a system manager deploys it in Factories.
In each case a system manager registers the missing factory on this page. When the sidebar points to Factories for a type the directory lacks, the Type list does not offer it and this page cannot register it.
Troubleshooting
Register factory cannot be selected
Every type this deployment can register already has a factory, and the header says so. If you expected another type, the network's system directory does not list it, so this page cannot register it.
The page reads Not available
Only a system manager sees Factories. Anyone without the System manager role who opens the address sees Not available inside the Console frame, and the page reads no factory data. Ask a system manager for the role.
The page reads Couldn't check access
The Console could not read your roles. Select Try again. If you lose the System manager role while the page is open, the header reads “Only a system manager registers factories.” and “Register factory” disappears.
The Type list is empty
The list offers only types of the network's system directory that have no factory yet. An empty list means every offered type is registered, or the network has no system directory.
API routes
A token factory is registered through POST /api/ and an add-on factory through POST /api/. A request from a browser session carries a wallet verification, which the Console collects for you. 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.
Registration is a transaction on the system, so by default the API answers 202 with a queued status and a status link, and the factory is usable once that transaction settles. Send Prefer: wait=N to hold the response until it settles, as Idempotency and async settlement explains.
An add-on request also registers the add-on types that the requested type depends on. A request whose types all have a factory already registers nothing and answers 200 with the system.
The platform refuses a registration in these cases: