Auto-Sweep

Auto-Sweep allows a capital provider to hold working capital in Multiliquid Treasury while MultiliquidSwap coordinates settlement conversions at execution time. The feature has two complementary operations:

Prefund runs before a user-requested stablecoin-output swap. It redeems the capital provider’s Multiliquid Treasury token ($TSY) into the stablecoin required for settlement.
Sweep runs after an eligible stablecoin-input swap. It deposits the stablecoin balance received by the capital provider vault during that swap into Multiliquid Treasury.

Both operations are internal swap legs owned by the capital provider. The capital provider does not add them to the user’s calldata or permit. The user authorizes a user-requested leg, and MultiliquidSwap derives any capital provider prefund or sweep leg from current execution state using the capital provider vault’s separate permissions.

How It Works

Prefund

Prefund is explicit in the user-requested route. It is not a separate route submitted by the capital provider:

The user-facing integrator selects route 8, 9, 10, or 11, and the execution operator submits it for the user.
MultiliquidSwap quotes that user-requested leg at execution time.
The contract derives a stablecoin-to-stablecoin exact-out leg owned by the capital provider from Multiliquid Treasury into the stablecoin needed by the user-requested leg.
The capital provider vault is the user and receiver of the derived leg; MultiliquidSwap is its operator.
The derived capital provider prefund and user-requested leg settle atomically.

The contract skips a no-op prefund when Multiliquid Treasury already supplies the required inventory. Otherwise, a user-requested prefunded route requires sufficient $TSY balance, Multiliquid Treasury credits, token approval, protocol allowance, and Treasury Delegate settlement capacity.

Sweep

Sweep is automatic on eligible user-requested routes once the capital provider vault has opted in for the user’s input asset:

Before the user-requested leg, the contract reads the capital provider vault’s input-stablecoin balance.
The user-requested leg settles into the capital provider vault.
The contract reads the balance again and uses only the positive delta as the sweep input.
A zero standing protocol allowance from the capital provider vault skips the sweep.
A positive allowance causes the contract to derive an exact-in deposit owned by the capital provider into Multiliquid Treasury.

The sweep does not consume stablecoin inventory that was already in the capital provider vault before the user-requested leg. Its minimum $TSY output is quoted internally at execution time, and the derived capital provider leg settles atomically with the user-requested swap. Multiliquid Treasury deposits create $TSY tokens and Treasury Delegate credits for the capital provider vault. The Multiliquid Treasury application page describes token and credit accounting.

Route Behavior

This table starts with the route requested and authorized by the user. The last two columns show whether MultiliquidSwap can add a separate Multiliquid Treasury leg owned by the capital provider.

User-requested route	IDs	Derived Multiliquid Treasury prefund	Derived Multiliquid Treasury sweep
Stablecoin → RWA	`0`, `1`	No	Eligible
RWA → stablecoin	`2`, `3`	No	No
RWA → RWA	`4`, `5`	No	No
Stablecoin → stablecoin	`6`, `7`	No	Eligible
Prefunded RWA → stablecoin	`8`, `9`	Yes	No
Prefunded stablecoin → stablecoin	`10`, `11`	Yes	Eligible

“Eligible” does not mean the user controls the capital provider sweep. A sweep executes only when the capital provider has configured Multiliquid Treasury and the capital provider vault has granted a sufficient standing allowance for the user-requested input asset. Prefund may be skipped when the derived conversion would be an identity operation. The contract reads Auto-Sweep configuration from the user-requested leg’s stablecoinDelegateID. For stablecoin-to-stablecoin routes, the integrator’s input-side or output-side delegate selection therefore determines which capital provider domain, configuration, and custody account apply. The capital provider provides integration partners with the stablecoin delegate ID that identifies the capital provider domain.

Who Controls Each Part

Multiliquid Treasury Auto-Sweep is controlled at three levels:

Control	Owner	Effect
Multiliquid Treasury destination	The capital provider admin	Sets `TSY_YIELD` for the capital provider delegate; zero disables all automatic capital provider legs
Standing input allowance	The capital provider vault	Enables derived spending from the capital provider vault for one input asset, such as USDC
User-requested route ID	User-facing integrator + user	Routes `8`–`11` ask the contract to derive prefund; the user authorizes this route selection

This separation supports several operating modes:

Mode	Capital provider configuration	Required user-facing integration behavior
Disabled	The configured destination is `bytes32(0)`	The integrator does not submit prefunded routes; they revert while disabled
Sweep only	Multiliquid Treasury is configured and only selected sweep inputs are authorized	The integrator submits base routes `0`–`7`; eligible user inputs can trigger sweep
Prefund only	Multiliquid Treasury is configured, `$TSY` is authorized, and sweep-input allowances remain zero	The integrator selects prefunded routes `8`–`11` where capital provider inventory is needed
Prefund and sweep	Multiliquid Treasury, `$TSY` prefund inventory, and selected sweep inputs are authorized	The integrator selects prefunded routes where needed; base routes remain available

Standing allowances can be bounded and replenished as they are spent, or set to type(uint256).max. A maximum allowance is treated as unlimited and is not decremented by successful swaps.

Capital Provider Enablement Steps

This section assumes the capital provider stablecoin delegate is initialized, its custody address is configured, and it accepts Multiliquid Treasury. The examples assume an initialized ml client from the EVM Integration Guide. Narrative references use capital provider terminology; ml.issuerAdmin remains the exact SDK module name for the delegate’s on-chain admin interface.

Capital provider admin: Select Multiliquid Treasury

The capital provider admin sets TSY_YIELD as the autoLiquidityStablecoinID for the existing capital provider stablecoin delegate.

Capital provider vault: Approve the Treasury Delegate

The capital provider vault approves the Treasury Delegate to pull USDC for Multiliquid Treasury sweeps. Approval for $TSY is required only when the capital provider also uses prefunded JIT redemption.

Capital provider vault: Grant standing protocol allowances

The capital provider vault authorizes MultiliquidSwap to spend USDC for derived Liquid Treasury sweeps. A separate $TSY allowance enables optional prefund.

Capital provider + operator: Verify enablement

The capital provider operations team confirms the configured Multiliquid Treasury ID and previews an eligible sweep. The execution operator simulates the final user-requested transaction.

Configuration Values

import { mainnet } from "@uniformlabs/multiliquid-evm-sdk";

const lpStablecoinID = mainnet.assetIds.stablecoin.USDC;
const sweepInputStablecoinID = mainnet.assetIds.stablecoin.USDC;
const liquidTreasuryID = mainnet.assetIds.stablecoin.TSY_YIELD;

const [lpVault, sweepInputInfo, liquidTreasuryInfo, treasuryDelegate] =
  await Promise.all([
    ml.delegates.getStablecoinCustodyAddress(lpStablecoinID),
    ml.assets.getStablecoinInfo(sweepInputStablecoinID),
    ml.assets.getStablecoinInfo(liquidTreasuryID),
    ml.delegates.getDelegateAddress(liquidTreasuryID),
  ]);

The example uses USDC as the sweep input and Multiliquid Treasury as the destination. A separate capital provider stablecoin registration can replace lpStablecoinID when the capital provider domain is not the Uniform Labs USDC registration.

1. Capital Provider Admin: Select Multiliquid Treasury

The capital provider admin sets Multiliquid Treasury as the destination for the existing capital provider stablecoin delegate:

await ml.issuerAdmin.setAutoLiquidityStablecoinID({
  stablecoinID: lpStablecoinID,
  autoLiquidityStablecoinID: liquidTreasuryID,
});

The delegate forwards the setting to MultiliquidSwap. The transaction emits AutoLiquidityStablecoinIDSet. The setting applies only to user-requested routes whose stablecoinDelegateID selects this capital provider domain.

2. Capital Provider Vault: Approve the Treasury Delegate

ERC-20 approval authorizes the Treasury Delegate to pull tokens from the capital provider vault during settlement. The wallet client below must sign as the capital provider vault. USDC approval enables the Multiliquid Treasury sweep:

import { maxUint256 } from "viem";
import { erc20Abi } from "@uniformlabs/multiliquid-evm-sdk";

await lpVaultWalletClient.writeContract({
  account: lpVaultWalletClient.account,
  address: sweepInputInfo.assetAddress,
  abi: erc20Abi,
  functionName: "approve",
  args: [treasuryDelegate, maxUint256],
  chain: lpVaultWalletClient.chain,
});

A capital provider that also uses prefunded JIT redemption grants a separate $TSY approval:

await lpVaultWalletClient.writeContract({
  account: lpVaultWalletClient.account,
  address: liquidTreasuryInfo.assetAddress,
  abi: erc20Abi,
  functionName: "approve",
  args: [treasuryDelegate, maxUint256],
  chain: lpVaultWalletClient.chain,
});

The Multiliquid Treasury administrator separately maintains the Treasury Delegate custody approvals and settlement inventory assumed by this guide.

3. Capital Provider Vault: Grant Standing Protocol Allowances

swapInputAllowance is separate from ERC-20 approval. It authorizes MultiliquidSwap to insert and operate a derived capital provider leg. The capital provider creates an SDK client whose wallet signs as the capital provider vault:

import { createMultiliquidClient } from "@uniformlabs/multiliquid-evm-sdk";

const mlAsLpVault = createMultiliquidClient({
  deployment: ml.deployment,
  publicClient,
  walletClient: lpVaultWalletClient,
});

The helper below moves the current standing allowance to a chosen target:

import { maxUint256, type Hex } from "viem";

const swapOperator = mlAsLpVault.deployment.addresses.multiliquidSwap;

async function setAutoLegAllowance(assetInID: Hex, target: bigint) {
  const current = await mlAsLpVault.swap.getSwapInputAllowance(
    lpVault,
    swapOperator,
    assetInID,
  );

  if (current === target) return;

  await mlAsLpVault.swap.adjustSwapInputAllowance({
    operator: swapOperator,
    assetInID,
    amount: target > current ? target - current : current - target,
    increase: target > current,
  });
}

// Required for USDC sweep into Multiliquid Treasury.
await setAutoLegAllowance(sweepInputStablecoinID, maxUint256);

// Optional: required only for prefunded JIT redemption from $TSY.
await setAutoLegAllowance(liquidTreasuryID, maxUint256);

For the USDC allowance:

0 leaves Multiliquid Treasury sweep disabled for USDC; the user-requested leg can continue without the sweep.
A sufficient positive allowance enables USDC sweep into Multiliquid Treasury.
A positive but insufficient allowance causes the complete user transaction to revert atomically.

type(uint256).max is treated as unlimited and is not decremented by successful swaps. A bounded allowance is decremented as it is spent and must include enough headroom for execution-time amounts.

4. Capital Provider + Operator: Verify Enablement

The capital provider operations team first confirms that the capital provider domain points to Multiliquid Treasury:

const configuredDestination =
  await ml.swap.getAutoLiquidityStablecoinID(lpStablecoinID);

if (configuredDestination !== liquidTreasuryID) {
  throw new Error("Multiliquid Treasury is not configured for this capital provider domain");
}

The capital provider operations team can then preview an eligible USDC-input route:

import { ROUTE_IDS } from "@uniformlabs/multiliquid-evm-sdk";

const userRequestedInput = {
  routeId: ROUTE_IDS.STABLE_TO_RWA_EXACT_IN,
  assetInID: sweepInputStablecoinID,
  assetOutID: rwaID,
  stablecoinDelegateID: lpStablecoinID,
  assetInAmt: exactInput,
  assetOutAmt: minimumOutput,
};

const preview = await ml.swap.getAutoLiquidityPreview({
  user: userAddress,
  input: userRequestedInput,
});

console.log("Capital provider vault:", preview.lpVault);
console.log("Multiliquid Treasury sweep:", preview.sweep);

The preview reports USDC sweep eligibility, the estimated input amount, the capital provider vault balance, and the standing protocol allowance. The final sweep amount remains unknown until execution because MultiliquidSwap measures the capital provider vault balance delta around the user-requested leg. The execution operator should simulate the final bounded transaction with the actual user, operator, receiver, and permit:

const quote = await ml.quote.quoteSwap({
  user: userAddress,
  input: userRequestedInput,
  simulate: true,
  operator: operatorAddress,
  receiver: receiverAddress,
  permit,
});

console.log("Settlement simulation:", quote.simulation);

Simulation exercises current user funds, capital provider balances, ERC-20 approvals, standing allowances, prices, whitelists, and delegate settlement state.

Change or Disable Auto-Sweep

Disable One Sweep Input

The capital provider vault sets that input asset’s standing protocol allowance to zero using the setAutoLegAllowance helper. This disables Multiliquid Treasury sweep for that asset without affecting other sweep inputs or user-requested swaps. Revoking the protocol allowance does not revoke the token’s ERC-20 approval. The capital provider vault revokes both controls if the Treasury Delegate should no longer be able to pull that asset from custody.

