Updates: v1 to v2 - Multiliquid Protocol

Overview

Multiliquid V2 keeps the protocol’s NAV-based exchange model while consolidating the integration surface and adding delegated execution, atomic batching, and automatic liquidity management. This page collects the V1-to-V2 comparison in one place; the other Core Components pages describe the current protocol directly.

Unified execution

One quote function and one swap function cover every exact-in and exact-out route.

Delegated workflows

Standing allowances and EIP-712 permits support operators, relayers, and institutional execution.

Atomic batches

One signed transaction can execute multiple independently specified legs.

Integrated liquidity

LPs can opt into automatic prefunding and sweeping with a designated liquidity stablecoin.

At a glance

Area	V1	V2
Quote surface	Route-specific calculation functions	`quoteSwap(user, inputs)`
Execution surface	Route-specific swap functions	`swap(user, receiver, inputs[], permit)`
Routing	Function selection determined the route	`routeId` selects one of 12 route variants
Identities	The caller was the user and receiver	User, operator, and receiver are explicit
Operator approval	Direct execution	Standing input allowances or one-shot EIP-712 permits
Transaction shape	One swap operation	Ordered, atomic multi-leg batches
Protocol fees	User-paid volume tiers	LP-funded fee plus a protocol share of LP spread
Liquidity workflow	Liquidity managed outside the swap call	Optional automatic prefund and sweep legs
Events	Route-specific execution events	One `Swap` event for every requested or derived leg

Unified pricing and execution

V1 exposed separate functions for each route direction and amount mode. Quote functions mirrored the execution functions, so integrations selected both a route-specific calculation method and its matching swap method. V2 represents every route with the same SwapInputs structure:

struct SwapInputs {
    uint256 routeId;
    bytes32 assetInID;
    bytes32 assetOutID;
    bytes32 stablecoinDelegateID;
    uint256 assetInAmt;
    uint256 assetOutAmt;
}

Integrations now use:

function quoteSwap(address user, SwapInputs calldata inputs)
    external
    view
    returns (SwapResolved memory outputs);

function swap(
    address user,
    address receiver,
    SwapInputs[] calldata inputs,
    ApprovalPermit calldata permit
) external;

The route ID encodes both direction and amount mode:

Route IDs	Direction	Amount modes
`0`, `1`	Stablecoin → RWA	Exact-in, exact-out
`2`, `3`	RWA → stablecoin	Exact-in, exact-out
`4`, `5`	RWA → RWA	Exact-in, exact-out
`6`, `7`	Stablecoin → stablecoin	Exact-in, exact-out
`8`, `9`	Prefunded RWA → stablecoin	Exact-in, exact-out
`10`, `11`	Prefunded stablecoin → stablecoin	Exact-in, exact-out

Even route IDs are exact-in and odd route IDs are exact-out. The unified pricing engine applies the same decimal normalization, NAV conversion, fee accounting, and conservative rounding rules across route families.

User, operator, and receiver separation

V1 used msg.sender as the economic user and output recipient. V2 names each role independently:

user owns the input assets, protocol permissions, and yield credits.
operator is msg.sender, the account that submits the transaction.
receiver receives the requested output assets.

Direct swaps remain straightforward: the user submits the transaction and can choose a receiver. Delegated swaps allow a router, relayer, smart account, or institutional operator to execute within the scope authorized by the user.

Fee model

V1 charged the user a global protocol fee tier based on the size of an individual transaction. V2 separates protocol economics from LP pricing:

Fee component	Paid by	Purpose
Treasury management fee	Yield generated by Treasury	The configured management rate is separated from the posted portfolio APY
LP-funded protocol fee	Stablecoin LP domain	Configurable rate reported as `issuerFeeAmt`, separate from the user’s route value
Protocol spread fee	User route value	Protocol share of the spread created by the LP’s discount and redemption or acceptance settings
Explicit LP fee	Route-dependent	Redemption or acceptance fee reported as `lpFeeAmt` when the route applies it explicitly

SwapResolved and the unified Swap event expose the amounts as issuerFeeAmt, spreadFeeAmt, and lpFeeAmt.

Worked RWA-to-stablecoin example

Assume:

Gross RWA value: $1,000 (500 tokens at $2.00)
LP discount: 10%
RWA redemption fee used to measure the LP spread: 20%
Protocol share of that spread: 5%
LP-funded protocol fee: 10 bps

The LP spread is:

1 / (1 - redemption fee) - (1 - discount)
= 1 / (1 - 0.20) - (1 - 0.10)
= 1.25 - 0.90
= 0.35

The protocol spread rate is 5% × 0.35 = 1.75%. Applied to the gross value, that is $17.50.

Component	Amount
Gross RWA value	`$1,000.00`
10% LP discount	`-$100.00`
1.75% protocol spread fee	`-$17.50`
Stablecoin output to user	`$882.50`
10 bps LP-funded protocol fee	`$1.00`
Total protocol fees	`$18.50`
Aggregate stablecoin settlement from LP domain	`$901.00`

