Engine Families

Versioned, timelocked, code-hash verified engine modules

The engine registry manages the lifecycle of versioned execution modules. Each active cycle stores an engine family and version, cycles stay pinned mid-flight, and rollover resolves the latest supported version in the same family for the selected pool.

Engine Activation Flow

Loading diagram...

Lifecycle

Queue

Owner calls queueEngineVersion() with the module details, supported pools, cooldown, and integrity references. The version is timestamped.

Wait (ACTIVATION_DELAY)

Queued upgrades wait through the engine registry activation delay before they can be enabled for future cycles. The first version in a new family can bootstrap immediately after validation.

Activate

Owner calls activateEngineVersion(). The registry re-verifies the queued module, runs activation checks, and then marks the version as eligible for future cycles.

Deprecate/Pause

Old versions can be deprecated (no new cycles) or paused. Active cycles keep their pinned version until close, and rollover upgrades within the same family when a newer eligible version exists.

Security Guarantees

✓Code hash is recorded at queue time and re-verified at activation - prevents code swaps

✓Bootstrap validation ensures the queued module is wired correctly before activation

✓Queued upgrades wait through the registry activation delay before becoming selectable for future cycles

✓Active cycles are isolated mid-cycle - they continue using their pinned module until close

✓Rollover upgrades within the same family only if a newer eligible version exists for the vault pool

✓Owner can cancel a queued version before activation

Failure ModesActivation fails if the queued module no longer matches what was announced, if the activation checks reject it, if the version does not support the intended pools, or if the required delay has not elapsed yet.

Secured NAV

Heliox (Core)