Feat/vh capped oracles - #320
Conversation
Three capped ERC4626Oracle instances for the Venus Hub receipt tokens (vhUSDT, vhUSDC, vhU) on BNB Chain, to back the core-pool listing in VenusProtocol/vips VIP-664. Cap arguments are deployed zeroed and armed afterwards by the VIP, matching how VIP-530 armed the asBNB oracle. bscmainnet only: the vaults exist there, and testnet needs the Hub team to deploy vaults or mocks first.
5c42f92 to
94b944c
Compare
Only Hub_USDT is deployed on bsctestnet, so testnet gets one oracle instead of three. Its share token is vSHARE with 12 decimals, keyed as vhUSDT to match the mainnet deployment name.
Mainnet's vhUSDT does not exist on testnet. The vault that stands in for it is Hub_USDT, whose share token is named vSHARE, so keying the config and the deployment off vhUSDT names a token that is not on the chain.
Deployed at 0xB5A17EB6A135A61057bc2F4f102c633899256BFa and verified on BscScan. Every cap argument is zeroed at deploy time; VIP-664 arms the snapshot, growth rate and gap. The bsctestnet.json and addresses exports are left to CI, which regenerates them on push.
Adds the deployment artifacts for the vhUSDT, vhUSDC and vhU ERC4626 oracles on BSC mainnet, along with the solc input used to build them.
- Deployment names now follow the vh<Token> convention agreed after the testnet deploy, so one vault has one name on every network - The testnet token predates that convention and is still "Vault Share" / vSHARE on chain; the comments record the mismatch - Renames the artifact alongside the config key so skipIfAlreadyDeployed still matches the existing deployment. Without it a re-run would deploy a second oracle and orphan the armed one - No on-chain effect: same address, same constructor args, contract untouched
|
just one nit from ai: The PR adds the three per-contract mainnet records but never regenerates the mainnet aggregates — bscmainnet_addresses.json has 87 keys and zero vh entries, while the testnet aggregates in the same diff were regenerated. hardhat-deploy's export step just didn't run for mainnet. Why it matters: @venusprotocol/oracle ships deployments/ in the npm package, and downstream resolves addresses by name from that index — vips/src/networkAddresses.ts:7 and venus-protocol-api's oracleNames.ts. So the API's getOracleName returns undefined for these three, and the next VIP touching them has to hardcode addresses again. Not a bug, no on-chain impact (VIP-664 hardcodes the addresses; live getPrice is correct). Fix is one export commit before merge; otherwise the next bulk export sweeps it up. |
GitHub automatically updates these files after deployment, so this is because of GitHub issue. |
Description
Adds capped
ERC4626Oracledeployments for the Venus Hub receipt tokens, to back the core pool listing in VenusProtocol/vips VIP-664.bscmainnet gets three oracles, one per receipt token:
0x18AfDACF30F8671021dec4b78297E39d2FE872260x9D2D9592cF8DFbf59107fAab703d08494BE146170x0e5AA174d4F31b757a237eb1999DE151596788B0Each prices its vault as
convertToAssets(1 share) * price(asset), reading the asset price from theResilientOracle.bsctestnet gets one oracle, for the USDT vault only.
Hub_USDTat0x7cE6ADF754D0eC81A6CF8ACd9C7454F45077dc61is the only Venus Hub vault deployed on testnet:deploy/config/bsctestnet.jsoninvenus-liquidity-hubhasassetCount: 1, there is no testnet Hub for USDC or U, and noUtoken exists on testnet at all.That vault's share token is named
Vault Share/vSHAREand has 12 decimals rather than mainnet's 24, because testnet USDT is 6 decimals and the Hub adds a 6 decimal offset. It is registered under thevSHAREkey, so the deployment is namedvSHARE_ERC4626Oracleafter the token that exists on testnet rather than after mainnet'svhUSDT.Cap arguments
Growth rate, snapshot interval, initial snapshot, snapshot timestamp and snapshot gap are all deployed zeroed on both networks. With
snapshotInterval == 0the cap is inactive andgetPricereturns the raw vault rate. VIP-664 arms it afterwards withsetSnapshot,setGrowthRateandsetSnapshotGap, the same way VIP-530 armed the asBNB oracle.Deployment
The bsctestnet oracle is deployed at
0xB5A17EB6A135A61057bc2F4f102c633899256BFa, verified on BscScan, and its artifact is committed here. The mainnet artifacts will land in a follow up commit once those deploys run.Checklist