Stop Using Prefund but Keep Sweep

The capital provider cannot rewrite the user’s route during execution. The capital provider coordinates with user-facing integrators to use base route IDs 2, 3, 6, or 7 instead of prefunded routes 8–11. This stops Multiliquid Treasury prefund requests while leaving Multiliquid Treasury sweep available on otherwise eligible stablecoin-input routes.

Disable All Automatic Legs

import { zeroHash } from "viem";

await ml.issuerAdmin.setAutoLiquidityStablecoinID({
  stablecoinID: lpStablecoinID,
  autoLiquidityStablecoinID: zeroHash,
});

Setting zero disables Multiliquid Treasury prefund and sweep for the capital provider delegate. The capital provider admin should notify integration partners before disabling it: a user-requested prefunded route does not fall back to its base route and will revert while Auto-Sweep is disabled. Existing protocol allowances and ERC-20 approvals remain stored, so the capital provider vault removes them separately when retiring the configuration.

Re-Enable Multiliquid Treasury

The capital provider admin can restore liquidTreasuryID after confirming the Treasury Delegate whitelist, per-asset terms, custody inventory, token approvals, and protocol allowances. The restored configuration applies immediately to subsequent user-requested swaps that select the capital provider delegate.

Monitoring

For capital provider reconciliation, every user-requested and derived capital provider leg emits its own unified Swap event:

Derived Multiliquid Treasury prefund events use stablecoin-to-stablecoin exact-out route 7.
Derived Multiliquid Treasury sweep events use stablecoin-to-stablecoin exact-in route 6.
For derived capital provider events, the event’s user and receiver are the capital provider vault, and its operator is MultiliquidSwap.
For the user-requested event, the user, receiver, operator, and requested route remain the user transaction’s values.

The REST API counts automatic Multiliquid Treasury prefund and sweep legs as realized swap legs in transaction history and volume analytics. The capital provider reporting pipeline should distinguish the user-requested leg from internal Multiliquid Treasury legs using the route together with the user, receiver, and operator; route 6 or 7 alone is not sufficient because users can also request those routes directly.

Multiliquid Treasury

Multiliquid Treasury token, credit, and yield mechanics

MultiliquidSwap

Automatic-leg execution mechanics

Overview

Core Components

Applications

Integration

How It Works

Prefund

Sweep

Route Behavior

Who Controls Each Part

Capital Provider Enablement Steps

Configuration Values

1. Capital Provider Admin: Select Multiliquid Treasury

2. Capital Provider Vault: Approve the Treasury Delegate

3. Capital Provider Vault: Grant Standing Protocol Allowances

4. Capital Provider + Operator: Verify Enablement

Change or Disable Auto-Sweep

Disable One Sweep Input

Stop Using Prefund but Keep Sweep

Disable All Automatic Legs

Re-Enable Multiliquid Treasury

Monitoring

Multiliquid Treasury

MultiliquidSwap

​How It Works

​Prefund

​Sweep

​Route Behavior

​Who Controls Each Part

​Capital Provider Enablement Steps

​Configuration Values

​1. Capital Provider Admin: Select Multiliquid Treasury

​2. Capital Provider Vault: Approve the Treasury Delegate

​3. Capital Provider Vault: Grant Standing Protocol Allowances

​4. Capital Provider + Operator: Verify Enablement

​Change or Disable Auto-Sweep

​Disable One Sweep Input

​Stop Using Prefund but Keep Sweep

​Disable All Automatic Legs

​Re-Enable Multiliquid Treasury

​Monitoring

Multiliquid Treasury

MultiliquidSwap

How It Works

Prefund

Sweep

Route Behavior

Who Controls Each Part

Capital Provider Enablement Steps

Configuration Values

1. Capital Provider Admin: Select Multiliquid Treasury

2. Capital Provider Vault: Approve the Treasury Delegate

3. Capital Provider Vault: Grant Standing Protocol Allowances

4. Capital Provider + Operator: Verify Enablement

Change or Disable Auto-Sweep

Disable One Sweep Input

Stop Using Prefund but Keep Sweep

Disable All Automatic Legs

Re-Enable Multiliquid Treasury

Monitoring