Multi-Vehicle architecture

In user-facing documentation, a MultiVehicle is referred to as a Strategy. See Glossary.

A Multi-Vehicle is a sophisticated vault system built on the STEAM protocol. It manages multiple sub-vehicles (yield strategies) with advanced allocation and redemption capabilities, providing a single entry point for diversified DeFi strategies.

Architecture overview

A Multi-Vehicle is composed of 6 interconnected components: The MultiVehicle exposes only manager(). Every engine is reached through the VehicleManager:

Solidity

IVehicleManager manager = MultiVehicle(multiVehicle).manager();

ISectorAccountingEngine accounting = manager.accountingEngine();
IQueueStrategyEngine strategy = manager.queueStrategyEngine();
ISubQueryEngine subQueryEngine = manager.subQueryEngine();
IQueryRedeemQueue redeemQueue = manager.redeemQueue();

The 6 components

1. MultiVehicle (main contract)

The STEAM-compliant entry point that users interact with directly. User operations:

Deposit assets — receive Multi-Vehicle shares
Redeem shares — receive base assets back

Key responsibilities:

User-facing STEAM operations (create, resume, unlock, recover)
Share minting and burning using ERC-4626-style exchange rates
Integration with QueryRedeemQueue for asynchronous redemptions

2. SectorAccountingEngine

The central accounting system implementing double-entry bookkeeping principles. Every asset movement is recorded as a transfer between sectors, ensuring the total supply of accounted assets remains constant.

Sector	Type	Description
ENTRY	Virtual	Assets entering the system (untracked balance)
AVAILABLE	Physical	Idle base assets; counted in `totalAssets()` and `withdrawable()`
RESERVED	Physical	Operator-earmarked base assets; in `totalAssets()` but excluded from `withdrawable()`
ALLOCATION	Physical	Sub-vehicle shares from settled deposits (deployed capital)
EXIT	Virtual	Assets leaving the system (untracked balance)
Vehicle sectors	Staging	`SectorLib.toSector(vehicle)` — per-vehicle staging area
Query sectors	Ephemeral	Assets or shares committed to an in-flight sub-query

RESERVED is asset-only and reachable only through an explicit move, so neither auto-fulfill nor the Queue Strategy Engine can consume liquidity parked there.

For a deep dive into how sectors work and how funds flow between them, see Accounting and flow of funds.

3. QueueStrategyEngine

Defines the allocation strategy through configurable priority queues. The asset manager sets up deposit and redeem queues that control how capital is distributed.

Deposit queue

A prioritized list of {vehicle, target} pairs:

Processes in order (index 0 = highest priority)
target = maximum shares to allocate to a vehicle before moving to the next entry
Stops when the vehicle reaches its target, hits maxDepositable, or assets are exhausted

// Initial state
depositQueue = [{aave, 60k}, {morpho, 30k}]
currentHoldings = {aave: 50k, morpho: 20k}
newDeposit = 20k shares

// Algorithm execution:
// 1. Check aave: 50k < 60k target
//    -> allocate min(20k available, 10k to reach target) = 10k to aave
//    -> aave now has 60k

// 2. Remaining: 10k shares

// 3. Check morpho: 20k < 30k target
//    -> allocate min(10k available, 10k to reach target) = 10k to morpho
//    -> morpho now has 30k

// 4. Done: aave=60k, morpho=30k

// Coming soon

The deposit queue does not enforce ongoing ratios. If a vehicle grows past its target from yield alone, new deposits skip it and go to the next queue entry.

Redeem queue

A prioritized list of {vehicle, target} pairs where target represents a floor (minimum shares to maintain):

Processes in order (index 0 = highest priority)
Redeems from a vehicle down to its floor
Moves to the next entry if more assets are needed

// Initial state
redeemQueue = [{aave, 20k}, {morpho, 10k}]
currentHoldings = {aave: 60k, morpho: 30k}
redeemRequest = 50k shares

// Algorithm execution:
// 1. Check aave: 60k holdings, 20k floor
//    -> redeem min(50k requested, 60k - 20k available) = 40k from aave
//    -> aave now has 20k (at floor)

// 2. Remaining: 10k shares

// 3. Check morpho: 30k holdings, 10k floor
//    -> redeem min(10k requested, 30k - 10k available) = 10k from morpho
//    -> morpho now has 20k

// 4. Done: redeemed 50k total

// Coming soon

4. SubQueryEngine

Manages the STEAM query lifecycle for operations dispatched to sub-vehicles. It tracks ephemeral accounting to prevent share price distortion during asynchronous operations. Ephemeral accounting ensures that totalAssets() remains accurate even when assets are in-flight:

