feat: add VIP-680 Liquidity Hub (USDT) BSC testnet wiring VPD-1566 & 1588#733
Open
Debugger022 wants to merge 3 commits into
Open
feat: add VIP-680 Liquidity Hub (USDT) BSC testnet wiring VPD-1566 & 1588#733Debugger022 wants to merge 3 commits into
Debugger022 wants to merge 3 commits into
Conversation
- Grant the Hub's asymmetric ACM roles: the full governance set to the Normal timelock (which then runs the wiring) plus the Guardian operator set; a companion addendum grants governance to the Fast-Track and Critical timelocks. - Wire the Core yield source end-to-end (register vUSDT behind AdapterCoreV1, set inner and outer queues) so the USDT Hub routes deposits and withdrawals through the Core pool. - Split the grants into a main proposal plus bsctestnet-addendum.ts: all three timelocks' grants plus the wiring exceed BSC's per-tx propose gas cap in a single proposal. - Defer the FRV and Flux sources — neither has a concrete resource on testnet yet (no FRV vault instance; Flux adapter not deployed). - Add fork simulations for both proposals: pre/post state, the 40 and 58 role grants, and an end-to-end maxDeposit check.
- New proposal grants the Guardian the full Governance role set across the Hub stack (Hub, Core, FRV, Flux) so resources can be listed and reconfigured via multisig without a proposal per change - Deliberate testnet-only deviation from the asymmetric model where the Operator is tighten-only; kept in a bsctestnet file, not for mainnet - Factor the shared YieldGroupBase signatures into one base array; FRV uses YieldGroupFRV (adds forceRemoveResource, no cap setters or setBlocksPerYear) so it keeps a separate set - Update the main and addendum descriptions to reference the three proposals as one package
Debugger022
marked this pull request as ready for review
July 9, 2026 11:59
Debugger022
changed the title
Debugger022
changed the title
Debugger022
changed the title
The Liquidity Hub (USDT) stack was redeployed on BNB Chain testnet (new HubRegistry, Hub, Core/FRV/Flux sources and adapters), so the previous VIP-680 targets stale addresses and predates the registry. Rewrite it to onboard the current deployment on-chain in one package. - Split into five REGULAR proposals: the full surface (ownership accepts, ~205 role grants, source wiring) exceeds the BSC per-tx propose gas cap in a single proposal. - main: accept Hub and registry ownership, grant the Normal Timelock the governance set across the stack. - wiring: register the Hub, then wire Core, FRV and Flux end to end (addHub before addYieldGroup, outer queue [FRV, Flux, Core]). - fast-track and critical: grant each timelock the governance set. - guardian: grant the Guardian full permissions (testnet only). - move addresses and ACM role strings into addresses.ts and permissions.ts; add the HubRegistry ABI, regenerate the Hub and YieldGroup ABIs, and drop the superseded addendum files.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
VPD-1566
Post-deploy governance wiring for the Liquidity Hub (USDT) on BNB Chain Testnet, as three proposals under
vips/vip-680/:bsctestnet.ts(main) — grants the Hub's asymmetric ACM roles (full Governance set on Hub_USDT and the Core source to the Normal timelock, the tighten-only Operator set to the Guardian) and wires the Core yield source end-to-end: register vUSDT behind AdapterCoreV1, set the inner queues, register the Core source on the Hub, set the outer queues.bsctestnet-addendum.ts— grants the same Governance role set to the Fast-Track and Critical timelocks. Separate proposal because all three timelocks' grants plus the wiring exceed BSC's per-tx propose gas cap (main already uses 65%, addendum 85%).bsctestnet-guardian.ts— testnet-only: tops the Guardian up to the full Governance set across the whole stack (Hub + Core + FRV + Flux sources, 39 grants), so the backend can list and reconfigure resources via multisig without a VIP per change. Deliberate deviation from the mainnet asymmetric model; marked not to be mirrored to mainnet.Role strings are copied verbatim from the deployed contracts'
_checkAccessAllowedliterals: Hub 19 sigs; Core/Flux sources (YieldGroup) share base + cap setters +setBlocksPerYear; FRV (YieldGroupFRV) is base +forceRemoveResourceonly.Fork simulations for all three proposals (
simulations/vip-680/): pre/posthasRoleasserts on the exact role ids (immune to the ACM wildcard fallback), RoleGranted event counts (40 / 58 / 39), negative asserts proving the asymmetric split (Guardian holds no governance-only role after main; timelocks never get operator-onlyreallocate), and an end-to-endmaxDeposit > 0check through Hub → Core source → vUSDT. All passing on a bsctestnet fork.FRV wiring — done on-chain via the Guardian multisig (click to expand)
Using the permissions from the guardian proposal (no code change in this PR), the Guardian registered a concrete Fixed Rate Vault on
FRVSource_USDT, set its inner queues, registered the FRV source on the Hub and put it first in the outer deposit queue (verified on-chain:resources(),innerDeposit/WithdrawQueue(),registeredYieldGroups(),outerDepositQueue()). The vault is live in Fundraising and currently empty. Config and timing below are read from its liveruntime().Flux stays deferred — no Flux adapter on testnet yet.
Addresses
0xc892F31c4dbDee443b3501BC27D92Aca3e787a640xA11c8D9DC9b66E209Ef60F0C8D969D3CD988782c0xC337Dd0390FdFD0Ee5D2b682E425986EDD7b59datokenId 75)0x2Ce1d0ffD7E869D9DF33e28552b12DdDed3267060xf77dED2A00F94e33C392126238360D4642c16Ba2Config (verified on chain)
Timing (UTC, from live
runtime())FRV yield source wiring txn (BNB Chain Testnet)
addResource(VAULT, AdapterFRV)0x5fe062a9…8f9dbb50setInnerDepositQueue([VAULT])0x970fb488…dfea6018setInnerWithdrawQueue([VAULT])0xc1ee418e…ce24a5aaaddYieldGroup(FRVSource_USDT, type(uint128).max, 10000)0x9e96db98…55b0590bsetOuterDepositQueue([FRVSource_USDT, CoreSource_USDT])0xd7f3b05d…de7c80e2setOuterWithdrawQueue([FRVSource_USDT, CoreSource_USDT])0xcb792106…d4badcb6Flux wiring — done on-chain via the Guardian multisig (click to expand)
Fluid has no bsctestnet deployment, so a Fluid fUSDT market was deployed separately on testnet to exercise the Flux family. Using the permissions from the guardian proposal (no code change in this PR), the Guardian deployed
AdapterFluxagainst that market'sLendingResolver, registered the fUSDT fToken onFluxSource_USDT, set its inner queues, registered the Flux source on the Hub, and updated the outer queues to[FRV, Flux, Core](verified on-chain:resources(),innerDeposit/WithdrawQueue(),registeredYieldGroups(),outerDeposit/WithdrawQueue()). The FRV vault's Fundraising and Lock windows have since closed, so a plain Hub deposit now cascades past FRV into Flux.Addresses
0x52217232e12A1c906aB8DEf58532a3618970D0250x8a0EB38F1AA55f93B79327c2Ec0327d8009C88480x477a0b09030f755D006daE6d8D90430AA0Fe77680x8Aac02EB8054F4CBAdE1396651b94F8F7D87fafcAdapterFlux deployment (BNB Chain Testnet)
0x8a0EB38F1AA55f93B79327c2Ec0327d8009C88480x46c609bf…db0ca6a3Flux yield source wiring txn (BNB Chain Testnet)
addResource(fUSDT, AdapterFlux)0x1443e755…7a5b650bsetInnerDepositQueue([fUSDT])0xc713bb9f…93f5d67esetInnerWithdrawQueue([fUSDT])0x0975288a…755d6f55addYieldGroup(FluxSource_USDT, type(uint128).max, 10000)0xa8f6ea3b…e922a061setOuterDepositQueue([FRV, Flux, Core])0x23a00efb…90934155setOuterWithdrawQueue([FRV, Flux, Core])0x4b7868e8…0485711aThe adapter deploy and all six wiring calls succeeded on-chain (receipt status
0x1); the wiring batch landed in a single block (119033584).