VDB-57: VIP-660 [BNB Chain] September 2026 Prime Allocation

[trumpgpt-bot]

VIP-660 [BNB Chain] September 2026 Prime Allocation

Summary

This proposal sets the September 2026 Prime reward allocation on BNB Chain — $80K in total, split 80/20 ($64K to USDT suppliers and $16K to U borrowers) — and ends wBNB Prime rewards. It is the first month U is a Prime market, and the first Prime market scored on the borrow side rather than the supply side. It also rebalances the PrimeLiquidityProvider's reward inventory toward USDT to match that split. Refer to the community post for the full background and rationale.

Actions

This VIP performs the following actions on BNB Chain:

1. Enable the U market for Prime on the borrow side — addMarket(vU, supplyMultiplier = 0, borrowMultiplier = 2e18) on PrimeV2. Prime scores in this market derive only from U borrowed; a pure vU supply position earns no Prime score. The 2x factor mirrors the existing supply-side markets (vUSDT / vWBNB, supplyMultiplier = 2e18), applied to the borrow leg instead. Adding a market queues a one-time score-update round across all 500 current Prime holders, drained by updateScores calls (at most 20 holders per call). Until that round completes, claimPrime, issue and burn on PrimeV2 revert with ScoreUpdateInProgress, and a holder's U borrow starts counting toward their Prime score once their own score has been updated. This is inherent to any PrimeV2 market change and clears as soon as the round is drained.
2. USDT market — set the Prime reward speed to 0.011111111111111111 USDT per block, distributing ~$64K to USDT suppliers over September 2026 (5,760,000 blocks at 192,000 blocks/day), up from ~$49K in August.
3. U market — set the Prime reward speed to 0.002777777777777777 U per block, distributing ~$16K to U borrowers over September 2026.
4. wBNB market — set the Prime reward speed to 0, ending wBNB Prime rewards (~$21K in August). wBNB already accrued to claimants stays claimable; only further accrual stops.
5. Reward-inventory rebalance — transfer 12,000 U (≈ $12K) from the PrimeLiquidityProvider to the Venus dev recipient (0x080f8A0fB70F8F0F1b83C6178225a96CbE2BE0DE) for off-chain conversion into USDT, which is returned to the PrimeLiquidityProvider. Prime's share of protocol revenue reaches the PrimeLiquidityProvider through the two buyback contracts set up in VIP-620, one converting into USDT and one into U; over the past 30 days they delivered ~29.8K USDT and ~29.9K U, an effectively 50/50 split. That leaves the contract's inventory balanced (~36.0K USDT free vs ~35.8K idle U) while this month's distribution is 80/20 in favour of USDT, so part of the U is converted to USDT.

Actions 2–4 are a single setTokensDistributionSpeed call on the PrimeLiquidityProvider; action 5 is a sweepToken call on the same contract. The Normal Timelock holds the PrimeV2 addMarket and PrimeLiquidityProvider setTokensDistributionSpeed ACM permissions and owns the PrimeLiquidityProvider, so no ACM grants are needed. The Critical Timelock's privileges were removed in VIP-645, so — as with the August allocation — this proposal is submitted as a Normal VIP.

Funding the reward legs

• USDT — the PrimeLiquidityProvider holds ~53.7K USDT, of which ~17.7K is already accrued to claimants, leaving ~36.0K free against the $64K September leg, and that free balance keeps shrinking by ~1.6K USDT per day at the current August speed until execution. The 12,000 USDT returned from action 5, together with the USDT buyback inflow over the month (~29.8K over the past 30 days), covers the remainder. accrueTokens caps accrual at the available balance and does not backfill, so the USDT leg depends on the off-chain conversion landing promptly after execution.
• U — the contract holds ~35.8K U, all idle (distribution speed and accrued amount both zero), so the sweep takes nothing from Prime claimants and the remaining ~23.8K U covers the $16K U leg with margin.

U, USDT and wBNB are already configured reward tokens on the PrimeLiquidityProvider (each with a max distribution speed of 1e18, unchanged here), so no initializeTokens or setMaxTokensDistributionSpeed call is needed.

References

• VIP simulation
• VIP-637 — PrimeV2 launch (vUSDT / vWBNB supply-side markets)

Voting options

• For — Execute the proposal
• Against — Do not execute the proposal
• Abstain — Indifferent to execution

---

Tests: npx hardhat test simulations/vip-660/bscmainnet.ts --fork bscmainnet → 16 passing. yarn lint 0 errors, prettier clean. propose() via proposer Safe requiredGasLimit ≈ 1.26M (7.5% of the 16.78M per-tx cap).

Originally opened by the Venus dev bot as VIP-665; renumbered to VIP-660 at proposal time (on-chain proposalCount = 659).

[greptile-apps]

Greptile Summary

Adds VIP-665 for the September 2026 BNB Chain Prime allocation.

• Adds vU to PrimeV2 with borrow-only scoring at a 2× multiplier.
• Sets USDT and U reward speeds for the September allocation and disables WBNB rewards.
• Adds fork simulation coverage for proposal execution, emitted events, market configuration, reward speeds, token configuration, and speed limits.
• Adds the PrimeV2 and PrimeLiquidityProvider ABIs used by the simulation.

Confidence Score: 5/5

The PR appears safe to merge, with the governance actions and resulting state covered by the included fork simulation.

The proposal uses established BNB Chain reward-speed conventions, targets the expected PrimeV2 and liquidity-provider interfaces, and successfully verifies both actions and their post-execution state on a representative fork.

Important Files Changed

Filename	Overview
vips/vip-665/bscmainnet.ts	Defines the two regular-governance actions, allocation constants, addresses, and proposal metadata; no actionable defect was identified.
simulations/vip-665/bscmainnet.ts	Exercises the proposal on a BNB Chain fork and verifies pre-state, execution events, market registration, multipliers, distribution speeds, and configured maxima.
simulations/vip-665/abi/PrimeV2.json	Supplies the PrimeV2 interface required to execute and inspect the new three-argument addMarket action in simulation.
simulations/vip-665/abi/PrimeLiquidityProvider.json	Supplies the PrimeLiquidityProvider interface required to execute and validate reward-speed updates in simulation.

_{Reviews (1): Last reviewed commit: "vip-665: September 2026 Prime allocation..." | Re-trigger Greptile}

[vancegpt-bot]

Squad review — round 1, head ffd1251

Result: no material findings. Review loop closed clean (round 1 of a 3-round cap).

Dimensions run: Code Quality (clean) and VIP review (clean). All values below were read from BSC mainnet, not from the diff; the simulation was independently reproduced — 14/14 passing at the pinned fork block 118190000.

Verified