When a sub-query enters PROCESSING, the system uses the vehicle’s estimate() function to record expected outputs
As actual shares are received on settlement, the ephemeral estimate is replaced with real values
This prevents spikes or drops in the Multi-Vehicle’s share price during async settlements

5. QueryRedeemQueue

Handles asynchronous redemptions when immediate liquidity is insufficient:

Demands — user redemption requests created by demand(amountIn, maxAmountOut). Each demand records the shares owed, carries a slippage ceiling, and is assigned a 1-indexed id.
Fulfillments — liquidity provisions created by fulfill(amountInFilled, amountOutProvided), driven by a keeper or operator calling feedQueryRedeemQueue on the Vehicle Manager. Assets are distributed pro-rata over the demand/fulfillment position overlap.
Partial fills — a single demand can be filled across multiple rounds. redeem is callable repeatedly as new fulfillments arrive, and pending(demandId) reports what is still owed.
Claiming — once a demand is redeemable, the holder calls redeem(demandId), which returns (redeemedAssets, remainingShares) and transfers the base assets. Check redeemable(demandId) first; the call reverts if the demand is not yet redeemable or if the assets would exceed the demand’s maxAmountOut.
Excess — assets left over when fulfillments over-provide accumulate as retrievable(), pulled back by the Vehicle Manager via retrieveQueryRedeemQueueAssets.

6. VehicleManager

The control plane for sub-vehicles and the contract the MultiVehicle points at. Every vehicle must be authorized here before it can receive capital. Key responsibilities:

Validate vehicle compatibility (a contract, ready(), matching base asset)
Store per-vehicle configuration: VehicleConfig { VehicleMode mode; Target cap; }
Hold the wiring to the engines and the redeem queue (accountingEngine(), queueStrategyEngine(), subQueryEngine(), redeemQueue())
Own the strategy-level knobs: setThresholds, setMaxTotalAssets, feedQueryRedeemQueue, retrieveQueryRedeemQueueAssets
Enforce role-based access for authorization changes

The role of the asset manager

The asset manager configures and operates the Multi-Vehicle. Beyond setting initial parameters, they have four active levers.

Rebalance capital

There is no rebalance function. The asset manager composes one from dispatch and move, reusing a single operationId so off-chain consumers can group the steps:

bytes32 opId = keccak256("rebalance-aave-to-morpho");

// 1. Redeem from the source vehicle, proceeds land in AVAILABLE
accounting.dispatch(
    ISectorAccountingEngine.DispatchParams({
        vehicle: fromVehicle,
        mode: Mode.REDEEM,
        amount: shareAmount,
        settledDestination: SectorLib.AVAILABLE,
        rejectedDestination: SectorLib.ALLOCATION,
        minOutput: minAssetsOut,
        data: "",
        operationId: opId
    })
);

// 2. Stage the freed assets for the destination vehicle
accounting.move(
    ISectorAccountingEngine.MoveParams({
        from: SectorLib.AVAILABLE,
        to: SectorLib.toSector(toVehicle),
        asset: baseAsset,
        amount: type(uint256).max,
        operationId: opId
    })
);

// 3. Dispatch the deposit into the destination vehicle

// Coming soon

If the source vehicle is asynchronous, step 1 returns PROCESSING: the redemption must settle before the assets exist in AVAILABLE, so steps 2 and 3 run in a later transaction.

Manage sub-vehicles

Add or remove yield sources at any time:

// Authorize a new sub-vehicle with the default config
vehicleManager.authorize(newVehicle);

// Or authorize with an initial mode and cap
vehicleManager.authorizeAndConfigure(newVehicle, config);

// Change mode or cap later
vehicleManager.configure(existingVehicle, newConfig);

// Remove a sub-vehicle (redeem all positions first)
vehicleManager.unauthorize(vehicleToRemove);

// Coming soon

Removing a sub-vehicle prevents new allocations but does not automatically redeem existing positions — unallocate first.

Reconfigure queues

Update allocation priorities without moving capital:

// Set new deposit and redeem queues
queueStrategyEngine.setQueues(newDepositQueue, newRedeemQueue);

// Coming soon

New deposits and redemptions follow the updated order immediately. Existing positions are unaffected.

Feed redemption liquidity

When async redemptions are pending in the QueryRedeemQueue, feed liquidity to fulfill demands:

vehicleManager.feedQueryRedeemQueue();

// Coming soon

Keepers typically automate this, but operators can trigger it manually if redemptions stall.

