[BSC] Institutional Fixed Rate Vaults — Activation

This proposal activates the Institutional Fixed Rate Vault system on BNB Chain and upgrades the ProtocolShareReserve to support it. The system introduces fixed-rate, time-bound, overcollateralized vaults intended for whitelisted institutional borrowers, with a dedicated liquidation flow operating independently from the existing Core Pool.

Background

Venus’ Core Pool serves the broad retail and DeFi audience well, but its variable-rate, shared-liquidity model is not well suited to institutional credit, where borrowers require fixed cost, a fixed term, large committed size, and curated counterparty exposure. The Institutional Fixed Rate Vault system addresses that gap by introducing a primitive comparable in structure to established institutional-credit venues (e.g. Maple-style fixed-rate pools), implemented natively inside Venus governance.

Each loan is encapsulated in its own vault (a per-loan clone), so credit exposure is fully isolated rather than commingled with the Core Pool. Borrowers must be whitelisted before they can open a position, and the loan moves through a defined lifecycle — margin deposit, fundraising, locked term, and settlement — at the end of which the position is either matured, repaid early, or liquidated. Liquidations route through a dedicated LiquidationAdapter and a restricted liquidator whitelist, rather than the open Core-Pool liquidation flow.

Details

The activation introduces four new contracts to the Venus governance perimeter on BNB Chain:

  • InstitutionalVaultController — central registry and lifecycle manager. Governance creates and parameterizes vaults through this contract; it also issues the position-token NFT representing a borrower’s position.
  • InstitutionPositionToken — ERC-721 representing ownership of an institutional position. Transferability is gated by approvePositionTransfer so that positions remain bound to whitelisted parties.
  • LiquidationAdapter — the dedicated liquidation router for institutional vaults. Only whitelisted liquidators may submit liquidations, and only whitelisted settlers may finalize them. Protocol share from liquidations is forwarded to the ProtocolShareReserve.
  • ProtocolShareReserve (new implementation) — upgraded to recognize an additional income type produced by institutional-vault liquidations, so the corresponding protocol-share income is accounted for and distributed correctly.

The governance perimeter follows Venus’ standard timelock model. Sensitive risk-parameter setters — liquidation threshold, liquidation incentive, late-penalty rate, vault implementation — are restricted to the Normal, Fast-track, and Critical timelocks only, and are not exposed to the Critical Guardian. Vault lifecycle operations (create, open, pause, close, sweep) are available to the timelocks and the Critical Guardian. Plumbing setters (oracle, comptroller, treasury, ProtocolShareReserve) sit with the Normal Timelock and Critical Guardian.

At activation, the Critical Guardian is whitelisted as the initial liquidator and settler on the LiquidationAdapter. This allows the dedicated liquidation flow to operate under governance-bounded operational control from day one; additional whitelisted parties can be added later via subsequent VIPs.

:lock: No institutional vault is created by this VIP. Activation only deploys the governance scaffolding; individual vaults (per borrower, per term) will be created in follow-up VIPs once a borrower has been onboarded.

Summary

If approved, this VIP will:

  • Activate the Institutional Fixed Rate Vault system on BNB Chain (InstitutionalVaultController, LiquidationAdapter, InstitutionPositionToken) under Venus governance.
  • Wire the dedicated liquidation flow and whitelist the Critical Guardian as the initial liquidator and settler.
  • Upgrade the ProtocolShareReserve to recognize institutional-vault liquidation income.

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

6 Likes

As a Community Delegate, I think this is a very important evolution for Venus Protocol and one that makes a lot of sense strategically.

The Core Pool was designed extremely well for open DeFi markets, variable-rate lending and permissionless participation, but institutional credit has very different requirements:

• fixed borrowing costs
• predictable maturities
• isolated risk exposure
• curated counterparties
• operational control around liquidations and settlements

This proposal addresses those requirements without compromising the permissionless nature of the existing Core Pool. That separation is key.

I particularly like the architecture choice of isolated per-loan vaults rather than pooled institutional exposure. From a risk-management perspective, that is significantly cleaner and easier to reason about for governance, lenders and future institutional participants alike.

The dedicated liquidation flow and whitelist model also make sense in this context. Institutional borrowers are not retail users opening small leveraged positions. These are negotiated, overcollateralized credit facilities with operational requirements that differ from open-market liquidations.

A few things I appreciate here:

• No vaults are activated yet, only the infrastructure layer.
• Governance retains strong control through timelocks.
• Critical Guardian permissions appear intentionally scoped.
• ProtocolShareReserve integration ensures liquidation income accounting remains coherent.
• ERC-721 position representation opens interesting long-term possibilities for structured credit markets and transferable institutional exposure.

Most importantly, this expands Venus beyond being “just” a lending market and moves the protocol closer toward becoming a full on-chain credit infrastructure layer. That is a massive opportunity if executed carefully.

Of course, onboarding standards, borrower due diligence, collateral quality, liquidation operational procedures and governance transparency will matter enormously once actual vaults begin launching. Institutional credit can generate strong sustainable revenue, but it also introduces very different forms of risk than retail DeFi lending.

Overall, I think this is a thoughtful first step and I’m supportive of the direction. Looking forward to seeing further discussion around borrower onboarding frameworks, risk parameters and how governance intends to scale this model over time.

3 Likes