The LP-funded fee is reported separately and does not reduce the user’s $882.50 output. For a balance-sheet delegate, the LP domain settles the user output and both protocol fee amounts. Mint-and-burn delegates mint the same resolved amounts to their respective recipients.

Durable swap allowances

V2 adds protocol-level standing permissions:

swapInputAllowances[user][operator][assetInID]

Users update them with:

function adjustSwapInputAllowance(
    address operator,
    bytes32 assetInID,
    uint256 amount,
    bool increase
) external;

Key behavior:

Authorization is scoped to one user, operator, and input asset.
The allowance is spent by the resolved input amount, including on exact-out routes.
type(uint256).max acts as an infinite allowance.
A standing allowance can be used only when receiver == user.
ERC-20 approval to the relevant stablecoin delegate is still required for token movement.

This model supports trusted routers, programmatic rebalancing, triggered orders, and LP auto-liquidity without granting a reusable right to redirect a user’s outputs.

One-shot EIP-712 permits

V2 also supports “sign once, execute once” authorization with independent user, operator, and receiver addresses. The user owns the inputs and signs the permit, the operator submits the transaction, and the receiver receives the output. All three roles can use different addresses. The signed SwapInputs[] can contain one requested leg or an ordered multi-leg batch. Batch execution is supported, but identity separation is the permit’s primary purpose. The permit binds:

The user, operator, and receiver
The full ordered SwapInputs[] array
Every route ID, asset ID, delegate ID, amount, and execution bound
The user’s current nonce
The signature deadline
The chain ID and MultiliquidSwap verifying contract

The EIP-712 domain name is MultiliquidSwap and its version is 2. Signatures support standard ECDSA, compact EIP-2098, ERC-1271 contract accounts, and EIP-7702 delegated EOAs. A successful swap consumes one nonce for the complete signed execution. If any part of settlement reverts, the nonce change reverts with it. This authorization mode supports gas-sponsored flows, delayed execution, market-maker fills, and institutional signing policies without creating a durable protocol allowance.

Ordered multi-leg swaps

V2 accepts an ordered array of requested legs in one swap call. Every leg can use a different route, asset pair, LP delegate, and exact-in or exact-out mode. The complete batch is atomic and is limited by the protocol’s configured maximum leg count. Legs do not implicitly feed their outputs into the next leg. Applications that want chained execution calculate the intermediate bounded amounts offchain and submit those legs explicitly. This structure supports portfolio rebalancing, multi-order execution, batch optimization, and signed workflows that must either settle completely or not at all.

Automatic liquidity prefund and sweep

V2 lets a stablecoin LP configure an autoLiquidityStablecoinID, typically selecting a yield-bearing stablecoin held by its custody account.

Prefund

Prefunded routes 8–11 express that the requested stablecoin-output leg can derive an internal stablecoin-to-stablecoin exact-out leg immediately before execution. The derived leg:

Calculates the stablecoin amount needed for the requested swap.
Uses the LP custody account as the LP user and receiver.
Converts the configured auto-liquidity stablecoin into the required output stablecoin.
Spends the LP’s standing swap allowance to MultiliquidSwap.
Settles atomically with the user’s requested leg.

The prefund conversion is skipped when the configured auto-liquidity stablecoin is already the required output asset.

Sweep

After eligible stablecoin-input routes, the contract can measure stablecoin inventory received by the LP custody account and convert that balance into the configured auto-liquidity stablecoin. A sufficient standing allowance from the custody account opts into the sweep; without one, the requested user leg can still proceed without the derived sweep. Together, prefund and sweep let an LP hold working liquidity in a designated yield-bearing asset while making other accepted stablecoins available at execution time.

Integration migration checklist

Replace route-specific quote calls with quoteSwap(user, inputs).
Replace route-specific execution calls with swap(user, receiver, inputs[], permit).
Map each direction and exact-in or exact-out mode to route IDs 0–11.
Build exact-in bounds as an exact assetInAmt and minimum assetOutAmt; build exact-out bounds as a maximum assetInAmt and exact assetOutAmt.
Handle issuerFeeAmt, spreadFeeAmt, and lpFeeAmt in quotes and events.
Choose direct execution, a standing input allowance, or an EIP-712 one-shot permit.
Treat multi-leg inputs as an ordered atomic batch without implicit chaining.
Continue managing ERC-20 approvals separately from protocol operator authorization.
Index the unified Swap event for both requested and internally derived liquidity legs.

Next: Integration Guide

Build quotes, approvals, permits, and swaps with the Multiliquid EVM SDK.

​Overview

Unified execution

Delegated workflows

Atomic batches

Integrated liquidity

​At a glance

​Unified pricing and execution

​User, operator, and receiver separation

​Fee model

​Worked RWA-to-stablecoin example

​Durable swap allowances

​One-shot EIP-712 permits

​Ordered multi-leg swaps

​Automatic liquidity prefund and sweep

​Prefund

​Sweep

​Integration migration checklist