Authorization and guardrails

Every sub-vehicle must be explicitly authorized on the VehicleManager before it can receive capital. Authorization validates that the vehicle is a contract, reports ready(), and uses the same base asset as the Multi-Vehicle.

Vehicle configuration

Each authorized vehicle has a configuration with two parameters:

Parameter	Values	Description
Mode	`Automatic` (default), `Manual`	Automatic vehicles participate in queue-based allocation. Manual vehicles only receive capital through an explicit `move` plus `dispatch`.
Cap	Share target (default: unlimited)	Maximum allocation target for this vehicle. Limits exposure to a single yield source.

// Authorize with Automatic mode and a 100k share cap
vehicleManager.authorizeAndConfigure(
    vehicle,
    VehicleManagerStore.VehicleConfig({
        mode: VehicleMode.Automatic,
        cap: Target({value: 100_000e18, threshold: 0})
    })
);

// Coming soon

On-chain guardrails

Authorization and caps create enforceable boundaries:

Queue configuration cannot route capital to unauthorized vehicles
Allocation caps limit exposure regardless of queue targets or manual moves
Role-based access (via EAC) controls who can authorize vehicles, set caps, and reconfigure queues — allowing platforms commissioning a strategy to set guardrails that asset managers cannot override

This means strategies can run hands-off through queue automation while enforcing risk boundaries that neither automation nor operators can exceed.

Sync and async sub-vehicles

Multi-Vehicle orchestrates both synchronous and asynchronous sub-vehicles. Synchronous sub-vehicles (Aave V3, Morpho Blue, ERC-4626) complete in a single transaction:

// Sync flow: single transaction
// EMPTY -> UNLOCKING -> SETTLED

// Coming soon

Asynchronous sub-vehicles (ERC-7540 vaults, Lagoon, Ethena) require multiple transactions:

// Async flow: multiple transactions
// EMPTY -> PROCESSING -> (PAUSED ->) UNLOCKING -> SETTLED

// Coming soon

When interacting with async sub-vehicles:

Sub-queries remain in PROCESSING until the underlying protocol is ready
Ephemeral accounting tracks expected outputs to prevent share price distortion
The Keeper system automates monitoring and advancing nested operations
Operators should watch vehicle sector balances for high amounts indicating slow settlement

Design principles

Separation of concerns — Each component has a single, well-defined responsibility
Double-entry accounting — All asset movements are tracked through sector transfers
Asynchronous by design — STEAM handles both sync and async operations gracefully
Queue-based strategy — Flexible, operator-controlled allocation and redemption logic
Accurate pricing — Ephemeral accounting ensures share price accuracy during in-flight operations

Trade-offs to consider:

Gas costs — More automation means higher gas costs. Queue-based strategies execute more transactions.
Complexity — More vehicles mean more monitoring and management overhead. Start simple and scale up.
Async operations — Sub-vehicle operations may not settle immediately. Design your flows with async handling in mind.

Getting started

How-to guides

Reference

Multi-Vehicle architecture

Architecture overview

The 6 components

1. MultiVehicle (main contract)

2. SectorAccountingEngine

3. QueueStrategyEngine

Deposit queue

Redeem queue

4. SubQueryEngine

5. QueryRedeemQueue

6. VehicleManager

The role of the asset manager

Rebalance capital

Manage sub-vehicles

Reconfigure queues

Feed redemption liquidity

Authorization and guardrails

Vehicle configuration

On-chain guardrails

Sync and async sub-vehicles

Design principles

​Architecture overview

​The 6 components

​1. MultiVehicle (main contract)

​2. SectorAccountingEngine

​3. QueueStrategyEngine

​Deposit queue

​Redeem queue

​4. SubQueryEngine

​5. QueryRedeemQueue

​6. VehicleManager

​The role of the asset manager

​Rebalance capital

​Manage sub-vehicles

​Reconfigure queues

​Feed redemption liquidity

​Authorization and guardrails

​Vehicle configuration

​On-chain guardrails

​Sync and async sub-vehicles

​Design principles

Architecture overview

The 6 components

1. MultiVehicle (main contract)

2. SectorAccountingEngine

3. QueueStrategyEngine

Deposit queue

Redeem queue

4. SubQueryEngine

5. QueryRedeemQueue

6. VehicleManager

The role of the asset manager

Rebalance capital

Manage sub-vehicles

Reconfigure queues

Feed redemption liquidity

Authorization and guardrails

Vehicle configuration

On-chain guardrails

Sync and async sub-vehicles

Design principles