[BNB Chain] Liquidity Hub

This proposal activates the Liquidity Hub on BNB Chain for USDT, USDC and U. The Liquidity Hub gives each asset one place to deposit, and spreads that deposit across the available yield sources automatically.

Background

Today, lenders looking for the best stablecoin yield across Venus have multiple choices: the Core Pool, Venus Flux, and Institutional Fixed Rate Vaults, which lend to institutional borrowers at fixed rates for fixed terms. Because each venue offers a different rate, and the highest yield changes over time, users must actively monitor all options and manually move funds to wherever returns are best. This process is inefficient: it requires separate deposits, ongoing tracking, and repeated transactions, each with an associated cost. Since rates can change again soon after, many users simply leave funds where they were first deposited, resulting in lower returns than they might otherwise achieve.

The Liquidity Hub simplifies this into a single deposit experience. One Hub is deployed per asset and serves as the only entry point a lender needs for that asset. When a user deposits into the Hub, they receive a yield-bearing share token, while the Hub holds the underlying asset and allocates it across the three yield sources according to a governance-defined policy. As yield accrues, the redemption value of the share token increases automatically, meaning there is nothing additional for users to claim. At any time, the share token can be redeemed for the underlying asset.

Details

Every Hub connects to the same three yield sources. Governance sets two caps on each source — an absolute amount and a share of the Hub’s total assets — and the Hub allocates up to whichever of the two is lower. Deposits and withdrawals walk the sources in a fixed order, and the two orders differ:

Yield source Deposit priority Withdrawal priority Absolute cap Share of Hub assets
Venus Core Pool 1 2 2,000,000,000 tokens no limit
Venus Flux 2 1 7,000,000 tokens 20%
Institutional Fixed Rate Vaults not in queue 3 5,000,000 tokens 30%

The Core Pool receives deposits first: it has the longest track record and the deepest liquidity on BNB Chain. Venus Flux sits second on deposit and first on withdrawal, so it is filled by rebalancing rather than by new deposits and is drawn down first when a lender redeems — which leaves the larger Core Pool position as the deeper reserve. Its 20% share is the limit that binds at launch: a Hub holding 10,000,000 USDT can place at most 2,000,000 USDT in Venus Flux, with the remaining 8,000,000 USDT staying in the Core Pool.

The Fixed Rate Vault route is configured but receives nothing, because no fixed-rate vault exists for these three assets yet. It is kept out of the deposit queue and placed last on withdrawal; a later proposal will connect it once a vault is created.

Roles

Two multisigs operate the Hubs between governance votes, each with a deliberately one-directional set of powers:

  • The Operator handles routine work: moving funds between the connected yield sources, lowering caps, and pausing. It cannot connect a new yield source, change fees, or unpause.
  • The Guardian handles emergencies: it can pause a Hub, and can still move funds out of a yield source while that Hub is paused. It cannot unpause either.

Only governance can reverse a pause, connect or remove a yield source, or change fees. Management, performance and redemption fees all launch at zero; the mechanism exists so that governance can enable them later.

Each Hub is also seeded with a small deposit from the Venus Treasury at launch, and the resulting shares are permanently burned, so no Hub can ever return to an empty state.

Initial scope

This is the initial Liquidity Hub deployment, so it starts with three assets — USDT, USDC and U. Further assets will be proposed once these three Hubs have run in production and the routing policy has been observed at size. The caps above are a starting point rather than a target, and can be raised or lowered as the Hubs fill.

Because provisioning all three assets in a single transaction exceeds BNB Chain’s per-transaction gas limit, the launch is split across two proposals: the first onboards USDT and USDC, the second onboards U. The three Hubs are independent contract sets, and neither proposal changes anything about the other’s assets.

Summary

If approved, this VIP will:

  • Activate the Liquidity Hub on BNB Chain for USDT, USDC and U — one Hub per asset, each issuing a yield-bearing share token
  • Connect every Hub to the Venus Core Pool and to Venus Flux, under the caps and the queue order listed above
  • Configure the Institutional Fixed Rate Vault route on every Hub without funding it, pending a live vault for these assets
  • Seed every Hub from the Venus Treasury and burn the resulting shares, so no Hub can return to an empty state
  • Launch with management, performance and redemption fees all set to zero, and with no change to the Core Pool or Venus Flux markets themselves

We welcome community feedback on this proposal ahead of submitting it for a VIP vote.

1 Like

Very big product.

Very appreciated and believe it’s gonna be a great success.
Keep delivering product like this which fill a real need.

I’m supportive of the direction. One Hub per asset is the right shape. My questions are about what the Hub is optimising for, because the Background and the Details sections seem to point at different objectives.

The Background frames the problem as lenders failing to chase the best available rate and therefore earning less than they otherwise could. But the routing in Details is not rate-aware. Deposit priority is Core Pool first, Flux second, and Flux is explicitly filled by rebalancing rather than by new deposits. So if Flux is paying more at the moment I deposit, my deposit still goes to the Core Pool, and my blended rate sits below a direct Flux deposit until the Operator rebalances at its discretion, between governance votes.

Using the launch caps: a 10,000,000 USDT Hub can hold at most 2,000,000 in Flux, and the remaining 8,000,000 stays in Core regardless of the spread between the two.

That may well be the correct design. Core has the deeper liquidity and the longer track record, and a rate-chasing router would be far more fragile. But it means the Hub is a policy-driven allocator that produces yield, not a yield optimiser, and the proposal currently reads as if it is both at once.

1. Is it accurate to say the Hub maximises yield subject to a governance-defined liquidity policy, rather than maximising it outright? If so, I think that should be stated plainly, together with the benchmark users are meant to judge the Hub against: the best available venue, or the passive default most lenders actually sit in. Those are very different promises.

2. Management, performance and redemption fees launch at zero, but the mechanism exists for governance to enable them. So a depositor is accepting policy-constrained allocation today plus fee optionality against them later. What is the offsetting benefit for choosing the Hub over depositing directly? And when fees are eventually turned on, where does that revenue go: Treasury, XVS stakers, Prime? This is the part of the proposal that speaks to XVS holders, and it is currently unspecified.

3. Flux sits second on deposit and first on withdrawal, so Hub liquidity there is the most transient capital in the system, yet it will appear in Flux’s TVL indistinguishably from direct user demand. Will Hub-routed balances be reported separately, so per-product TVL still reflects genuine user preference?

A unified liquidity layer for the ecosystem is a strong long-term direction. But where yield maximisation and ecosystem liquidity management conflict and they will. I think the proposal should state which one takes priority, rather than leaving the impression that both are fully achievable at the same time.

A great update;

it’s great that users can automatically get the best returns without having to pay extra gas fees. I believe it will be a success.

Please keep rolling out updates that meet users’ real needs.