Upgrade your platform from the on-chain directory
System updates compares your deployed components against the on-chain directory and upgrades every out-of-date implementation in one guided run, with addresses and balances preserved.
The on-chain directory is the source of truth for the latest version of every platform contract. System updates compares your deployment against it, shows which components are behind, and upgrades them all in one guided, on-chain run. You run it, and every address stays put.
A platform upgrade used to mean a coordination call: schedule a window, wait for the vendor, hope nothing drifts. For a regulated institution that owns its change calendar, that is the wrong shape. DALP 3.0 puts the upgrade in your hands, and it grounds it where it belongs: on-chain. The directory records the current implementation for every component, and your system converges to it when you choose.
Compare against the directory, upgrade all, keep your addresses.
System updates compares every deployed component, the token factories, add-ons, and compliance modules, against the latest implementation recorded in the on-chain directory. It lists what is behind, and Upgrade all converges your system to the directory in one guided run of on-chain transactions. The implementation advances; the address in front of it does not.
- Source of truth
- On-chain directory
- Run by
- The operator
- Scope
- Whole system
- Addresses
- Preserved
The directory is the source of truth
Every component on your platform runs behind a stable address that points at an implementation contract. The on-chain directory records the current implementation for each one. When DALP ships a new version of a factory, an add-on, or a compliance module, the directory advances. Your deployment does not change until you converge it, so you decide when to move and the chain records exactly what the target is.
See what is behind, then upgrade all
Open System updates in the console. It compares your system against the directory and shows each component with a status: up to date, or behind. Expand a component and you see its current implementation address and the latest one the directory points to, for both the factory and the deployed instance. You do not chase components one at a time. Upgrade all converges the whole system in a single guided run, and the page shows what is left to do as it works.
Nothing moves underneath you
Upgrades advance the implementation behind each component, not the address in front of it. Contract addresses, balances, holder records, and full history carry straight across, so integrations, explorers, and audits that reference your contracts keep working without a remap. The run is gated to an authorized operator, and experimental components stay out of the set unless you opt in.
- 1Compare
System updates checks every deployed component against the latest implementation recorded in the on-chain directory.
- 2Review
Each component shows up to date or behind, with its current implementation address and the directory's latest, for the factory and the instance.
- 3Upgrade all
One guided run of on-chain transactions converges the whole system to the directory. You do not select components individually.
- 4Preserved
Only the implementation advances. Addresses, balances, and history stay put, so every reference to your contracts still resolves.
Why this is better for you
- Upgrades meant scheduling a window and waiting on the vendor.
- There was no single, verifiable source for what the latest version even was.
- Bringing components in line was manual and easy to do partially.
- Address or history changes risked breaking integrations and audits.
- You run the upgrade from the console, on your own schedule.
- The on-chain directory is the source of truth for the latest implementation.
- Upgrade all converges every behind component in one guided run.
- Implementations advance behind stable addresses, so balances and history are preserved.
Monitoring
One verdict tells you whether the platform can proceed, without leaving the product to stitch together three separate infrastructure views.
SDK, CLI & MCP
Every console action is available through the SDK, an AI-native CLI, and an MCP server that agents drive. Same permissions, same controls, whether a human or an agent is behind the wheel. The REST surface has its own entry.