Skip to content

Conversation

@nicholaspai
Copy link
Member

@nicholaspai nicholaspai commented Dec 11, 2025

The initial feature set of inventory manager 2.0 will support swapping cross chain between USDC and USDT. It should plug in seamlessly into the existing inventory client.

Features

Defines a new module under src/rebalancer designed to be used by the same accounts that run the relayer programs including the --relayer and --rebalancer processes. The new module can be run with the temporary --rebalancer2 flag.

Requirements

rebalancer is backwards compatible with the existing inventory client logic and its designed to be aware of all pending rebalances sent by the inventory client.

Implementation

We will define a new configuration which will be a set of USDC/USDT target balances across all chains supported by Hyperliquid/Binance.

The IM 2.0 will compare those target balances against current balances as returned by the inventoryClient which will include any virtual balance modifications we currently make. This will produce a set of excesses and deficits, which the IM 2.0 will then attempt to reconcile by swapping between Hyperliquid and Binance. If there is no fortunate matching of excesses and deficits then the IM 2.0 will do nothing.

The IM 2.0 will also expose a function getPendingRebalances that can be used by the inventoryClient so that it doesn’t double count any inventory that gets swapped by the IM 2.0.
The initial version of IM 2.0 will not support same asset to same asset bridging, like we currently do with CCTP/OFT, but eventually it should implement this logic and take it away from the inventory client.

Structure

  • Adapters
  • Controller (issues new rebalances)

Integration with Inventory Client

  • Keeping balances in sync (supplying block ranges)

… 2.0

This PR is designed to open the discussion on designing an improved inventory manager system that supports the following features:
- Allows arbitrary any to any rebalances
- Allows user to specify target balances instead of percentages, which are easier to reason about

The current system is limited to L1->L2 and L2->L1 flows and it handles them separately with different clients, this makes the code harder to maintain and also difficult to implement L2 to L2 rebalancing.
next up is to place an order in initializeRebalances
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants