Architecture

System overview and trust boundaries

Heliox is composed of owner-scoped subscription contracts, persistent state registries, Safe-vault infrastructure, execution modules, and supporting payment and history contracts. The protocol keeps billing and credits on the owner account while vault balances and cycle state stay isolated per Safe vault.

Contract Layers

Owner + Vault Control

HelioxHelioxVaultFactoryHelioxVaultRegistryHelioxAccountRegistryHelioxCycleRegistry

The main entry point coordinates owner subscriptions and shared credits, while Safe vault creation, owner-to-vault registration, and persistent account/cycle state live in the registry layer.

Execution

HelioxRunnerHelioxLensHelioxReader

The execution layer applies Heliox lifecycle logic to the selected vault, while read helpers support the app and operational tooling.

Supported Integrations

HelioxPoolRegistryHelioxEngineRegistryExecution modules

Vaults are expected to use supported pools and supported execution modules that the product recognizes.

Periphery

HelioxTradeBookHelioxReferralTreasuryHelioxConfigsHelioxPayments

Supporting contracts handle trade history, referrals, pricing, limits, and payment routing.

Trust Boundary

The most important architectural distinction is not the internal call graph. It is the trust boundary: owner account for subscription identity, Safe vault for strategy assets, and Safe itself for native asset recovery.

Why This MattersPublic docs should explain which account owns which responsibility. Internal execution topology belongs in engineering runbooks, not public product documentation.