> ## Documentation Index
> Fetch the complete documentation index at: https://docs.multiliquid.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Updates: v1 to v2
> Integration-facing changes in Multiliquid V2
## 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.
One quote function and one swap function cover every exact-in and exact-out
route.
Standing allowances and EIP-712 permits support operators, relayers, and
institutional execution.
One signed transaction can execute multiple independently specified legs.
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:
```solidity theme={null}
struct SwapInputs {
uint256 routeId;
bytes32 assetInID;
bytes32 assetOutID;
bytes32 stablecoinDelegateID;
uint256 assetInAmt;
uint256 assetOutAmt;
}
```
Integrations now use:
```solidity theme={null}
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:
```text theme={null}
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:
```solidity theme={null}
swapInputAllowances[user][operator][assetInID]
```
Users update them with:
```solidity theme={null}
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:
1. Calculates the stablecoin amount needed for the requested swap.
2. Uses the LP custody account as the LP user and receiver.
3. Converts the configured auto-liquidity stablecoin into the required output
stablecoin.
4. Spends the LP's standing swap allowance to `MultiliquidSwap`.
5. 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
1. Replace route-specific quote calls with `quoteSwap(user, inputs)`.
2. Replace route-specific execution calls with
`swap(user, receiver, inputs[], permit)`.
3. Map each direction and exact-in or exact-out mode to route IDs `0`–`11`.
4. Build exact-in bounds as an exact `assetInAmt` and minimum `assetOutAmt`;
build exact-out bounds as a maximum `assetInAmt` and exact `assetOutAmt`.
5. Handle `issuerFeeAmt`, `spreadFeeAmt`, and `lpFeeAmt` in quotes and events.
6. Choose direct execution, a standing input allowance, or an EIP-712 one-shot
permit.
7. Treat multi-leg inputs as an ordered atomic batch without implicit chaining.
8. Continue managing ERC-20 approvals separately from protocol operator
authorization.
9. Index the unified `Swap` event for both requested and internally derived
liquidity legs.
Build quotes, approvals, permits, and swaps with the Multiliquid EVM SDK.