> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hyperlane.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# HWR 2.0: Native Rebalancing

## Overview

Chains want to allow users to deposit and withdraw tokens from multiple networks. However, manually managing token liquidity across all these chains can be complex and operationally intensive.

When deploying assets (like USDC, USDT, ETH) across multiple chains, liquidity gets unbalanced when:

* Users deposit tokens on Chain A but withdraw from Chain B
* Chain B runs out of tokens
* New users cannot withdraw from Chain B until someone manually moves tokens from Chain A to Chain B

Native Rebalancing automates this process. For cases where it doesn't apply, [Manual Rebalancing](#manual-rebalancing) is also covered below.

## The Solution: Native Rebalancing

**Hyperlane Warp Route (HWR) 2.0** eliminates the complexity of managing multi-chain token liquidity while enabling users to deposit tokens from any supported chain to the destination chain.

HWR 2.0 solves the liquidity imbalance problem with a new **Rebalancer Agent** and smart contract support. The Warp Route contracts have been upgraded to enable the new functionality, with a rebalancer role which the contract owner controls.

### Rebalancer

HWR 2.0 includes a built-in **Rebalancer.** The Rebalancer is a whitelisted agent that continuously monitors and manages collateral across all chains in the warp route. This agent uses native bridges like CCTP to automatically move funds between chains, maintaining optimal liquidity distribution.

For example, if users deposit USDC on Arbitrum and withdraw on Base, the Rebalancer can use CCTP to transfer USDC from Arbitrum to Base to maintain sufficient liquidity on Base.

### What Native Rebalancing enables

This enables:

* Deposits from any supported chain
* Withdrawals to any supported chain
* A seamless user experience

The rebalancer role can be operated by anyone the contract owner permits. Abacus Works offers this as a managed service, with rebalancing based on configurable thresholds and policies that determine when and how collateral should move.

## How it works

### Basic Setup

The diagram below shows a setup where canonical USDC exists on Base and Arbitrum, with a synthetic HWR created on a new chain.

```mermaid theme={null}
flowchart
    subgraph base
    BU((User))
    BWR[USDC Collateral HWR]
    end

    subgraph arbitrum
    AU((User))
    AWR[USDC Collateral HWR]
    end

    subgraph newchain
    NWR[USDC Synthetic HWR]
    Recipient((Recipient))
    end

    BU -- "transferRemote(newchain,<br>recipient, amount)" --> BWR
    BWR -. "{recipient, amount}" .-> NWR
    AU -- "transferRemote(newchain,<br>recipient, amount)" --> AWR
    AWR -. "{recipient, amount}" .-> NWR
    NWR -. "2 \* amount" .-> Recipient
```

### Collateral Imbalances

If more funds flow in one direction, one of the chains in the route can run out of collateral. This *imbalanced flow* prevents withdrawals until the collateral is rebalanced.

```mermaid theme={null}
flowchart
	subgraph base
		BWR[USDC Collateral HWR]
	end

	subgraph arbitrum
		AWR[USDC Collateral HWR]
	end

	subgraph newchain
		NWR[USDC Synthetic HWR]
		NU((Recipient))
	end

	NU -- "transferRemote(arbitrum,<br> recipient, 2 * amount)" --> NWR
	NWR -. "{recipient, 2 * amount}" .-> AWR
```

### Managing Collateral Imbalances

To maintain a smooth user experience, collateral must be balanced across chains. HWR 2.0 introduces native rebalancing capabilities that automate this process where supported — collateral is automatically moved between chains to resolve imbalances. For deployments without native rebalancing, this requires manually moving collateral between chains.

### USDC Rebalancing

