New features
- New Unavailability System —
The frozen and liquid unavailability system we mentioned in the 2nd April release notes will be rolled out to all customers in the coming week.
Action Needed
The new unavailability system does not strictly require any implementation, it is fully backwards compatible and all existing implementations will continue to function.
However, existing implementations will need to be changed to fully utilise the range of new features that have come with this release.
Specifically, in the event of a sudden and unexpected unavailability, we guarantee schedules for a number of settlement periods into the future. The portion of the schedule which is guaranteed and protected by us, but not strictly deliverable, can be obtained from the virtual asset operational endpoint (/organisations/{organisationID}/virtual-assets/{virtualAssetID}/operational) by querying the parameter undeliverableSchedule.
Without this piece of contextual information, your algos may be too conservative in closing positions at short notice after an unavailability.
What’s Changing
As mentioned on 2nd April, the main changes to the behaviour of virtual assets coming with this release are:
- During an unavailability, a virtual asset’s state of energy will now be split into “usable” and “frozen” components, based on the size of the unavailability.
- The virtual asset’s schedule will also be split into “deliverable” and “undeliverable” components.
- The virtual asset’s usable state of energy will evolve according to the deliverable schedule, and the frozen state of energy will evolve according to the undeliverable schedule.
- The values currently returned under the “state-of-charge” and “state-of-energy” endpoints will return the asset’s usable energy — this is to ensure consistency and backwards compatibility with the behaviour of the old unavailability system.
- Additional variables are now available via the asset’s operational endpoint (
/organisations/{organisationID}/virtual-assets/{virtualAssetID}/operational):
- frozenEnergy
- frozenEnergyProjection
- undeliverableSchedule
Bug fixes & stability improvements
- A bug in the calculation of state of energy boundaries under an unavailability which was causing upper boundary values >100% state of charge to be returned by our platform has now been fixed.
- A limitation of the backend system that interfaces with our fleet of physical assets which was occasionally causing extended periods of no state of energy data has been resolved.
Last modified on May 6, 2026