• 3-arg addMarket is real. PrimeV2 proxy 0x059EabA8… → impl 0x18cb7198… (BscScan-verified) exposes selector 0xc0ffb809 = addMarket(address,uint256,uint256), no 4-arg variant. The checked-in PrimeV2.json matches the deployed ABI exactly (119/119 entries). vU is not yet a Prime market (markets(vU).exists = false; getAllMarkets() = [vUSDT, vWBNB]), duplicate adds revert, and supplyMultiplier = 0 is accepted (only both-zero reverts).
• Borrow-side semantics of (0, 2e18). A pure vU supply position earns no score; a U borrower's capital is min(borrowUSD, 2 × stakedXVS_USD) with alpha (1/2) unchanged. Adding vU does not redistribute rewards away from vUSDT/vWBNB: each market accrues only its own underlying's PLP stream.
• Speed arithmetic. Both speeds floor-truncate (63,999.999… USDT and 15,999.999… U per month), matching the stated $64K/$16K; both are under the on-chain maxTokensDistributionSpeed of 1e18. Convention (192000 × 30, floor division) matches VIP-652. Oracle prices at head: USDT $0.9994, U $0.9991 — $1 accounting is defensible.
• wBNB → 0 is safe. _setTokenDistributionSpeed accrues before changing the speed, so the ~1.36 wBNB already accrued settles and stays claimable; nothing is stranded. U is already an initialized PLP token, so "no initializeTokens or setMaxTokensDistributionSpeed needed" is correct. Exactly 3 TokenDistributionSpeedUpdated events fire (all three speeds actually change).
• Funding. USDT free ≈ 36.6K now (draining ~1,633/day at August's speed → ~31–32K at execution); U free ≈ 35.8K already over-funds the $16K U leg. Measured PLP inflow over the last 30 days: 44,225 USDT and 37,336 U. At that run-rate the $64K USDT leg closes with ~12K margin — the author's "no U→USDT swap this month" conclusion holds, contingent on September buyback inflow continuing at roughly August's pace. A shortfall would only pause distribution (PLP accrual caps at balance); it cannot strand claimant funds.
• Permissions / proposal type. Normal Timelock holds the exact ACM roles for both signatures; Critical Timelock holds neither (consistent with VIP-645); PLP owner() = Normal Timelock. ProposalType.REGULAR is right and matches VIP-652.
• Description claims. PrimeV2 provenance (VIP-637), comptroller stored on-chain, the "mirrors the 2x factor" claim (vUSDT/vWBNB read back 2e18/0), the community-post link, and VIP number 665 (no collision on main or open PRs) all check out.
• Simulation quality. Fork block pinned; pre-state asserts vU non-membership three ways and the live August speeds (still current at head — no fork-vs-now divergence); post-state reads multipliers and speeds back from the contracts.

Non-blocking follow-ups (optional; none block this PR)

1. meta.description omission: addMarket queues a score-update round over all ~500 Prime holders, during which claimPrime/issue/burn revert with ScoreUpdateInProgress and holders earn no vU score until updateScores completes. One voter-facing sentence noting this temporary freeze would help (it is inherent to every PrimeV2 market/multiplier change, not specific to this PR).
2. simulations/vip-665/bscmainnet.ts:70 — event assertions are count-only (MarketAdded ×1, TokenDistributionSpeedUpdated ×3); argument-level assertions would be stronger. Substance is already covered by the post-state readbacks.
3. simulations/vip-665/abi/PrimeLiquidityProvider.json — the fixture is not the deployed implementation's ABI (extra getBlockNumber()/proxy-admin entries; 6 deployed entries missing, e.g. isTimeBased()). Tests are unaffected; regenerating from impl 0x46bed43b… would fix the drift.
4. simulations/vip-665/bscmainnet.ts:26 — comment references an out-of-repo Notion doc a future reader cannot check; the VIP-652 convention is a single sentence stating the speeds are the on-chain values at the fork block.
5. simulations/vip-665/bscmainnet.ts:91-93 — the "wBNB Prime rewards are ended" test repeats the zero-speed assertion from line 87 verbatim; it could be folded into one test.

Reviewed by the Get Things Done squad (Code Quality + VIP reviewers), consolidated by the squad lead. Tracker: VENUS-257.

[vancegpt-bot]

Squad review — round 2 (final), head 2f21310

Verdict: no blockers to execution. Everything the proposal executes — targets, signatures, parameters, speeds, permissions — was verified on-chain in round 1 and is byte-identical at this head. Two wording defects remain open in the voter-facing meta.description (details below); they are one-line text fixes and the only open items. The squad review loop is now closed at its 2-round cap, so their disposition is a human call: fix before merge (recommended — the description is permanent proposal calldata) or accept as-is.

Delta verified (ffd12517..2f213104, one commit, 3 files)

Nothing that executes changed: both targets, both signatures, and every parameter/constant are identical between heads. The only hunk in vips/vip-665/bscmainnet.ts is inside the meta.description template string (note: this does change the proposed calldata — intentionally, description text only). Simulation independently re-run: 13/13 passing at the same pinned fork block 118190000.

Round-1 follow-up closure

#	Item	Verdict
1	Freeze sentence in meta.description	Partially fixed — sentence added, mostly accurate, two clauses defective (below)
2	Count-only event assertions	Fixed — argument-level withArgs added and verified against deployed source and on-chain state at the fork block (incl. U previous speed = 0, USDT 8506944444444444, wBNB 6166906433170)
3	PLP ABI fixture drift	Fixed — exact entry-for-entry match with deployed impl 0x46bed43b… (58/58 after canonical sort)
4	Out-of-repo (Notion) comment	Fixed — self-contained sentence matching the VIP-652 convention
5	Duplicate wBNB test	Fixed — folded with equivalent coverage; the explicit == 0 literal now pins the constant

Open items — vips/vip-665/bscmainnet.ts:60 (voter-facing description)

1. "no vU Prime score accrues" until the round finishes — inaccurate. vU score goes live per holder as each holder's score is updated: partial updateScores batches mark users one by one, and any vU interaction through the Comptroller hook (permissionless accrueInterestAndUpdateScore) or an XVS-stake change updates that holder immediately. Early-updated holders share the full $16K/mo U stream while not-yet-updated holders earn nothing from vU. The freeze gates claimPrime/issue/burn, not scoring.
2. "resolves once the score update completes" — implies self-resolution. Nothing on-chain drives the round: updateScores is permissionless but keeper-driven, batches capped at 20 loops (≥25 transactions at ~500 holders). Claim functions revert until someone runs it — minutes-scale with a prompt keeper, indefinite without one.

New non-material nit (listed only because this is the final round): simulations/vip-665/bscmainnet.ts:73-74 — a two-line comment restates what the withArgs calls and constant names already show.

Dimensions this round

VIP review — clean (no-logic-change proof, event args vs chain, ABI fidelity, sim re-run). Functional Correctness — the two description findings above; fresh sweep of the change surface otherwise clean (speed math exact, addMarket preconditions hold, action ordering safe). Code Quality — clean, one nit.

Squad review loop closed at its 2-round cap (cap set by Aditya). Reviewed by the Get Things Done squad; consolidated by the squad lead. Tracker: VENUS-257 / VENUS-260. Round-1 review: comment.

[fred-venus]

https://venus.io/#/governance/proposal/660?chainId=1

[fred-venus]

Next step once vip get executed --> VenusProtocol/venus-protocol#709