Accounting and flow of funds

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

Multi-Vehicle implements rigorous double-entry accounting to track all asset movements through the system. Understanding the sector model and asset flow is essential for operating multi-vehicle deployments.

Why sector-based accounting

In a multi-protocol environment, assets are rarely static. They move between being idle in the vault, committed to a deposit query, held as shares in a sub-vehicle, or queued for redemption. Traditional balance-based accounting struggles to track these “in-flight” assets, leading to potential double-counting or inaccurate share pricing. Multi-Vehicle solves this by partitioning assets into logical sectors that represent their current operational state. This allows the protocol to:

Track the exact lifecycle stage of every asset
Handle asynchronous settlements without losing track of value
Provide an accurate totalAssets() calculation at any point in time

The double-entry principle

Every movement of assets within the system has an explicit source and destination sector. The SectorAccountingEngine:

Decrements the balance of the source sector
Increments the balance of the destination sector
Emits a SectorTransfer event for a clear audit trail

This ensures total supply of accounted assets remains constant across internal transfers, making the system resistant to accounting leaks or “lost” assets.

Core sectors

Sector	Type	Description
ENTRY	Virtual	Assets entering the system. Used as a source for initial deposits; not tracked in internal balances.
AVAILABLE	Physical	Idle base assets (e.g., USDC), usable for both sub-vehicle allocation and redeem-queue fulfillment. Counted in both `totalAssets()` and `withdrawable()`.
RESERVED	Physical	Base assets the operator has explicitly earmarked. Counted in `totalAssets()` but excluded from `withdrawable()`. Asset-only: share moves into RESERVED are rejected.
ALLOCATION	Physical	Sub-vehicle shares from settled deposit queries, representing deployed capital across the portfolio.
EXIT	Virtual	Assets leaving the system. Used as a destination for withdrawals; not tracked in internal balances.

RESERVED exists so that you can park liquidity neither the auto-fulfill path nor the QueueStrategyEngine can consume: both spend against withdrawable(), which reads only AVAILABLE, so a parked balance is invisible to them while still counting towards totalAssets(). Nothing reaches RESERVED implicitly — you must move assets in explicitly (AVAILABLE → RESERVED to park, RESERVED → AVAILABLE to unpark), or route a redeem’s settledDestination there.

Dynamic sectors

Beyond the core sectors, the system creates dynamic sectors for per-vehicle operations:

Sector	Purpose
Vehicle sector	`SectorLib.toSector(vehicle)` — the `0x01` prefix followed by the vehicle address. Per-vehicle staging area between AVAILABLE/ALLOCATION and the sub-vehicle, where assets or shares accumulate before a STEAM query is created.
Query sector	Temporary sector keyed by sub-query, used when recovering from a failed sub-query. Provides high-granularity tracking before funds return to a standard sector.

Deposit flow

Assets flowing from users into sub-vehicles follow this path:

Asset reception

The user deposits base assets into the Multi-Vehicle. Assets transfer from ENTRY (virtual) to the AVAILABLE sector.

Allocation decision

The QueueStrategyEngine processes the deposit queue and determines which sub-vehicle receives the assets.

// QueueStrategyEngine processes deposit queue
depositQueue = [{aave, 60k}, {morpho, 30k}]
// Determines: allocate X to Aave vehicle

// Coming soon

Staging

Assets move from AVAILABLE into the target vehicle’s own sector, SectorLib.toSector(vehicle), where they wait for a query to be created.

Query dispatch

dispatch creates the STEAM query and sends the assets to the sub-vehicle, so they leave the vehicle sector and the accounting system in one step. Ephemeral accounting estimates the expected shares to keep totalAssets accurate during this gap.

Settlement

When the sub-vehicle query settles (sync or async), shares enter the accounting system. ENTRY → ALLOCATION (virtual). Ephemeral estimates are replaced with actual values.

Between steps 4 and 5, assets exist outside the Multi-Vehicle’s accounting system (they are held by the sub-vehicle). Ephemeral accounting tracks their estimated value during this gap to keep totalAssets() and share price accurate.

Redeem flow

Assets flowing from sub-vehicles back to users follow the reverse path:

Unallocation decision

The QueueStrategyEngine processes the redeem queue and determines which sub-vehicle to unallocate from. ALLOCATION → vehicle sector.

Query dispatch

dispatch creates a STEAM redeem query and sends the shares to the sub-vehicle, so they leave the vehicle sector and the accounting system. Ephemeral accounting estimates the expected base assets to keep totalAssets accurate.

Settlement

Base assets arrive from the sub-vehicle and land in the query’s settledDestination — AVAILABLE by default, though you can route them to RESERVED or to another vehicle’s sector instead. Ephemeral estimates are replaced with actual values.

Asset return

The user withdraws their base assets. AVAILABLE → EXIT.

Example: deposit cycle walkthrough

Step-by-step sector balances through a 50k deposit

A Multi-Vehicle starts with 100k in total assets. A user deposits 50k, which is allocated to an Aave sub-vehicle.

Step	Action	AVAILABLE	Aave vehicle sector	Ephemeral	ALLOCATION	totalAssets
T0	Initial state	20k	—	—	80k (shares)	100k
T1	User deposits 50k	70k	—	—	80k	150k
T2	Stage 50k into the Aave vehicle sector	20k	50k	—	80k	150k
T3	Query created, assets sent to Aave	20k	—	~50k (est. shares)	80k	~150k
T4	Settlement: shares received (ENTRY →)	20k	—	—	130k	~150k

Key insight: totalAssets stays at ~150k through every step. At T2 the 50k is still accounted for, just staged in the vehicle sector. At T3 it has left the system entirely and the shares have not arrived yet (ENTRY → ALLOCATION has not happened); ephemeral accounting bridges this gap by estimating the expected share value.

Asynchronous redemptions

When immediate liquidity is insufficient, the QueryRedeemQueue handles fulfillment over time:

User requests a redemption that exceeds available liquidity
A demand is created in the QueryRedeemQueue for the unfulfilled portion
A keeper or operator provides liquidity by calling feedQueryRedeemQueue on the VehicleManager, which spends withdrawable() (the AVAILABLE balance)
FIFO position-based matching pairs demands with fulfillments as liquidity arrives
The user receives assets (full or partial) as liquidity becomes available

// User redeems shares worth 2000 USDC
// Immediate liquidity, withdrawable() over AVAILABLE: 500 USDC
// Need: 1500 USDC more

// 1. The immediate portion settles out of AVAILABLE
// 2. Multi-Vehicle queues the rest:
//    redeemQueue.demand(remainingShares, 1500e6)

// Later: operator provides liquidity from AVAILABLE
// 3. manager.feedQueryRedeemQueue()
// 4. The user unlocks again and receives the remaining 1500 USDC

// Coming soon

Ephemeral accounting

One of the most critical challenges in async asset management is accounting for value that has been committed but not yet received. When a deposit to a sub-vehicle is PROCESSING, the Multi-Vehicle no longer has the base assets, but it does not yet have the shares. The SubQueryEngine manages ephemeral accounting to bridge this gap:

Without ephemeral accounting
With ephemeral accounting

// WITHOUT ephemeral accounting
// T0: totalAssets = 100k (AVAILABLE: 20k, ALLOCATION: 80k in shares)
//
// User deposits 10k -> staged in the Aave vehicle sector -> query dispatched
// Assets leave the system: vehicle sector -> sub-vehicle
// Shares not yet received (ENTRY -> ALLOCATION hasn't happened)
//
// T1: totalAssets = 100k — the 10k left the system entirely!
//     Share price drops — new depositors get shares too cheaply

// Coming soon

// WITH ephemeral accounting
// T0: totalAssets = 100k (AVAILABLE: 20k, ALLOCATION: 80k in shares)
//
// User deposits 10k -> staged in the Aave vehicle sector -> query dispatched
// Assets leave the system: vehicle sector -> sub-vehicle
// Ephemeral: vehicle.estimate({usdc, 10k}, Mode.DEPOSIT, EstimationType.OUTPUT) ≈ 9,950 aUSDC
//
// T1: totalAssets = 100k + convert(9,950 aUSDC) ≈ 110k ✓
//
// Settlement: actual 9,980 aUSDC received → ENTRY → ALLOCATION
// Ephemeral cleared, real shares replace estimate
// T2: totalAssets = 100k + convert(9,980 aUSDC) ≈ 110k ✓

// Coming soon

When a sub-query enters PROCESSING, the assets leave the vehicle sector and the accounting system altogether, and the system uses the vehicle’s estimate() function to determine the expected output. This estimated value is tracked as ephemeral accounting against the query’s settledDestination. On settlement, shares enter the system (ENTRY → ALLOCATION) and the ephemeral estimation is replaced with actual values. Multi-Vehicle uses the ERC-4626 standard for pricing:

shares = assets * totalSupply / totalAssets()

// Coming soon

The totalAssets() function aggregates value across all sectors:

totalAssets =
    AVAILABLE sector balance                        // idle base assets
  + RESERVED sector balance                         // operator-earmarked base assets
  + for each active vehicle:
      + assets in vehicle sector                    // awaiting deposit query creation
      + expected assets from PROCESSING redeems     // ephemeral
      + estimateSingleAssetAssets(                  // redeem-output estimate, post-fee
          shares in ALLOCATION                      // settled
        + shares in vehicle sector                  // awaiting redeem query
        + expected shares from PROCESSING deposits  // ephemeral
      )

// Coming soon

By including both settled and in-flight value, Multi-Vehicle ensures that its share price always reflects the true underlying value of the entire portfolio. withdrawable() is deliberately narrower: it reports only the AVAILABLE balance. RESERVED, vehicle-sector residuals and ALLOCATION shares are never counted as immediate liquidity, because reaching them requires an explicit move or dispatch.

Monitoring

Operators should track these key metrics:

Sector balances

AVAILABLE — Idle base-asset liquidity, and everything withdrawable() reports
RESERVED — Earmarked base assets, excluded from withdrawable()
ALLOCATION — Total deployed capital, held as sub-vehicle shares
Vehicle sectors — Assets and shares staged for the next query
Ephemeral — Value in flight for PROCESSING queries

Queue health

Demand — Total pending redemptions in the QueryRedeemQueue
Fulfillment — Available liquidity for matching
Average wait time — User experience metric

Vehicle health

Per-vehicle — totalAssets, share price, query states
Distribution — Actual vs target allocations across sub-vehicles

IVehicleManager manager = MultiVehicle(multiVehicle).manager();
ISectorAccountingEngine accounting = manager.accountingEngine();

uint256 idle = accounting.getSectorBalance(SectorLib.AVAILABLE, IERC20(baseAsset));
uint256 parked = accounting.getSectorBalance(SectorLib.RESERVED, IERC20(baseAsset));
uint256 liquidity = accounting.withdrawable();   // equals `idle`
uint256 staged = accounting.getSectorBalance(SectorLib.toSector(vehicle), IERC20(baseAsset));

// Per-vehicle detail
(
    uint256 sharesAfterUnlocks,          // settled shares in ALLOCATION
    uint256 sharesBeforeCreates,         // shares staged for new redeem queries
    uint256 expectedSharesAfterUnlocks,  // ephemeral shares from in-flight deposits
    uint256 expectedAssetsAfterUnlocks,  // projected assets from in-flight redeems
    uint256 assetsBeforeCreates          // assets staged for new deposit queries
) = accounting.vehicleHoldings(vehicle);

// Coming soon

Best practices:

Monitor vehicle sectors for balances that linger, indicating slow query settlement
Maintain a sufficient AVAILABLE balance for immediate withdrawals
Regularly fulfill the QueryRedeemQueue to minimize user wait times
Validate sector balances for accounting integrity with regular audits

Next steps

Multi-Vehicle architecture

How Multi-Vehicle orchestrates capital across sub-vehicles.

The STEAM standard

The state machine interface that drives all deposit and redeem queries.

Create an Allocation Strategy

Deploy an Allocation Strategy (MultiVehicle) ecosystem.

Operate an Allocation Strategy

Day-to-day operations including queue management and rebalancing.

Getting started

How-to guides

Reference

Accounting and flow of funds

Why sector-based accounting

The double-entry principle

Core sectors

Dynamic sectors

Deposit flow

Redeem flow

Example: deposit cycle walkthrough

Asynchronous redemptions

Ephemeral accounting

Monitoring

Next steps

Multi-Vehicle architecture

The STEAM standard

Create an Allocation Strategy

Operate an Allocation Strategy

​Why sector-based accounting

​The double-entry principle

​Core sectors

​Dynamic sectors

​Deposit flow

​Redeem flow

​Example: deposit cycle walkthrough

​Asynchronous redemptions

​Ephemeral accounting

​Exchange rate and share price

​Monitoring

​Next steps

Multi-Vehicle architecture

The STEAM standard

Create an Allocation Strategy

Operate an Allocation Strategy

Why sector-based accounting

The double-entry principle

Core sectors

Dynamic sectors

Deposit flow

Redeem flow

Example: deposit cycle walkthrough

Asynchronous redemptions

Ephemeral accounting

Exchange rate and share price

Monitoring

Next steps