For USDC, native rebalancing is handled directly via [Circle CCTP](https://developers.circle.com/cctp). The Rebalancer uses CCTP to move USDC between chains without any additional infrastructure.

**Requirements:**

* A Rebalancer Agent (the whitelisted agent that monitors and manages collateral)
* Warp Route contracts with rebalancer role support
* CCTP support on each participating chain

<Warning>
  Chains without CCTP support cannot use native rebalancing for USDC.
</Warning>

### Inventory Rebalancing

For tokens without native bridge support (USDT, ETH), Inventory Rebalancing fills the same role — automatically redistributing collateral across chains based on configurable thresholds via a cross-chain liquidity aggregator.

**How It Works:**

1. **Detect**: The Rebalancer monitors collateral levels across all chains in the route and identifies imbalances against configured thresholds
2. **Move**: Inventory is moved to the target chain via a cross-chain liquidity aggregator
3. **Deposit**: Collateral is deposited and withdrawn via the warp route contracts to restore balance

**Requirements:**

* The route must have on-chain inventory (collateral) on the chains to be rebalanced
* The HWR must support the Rebalancer role (HWR 2.0)
* Fee contracts must be deployed on each collateral leg of the HWR. These ensure rebalancing costs are covered and that the route remains economically sustainable.

Inventory Rebalancing supports USDT and ETH across EVM-compatible chains. Additional chains and assets are planned.

## Manual Rebalancing

<Note>
  This section is for advanced users managing liquidity manually. The automated
  rebalancer is recommended where available.
</Note>

### Liquidity Provider

Currently, Hyperlane Warp Routes 2.0 don't have an explicit liquidity provider interface that enables local deposits/withdrawals. However, LPs can manually manage liquidity using the [Hyperlane CLI](https://www.npmjs.com/package/@hyperlane-xyz/cli) or the UI to interact with the HWRs in the [Hyperlane registry](https://github.com/hyperlane-xyz/hyperlane-registry).

<Warning>
  The stopgap procedure defined below requires at least one synthetic chain to
  exist within the HWR topology.
</Warning>

* To inspect a HWRs topology, use the `warp read` command:

```
hyperlane warp read -w ETH/ethereum-base-bsc

ethereum:
    type: native
    ...
base:
    type: native
    ...
bsc:
    type: synthetic
    ...
```

* To send a transfer (`transferRemote`) on a HWR, use the `warp send` command:

```
hyperlane warp send \
	-w ETH/ethereum-base-bsc \
	--origin base \
	--destination bsc \
	--amount <AMOUNT> \
	--recipient <ADDRESS>
```

### Depositing Liquidity

LPs can deposit collateral via a `transferRemote` where:

* `destination` domain is a chain where the HWRs has a `synthetic` type
* `recipient` address is controlled by the LP
* `amount` is liquidity denominated in the `origin` chains `collateral` token

```mermaid theme={null}
flowchart
	LP((Liquidity Provider))

	subgraph arbitrum
		AWR[USDC Collateral HWR]
		AUSDC[USDC]
	end

	subgraph mychain
		MWR[USDC Synthetic HWR]
	end

	AWR -- "transferFrom(LP, amount)" --> AUSDC
	LP -. "amount" .-> AWR
	LP -- "transferRemote(newchain,<br>LP, amount)" --> AWR

	AWR -. "{LP, amount}" .-> MWR
	MWR -. "amount" .-> LP
```

This can be done by providing liquidity on many collateral chains and representing a claim on each collateral with a single synthetic asset balance.

### Withdrawing Liquidity

LPs can withdraw via a `transferRemote` where

* `destination` domain is a chain where the HWR is a `collateral` type
* `recipient` address is controlled by the LP
* `amount` is denominated in the `destination` chains `collateral` token

```mermaid theme={null}
flowchart
	LP((Liquidity Provider))

	subgraph arbitrum
		AWR[USDC Collateral HWR]
		AUSDC[USDC]
	end

	subgraph mychain
		MWR[USDC Synthetic HWR]
	end

	LP -- "transferRemote(arbitrum,<br>LP, amount)" --> MWR
	LP -. "amount" .-> MWR

	MWR -. "{LP, amount}" .-> AWR
	AWR -- "transfer(LP, amount)" --> AUSDC
	AWR -. "amount" .-> LP
```