VBT-7: VIP-633: sets the vUSDT (BSC Core Pool) supply cap to 350,000,000 USDT

[GitGuru7]

VIP-633 — Set vUSDT Supply Cap to 350M (BSC Core Pool)

What changed

• vips/vip-633/bscmainnet.ts — new FAST_TRACK VIP. One command:
  setMarketSupplyCaps([vUSDT], [350,000,000e18]) on bscmainnet.UNITROLLER (Core Pool Comptroller).
• simulations/vip-633/bscmainnet.ts — fork simulation (block 99000000):
  • Pre-VIP: asserts vUSDT supply cap == 600M.
  • testVip execution + expectEvents([NewSupplyCap], [1]).
  • Post-VIP: asserts vUSDT supply cap == 350M.
• simulations/vip-633/abi/Comptroller.json — ABI copied from simulations/vip-663/abi/ (has supplyCaps, NewSupplyCap, markets).

Key decision (human chose "option 1")

The request said raise to 350M, but the live on-chain vUSDT Core Pool cap is 600,000,000 USDT — verified via eth_call of supplyCaps(vUSDT) on the Unitroller at both latest and the chosen fork block 99,000,000 (raw 600000000e18). Setting it to 350M is therefore a reduction, not a raise. The spec had speculated an EBrake-driven reduction below 350M; that did not happen. Per the human's "option 1", I implemented exactly 350M as the literal target and used accurate, neutral framing ("Set ... to 350M", with the current 600M stated in the description) rather than "Raise".

Address / parameter verification

• vUSDT (Core Pool) = 0xfD5840Cd36d94D7229439859C0112a4185BC0255 — cross-checked against existing vips/vip-205.ts, vip-215.ts, vip-244.ts.
• Comptroller = NETWORK_ADDRESSES.bscmainnet.UNITROLLER (0xfD36E2c2a6789Db23113685031d7F16329158384).
• Function signature setMarketSupplyCaps(address[],uint256[]) (no underscore) — correct for the Core Pool at recent blocks following the vip-610 diamond migration; confirmed against recent precedent vip-568 and vip-622. (Older VIPs e.g. vip-516/542 used the legacy _setMarketSupplyCaps.)
• USDT on BNB Chain = 18 decimals → parseUnits("350000000", 18); consistent with the on-chain 600M value stored as 600000000e18.
• vips/vip-633/ did not previously exist.

Tests run + results

$ npx hardhat test simulations/vip-633/bscmainnet.ts --fork bscmainnet
At block #99000000
  Pre-VIP behavior
    ✔ vUSDT supply cap is 600M before execution
  VIP-633 ... commands
    ✔ executes setMarketSupplyCaps(address[],uint256[]) successfully
  VIP-633 ... execution
    ✔ can be proposed
    ✔ should be voteable
    ✔ should be queued successfully
    ✔ should be executed successfully   (gasUsed=154190)
  Post-VIP behavior
    ✔ vUSDT supply cap is 350M after execution
  7 passing (15s)

• npx prettier --check on the new files → "All matched files use Prettier code style!"
• npx eslint vips/vip-633/bscmainnet.ts simulations/vip-633/bscmainnet.ts → exit 0
• npx tsc --noEmit → clean (no errors)

Risks / notes

• Direction of change: this VIP lowers the vUSDT cap from 600M to 350M. If the intent was genuinely to increase capacity, the target value should be revisited — but it matches the explicitly requested 350M and the human's option-1 choice.
• Fork block 99000000 is a fixed, recently-verified block; the pre-VIP assertion will fail loudly if a future EBrake/governance action changes the cap before merge, which is the intended guard.
• Scope kept to the proposal + simulation; no on-chain propose/execute performed.

---

Opened by the Venus dev bot. Review required; the bot cannot merge.

[GitGuru7]

Why FAST_TRACK rather than REGULAR/NORMAL Timelock here? A cap reduction isn't obviously time-sensitive. Lets update accordingly.