Legacy asset families are no longer created by default
The seven original asset families can no longer be created on a new deployment because they carry an older identity model; issued tokens keep working.
New assets are designed from a template as a DALP asset. The seven original families that predate templates can no longer be created, because they use an older identity model that does not evaluate compliance claims. Nothing you already issued changes, and an operator who still issues them can enable legacy creation again.
What changed
Two operations now refuse a legacy family, meaning bond, equity, fund, stablecoin, deposit, real estate, or precious metal:
- Installing a token factory of that type on a system is refused with a
422. - Creating a token of that type is refused with a
400.
Both refusals name the type and point at DALP assets, which are the template-designed instruments the rest of the platform is built around.
Everything else about those tokens is untouched. An existing bond keeps minting, transferring, paying, and reporting exactly as before, and a system that already has a legacy factory installed keeps it.
Why the two operations move together
An asset cannot be created without a factory of its type, so allowing an install while refusing the create would leave an operator with a factory nothing can use. They are two halves of one capability and they switch together.
Turning it back on
A deployment that still issues legacy assets sets one flag:
FEATURE_LEGACY_ASSET_CREATION=trueIn the DALP Helm chart the value is global.dalpApp.config.features.legacyAssetCreation; it defaults to ${FEATURE_LEGACY_ASSET_CREATION:-false}, so either set the value to true or set the environment variable on the pods. It is deployment-wide: every organisation on that install may create legacy assets while it is on. Understand what it restores. Those seven families use the older identity model, which does not evaluate identity claims the way a template-designed DALP asset does.
After enabling creation, a newly created organisation still comes up with only the DALP asset factory installed. Install the legacy factories you need on that organisation's system through the Platform API before creating a legacy token there.
Compatibility
One additive change: the public settings response gains a features.legacyAssetCreation boolean, so a client can hide legacy options a deployment has not enabled. No other route, request, or response shape changes. The two refusals are new rejections on existing routes, and they only reach an integration that creates a legacy family on a deployment that has not opted in.
The two refusals are not equally identifiable. The install refusal carries its own error code, TOKEN_FACTORY_TYPE_DEPRECATED, so a client can branch on it directly. The create refusal does not: it arrives on the code that every terminal token-creation failure shares, and only the message names the family. A client that needs to tell this case apart reads features.legacyAssetCreation from the settings response before it offers a legacy family, rather than classifying the failure after the fact.
Design an asset from a template → · Understand on-chain identity →
Response caching
Read responses carry a version tag, so a client can ask whether anything changed instead of fetching the payload, and read-your-write moved into the platform.
Documentation in the Console
Console screens that use a term of art now link to the page that defines it, so a reader meeting collateral or a record date can read what it means in place.