Create a Conduit

A Conduit wraps an existing Vehicle and issues its own ERC20 shares. This lets multiple Multi-Vehicles access the same yield source while the Conduit manages position aggregation, deposits, and redeems through the STEAM lifecycle.

Platforms also deploy Conduits as distribution channels for existing strategies. See Deploy a Conduit as a platform for the platform-focused guide.

When to use a Conduit

Use a Conduit when:

Multiple Multi-Vehicles need access to the same underlying yield source
You want a single shared position instead of separate per-Multi-Vehicle positions
You need ERC20 transferable shares representing a pro-rata claim on the underlying Vehicle

If only one Multi-Vehicle will ever use a yield source, a regular Vehicle is simpler.

Prerequisites

A deployed STEAM Vehicle (e.g., an ERC4626Vehicle)
A deployed CoreFactory, an AssetRegistry, and a FreezablePausableBeacon holding the Conduit implementation
The CONDUIT_SPAWN role on the factory’s access control — spawn is gated on it
The deposit asset authorized in the AssetRegistry — the factory reads the initial deposit size from there at spawn time
Familiarity with the STEAM standard

Deploy a Conduit

Deploy the ConduitFactory

The ConduitFactory is responsible for spawning new Conduit instances. Its constructor pins the deployment plumbing and the trusted factories used to validate the optional modules you pass to spawn.

ConduitFactory factory = new ConduitFactory(
    coreFactory,              // Deterministic CREATE2 deployment
    conduitBeacon,            // Beacon holding the Conduit implementation
    accessControl,            // Gates CONDUIT_SPAWN and FACTORY_DEPRECATE
    assetRegistry,            // Supplies the per-asset initial deposit amount
    FactoryBase(address(0)),  // previousFactory — none for a first deployment
    feeManagerFactory,        // Validates the feeManager param
    accountListFactory,       // Validates the accountList param
    ownerRegistryFactory,     // Validates the ownerRegistry param
    accessControlFactory      // Validates the accessControl param
);

// Coming soon

Configure spawn parameters

Define the Conduit’s configuration. The deposit asset is the underlying Vehicle’s own asset() and the initial deposit amount is read from the AssetRegistry — neither is passed here.

ConduitFactory.SpawnParams memory params = ConduitFactory.SpawnParams({
    name: "My Conduit",
    symbol: "mCON",
    vehicle: IVehicle(VEHICLE_ADDRESS),
    feeManager: IFeeManager(address(0)),        // No fees for now
    accountList: IAccountList(address(0)),      // No compliance screening
    ownerRegistry: IOwnerRegistry(address(0)),  // No wrapped-query NFTs
    accessControl: accessControl,
    transferEnabled: false,                     // One-way latch, see below
    initialInterceptions: new Interceptor.Interception[](0),
    initialExpectedSupply: 1e18,                // Minimum cShare supply after the seed deposit
    querySalt: bytes32(0),
    deploymentSalt: keccak256("my-conduit-salt")
});

// Coming soon

transferEnabled is a one-way latch. Deploy with false to mint and burn only, then flip it once with enableTransfers() (gated on CONDUIT_SET_TRANSFER_ENABLED); it can never be turned back off. A user-to-user transfer needs both transferEnabled and — when an accountList is set — accountList.canTransfer(from, to).

Spawn the Conduit

Resolve the deposit asset from the Vehicle, look up the amount in the AssetRegistry, approve the factory, then spawn. The deployment salt travels inside params, so spawn takes a single argument.

// The seed deposit uses the Vehicle's own asset
address depositAsset = IVehicle(VEHICLE_ADDRESS).asset();

// Read the configured initial deposit from the AssetRegistry
uint256 initialDeposit = assetRegistry.getInitialDepositAmount(depositAsset);

// Approve the factory to spend it
IERC20(depositAsset).approve(address(factory), initialDeposit);

// Spawn the Conduit — requires CONDUIT_SPAWN
IConduit conduit = factory.spawn(params);

// Coming soon

The initial deposit protects against inflation attacks by bootstrapping the share supply. Once the seed query settles, the factory transfers the shares it received to the burn address, checks totalSupply() >= initialExpectedSupply, and calls enable() on the Conduit. The registry amount also dampens cumulative rounding losses from nested vault accounting — see Asset registry for sizing guidance.

With an async underlying Vehicle the seed deposit does not settle inside spawn. The factory records a PendingDeposit, emits PendingConduitDeposit, and returns a Conduit that is not yet enabled. Call factory.finalizeConduitDeposit(conduit) once the query reaches SETTLED to burn the seed shares and enable it. The factory is the msg.sender of the seed deposit, so if you pass an accountList the factory address must itself satisfy canDeposit at spawn time.

Make a deposit

After deployment, deposit into the Conduit. The Conduit handles pulling assets and creating the STEAM query in the underlying Vehicle.

// Approve the Conduit to spend your tokens
IERC20(underlyingAsset).approve(address(conduit), 100e18);

// The query salt must be caller-bound: `create` requires
// `query.salt == keccak256(abi.encode(msg.sender, sourceSalt))`, otherwise it
// reverts `InvalidQuerySalt`. This ties the query id to you so it cannot be front-run.
bytes32 sourceSalt = keccak256("my-deposit");

// Define the deposit query
Query memory depositQuery = Query({
    owner: address(conduit),
    receiver: address(conduit),
    input: Asset({ asset: address(underlyingAsset), value: 100e18 }),
    output: Asset({ asset: address(conduit), value: 0 }), // 0 = no slippage floor
    mode: Mode.DEPOSIT,
    salt: keccak256(abi.encode(msg.sender, sourceSalt)),
    data: ""
});

// Create and auto-process the deposit — `msg.sender` receives the Conduit shares
conduit.create(depositQuery, msg.sender, sourceSalt);

// Coming soon

After the deposit settles, check your shares:

uint256 shares = conduit.balanceOf(msg.sender);
uint256 assets = conduit.totalAssets();

// Coming soon

Redeem from a Conduit

Call createRedeemFromConduitShares() with the amount of Conduit shares to burn. It converts that cShare amount to Vehicle shares and routes through the same create entrypoint as a deposit, so the gating and salt binding are identical. No ERC20 approval is needed — the Conduit burns your shares internally.

// The salt is caller-bound, exactly as for a deposit
bytes32 sourceSalt = keccak256("my-redeem");

// `value` is a minimum enforced at the Vehicle output; 0 disables the floor
Asset memory outputAsset = Asset({ asset: address(underlyingAsset), value: 0 });

// Burn Conduit shares and send the underlying asset to `msg.sender`
(Id queryId, State state) = conduit.createRedeemFromConduitShares(
    shares,
    outputAsset,
    sourceSalt,
    msg.sender
);

// Coming soon

Getting started

How-to guides

Reference

Create a Conduit

When to use a Conduit

Prerequisites

Deploy a Conduit

Make a deposit

Redeem from a Conduit

Next steps

Configure fees

Learn about Conduits

​When to use a Conduit

​Prerequisites

​Deploy a Conduit

​Make a deposit

​Redeem from a Conduit

​Next steps

Configure fees

Learn about Conduits

When to use a Conduit

Prerequisites

Deploy a Conduit

Make a deposit

Redeem from a Conduit

Next steps