Skip to content

Feat/vh capped oracles - #320

Merged
fred-venus merged 9 commits into
developfrom
feat/vh-capped-oracles
Aug 27, 2026
Merged

Feat/vh capped oracles#320
fred-venus merged 9 commits into
developfrom
feat/vh-capped-oracles

Conversation

@Debugger022

@Debugger022 Debugger022 commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Description

Adds capped ERC4626Oracle deployments 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:

vault address asset
vhUSDT 0x18AfDACF30F8671021dec4b78297E39d2FE87226 USDT
vhUSDC 0x9D2D9592cF8DFbf59107fAab703d08494BE14617 USDC
vhU 0x0e5AA174d4F31b757a237eb1999DE151596788B0 U

Each prices its vault as convertToAssets(1 share) * price(asset), reading the asset price from the ResilientOracle.

bsctestnet gets one oracle, for the USDT vault only. Hub_USDT at 0x7cE6ADF754D0eC81A6CF8ACd9C7454F45077dc61 is the only Venus Hub vault deployed on testnet: deploy/config/bsctestnet.json in venus-liquidity-hub has assetCount: 1, there is no testnet Hub for USDC or U, and no U token exists on testnet at all.

That vault's share token is named Vault Share / vSHARE and 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 the vSHARE key, so the deployment is named vSHARE_ERC4626Oracle after the token that exists on testnet rather than after mainnet's vhUSDT.

Cap arguments

Growth rate, snapshot interval, initial snapshot, snapshot timestamp and snapshot gap are all deployed zeroed on both networks. With snapshotInterval == 0 the cap is inactive and getPrice returns the raw vault rate. VIP-664 arms it afterwards with setSnapshot, setGrowthRate and setSnapshotGap, the same way VIP-530 armed the asBNB oracle.

Deployment

npx hardhat --network bscmainnet deploy --tags vh-erc4626-oracles
npx hardhat --network bsctestnet deploy --tags vh-erc4626-oracles

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

  • I have updated the documentation to account for the changes in the code.
  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a test preventing this bug from silently reappearing again.
  • My contribution follows Venus contribution guidelines.

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.
Debugger022 and others added 5 commits August 20, 2026 16:06
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.
@Debugger022
Debugger022 marked this pull request as ready for review August 24, 2026 11:46
@Debugger022
Debugger022 changed the base branch from develop to main August 24, 2026 12:07
@Debugger022
Debugger022 changed the base branch from main to develop August 24, 2026 12:08
- 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
@Debugger022 Debugger022 self-assigned this Aug 25, 2026

@fred-venus fred-venus left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@fred-venus

Copy link
Copy Markdown
Contributor

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-actions

Copy link
Copy Markdown

Code Coverage

Package Line Rate Branch Rate Health
contracts 99% 92%
contracts.interfaces 100% 100%
contracts.lib 100% 100%
contracts.oracles 83% 76%
contracts.oracles.common 97% 92%
Summary 93% (562 / 604) 87% (278 / 320)

@Debugger022

Debugger022 commented Aug 25, 2026

Copy link
Copy Markdown
Contributor Author

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.
fixed:9b20d41

@fred-venus
fred-venus merged commit 85d8cc3 into develop Aug 27, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants