Asset registry

The AssetRegistry is a single contract that Vehicle and Conduit factories consult at spawn time. For each asset, it stores two things:

Whether the asset is authorized for use
The initial deposit amount the factory should pull and burn during deployment

Registry-backed factories no longer accept an initialDepositSize in their SpawnParams — the registry is the source of truth. A caller with FACTORY_SPAWN cannot deploy through them for an unauthorized asset, and cannot override the initial deposit amount set by the registry admin. ERC7540VehicleFactory is the exception: it is not wired to a registry and still takes initialDepositSize in its SpawnParams.

What it stores

Each asset has an AssetConfig:

struct AssetConfig {
    bool isAuthorized;
    uint256 initialDepositAmount;
}

The registry exposes three reads:

Method	Returns
`getAssetConfig(asset)`	Full `AssetConfig` struct
`isAssetAuthorized(asset)`	`true` if authorized
`getInitialDepositAmount(asset)`	Configured initial deposit (reverts with `AssetNotAuthorized` if not authorized)

Why the initial deposit size matters

Vehicles wrap underlying yield protocols (Aave V3, Morpho Blue, ERC-4626 vaults), creating two independent layers of integer share math. Each layer rounds in the protocol’s favor (floor on deposit, ceil on withdraw), and because the Vehicle’s share math and the underlying protocol’s share math round independently, per-operation dust accumulates non-deterministically on the Vehicle’s balance. Two outcomes per operation:

Erosion — the underlying protocol rounds harder against the Vehicle than the Vehicle rounds against the user. The Vehicle ends up with slightly less underlying value, dragging the share price down for all holders.
Accretion — the Vehicle rounds harder against the user. The Vehicle retains extra dust, lifting the share price.

The per-operation impact is inversely proportional to the Vehicle’s total underlying balance. A large enough initial deposit makes cumulative rounding losses economically insignificant relative to totalAssets. The shares minted from the initial deposit are burned to a permanent burn address, so the underlying buffer stays in the Vehicle forever, absorbing rounding losses without affecting any real user.

Low-decimal assets are more sensitive to rounding than high-decimal assets because 1 wei represents a larger fraction of a unit. Size the initial deposit for USDC (6 decimals) more aggressively than for DAI (18 decimals). Configure it high enough that realistic operation volumes cannot meaningfully erode the Vehicle’s balance.

Authorization

Managing registry entries requires the ASSET_REGISTRY_SET_ASSET role.

Role	Purpose
`ASSET_REGISTRY_SET_ASSET`	Authorize, deauthorize, or reconfigure assets in the registry

setAssetConfig(asset, isAuthorized, initialDepositAmount) is the only writer. Authorizing an asset requires a non-zero initialDepositAmount, otherwise the call reverts with InvalidInitialDepositSize; deauthorizing forces the stored amount back to 0. Every write emits AssetConfigSet(asset, isAuthorized, initialDepositAmount). When a factory is asked to spawn for an unauthorized asset, it reverts with AssetNotAuthorized(address) from FactoryLib. Constructing a factory with a zero or non-contract registry address reverts with InvalidAssetRegistry.

Deauthorizing an asset does not affect Vehicles already deployed for that asset — it only prevents new spawns. Existing positions continue to operate normally.

Deploy and configure

The registry is typically deployed once per environment, pre-populated with the assets you expect to support.

// Deploy with an initial set of authorized assets
IAssetRegistry.InitialAssetConfig[] memory configs = new IAssetRegistry.InitialAssetConfig[](2);
configs[0] = IAssetRegistry.InitialAssetConfig({
    asset: USDC,
    initialDepositAmount: 1_000e6 // 1,000 USDC — sized for 6-decimal rounding sensitivity
});
configs[1] = IAssetRegistry.InitialAssetConfig({
    asset: DAI,
    initialDepositAmount: 1e18 // 1 DAI — 18 decimals, less sensitive
});

AssetRegistry registry = new AssetRegistry(accessControl, configs);

// Coming soon

Update a single asset later:

// Authorize a new asset (requires ASSET_REGISTRY_SET_ASSET)
registry.setAssetConfig(WETH, true, 0.1 ether);

// Deauthorize an asset — initialDepositAmount is forced to 0
registry.setAssetConfig(oldAsset, false, 0);

// Coming soon

How factories use the registry

The AaveV3, ERC4626, Ethena, MorphoBlue, MultiVehicle, Wrapper, and Conduit factories each hold an immutable ASSET_REGISTRY pointer set at construction, announced with the AssetRegistryInitialized event. On spawn:

The factory reads getInitialDepositAmount(asset) — reverts if the asset is not authorized. ConduitFactory uses the underlying Vehicle’s asset().
It pulls that amount from the caller and performs the initial deposit into the new Vehicle or Conduit.
It transfers the resulting shares to the burn address (0x…dEaD), permanently locking the deposit.

Callers of those factories do not pass an initial deposit size anywhere in the spawn flow — they only need to hold the registry-specified amount and have approved it to the factory.

Getting started

How-to guides

Reference

What it stores

Why the initial deposit size matters

Authorization

Deploy and configure

How factories use the registry

Next steps

Create a Conduit

Create an Allocation Strategy

​What it stores

​Why the initial deposit size matters

​Authorization

​Deploy and configure

​How factories use the registry

​Next steps

Create a Conduit

Create an Allocation Strategy

What it stores

Why the initial deposit size matters

Authorization

Deploy and configure

How factories use the registry

Next steps