#termmax @TermMax
I went into TermMax’s oracle docs assuming “backup oracle support” meant every listed asset had a configured backup.
Then I started opening the individual asset pages.
That assumption didn’t hold.
@TermMax ’s own security docs say its oracle system supports multiple oracles and backup mechanisms that can fail over if a primary oracle fails.
USDe clearly uses that redundancy.
TermMax documents Chainlink as its primary feed, RedStone as its backup, and an 86,400 second (24-hour) heartbeat.
But the setup is not uniform.
On TermMax’s published Ethereum oracle pages wbrETH and sYUSD both list a primary price feed while the published Backup Price Feed is the zero address (0x0000...0000).
That changed how I read oracle redundancy.
Backup oracle capability at the protocol level does not mean every listed asset has the same backup configuration.
To be fair a zero address backup field does not prove that an asset is unprotected or that other safeguards are absent.
It simply tells me that the published per asset configuration is different.
And that matters because TermMax’s own security docs describe oracle prices as critical to collateral valuation and liquidation decisions.
So the question I’m left with is:
When an asset’s published backup field is the zero address, where is its intended failover path documented if the primary feed cannot be used?
@TermMax #TermMax
I went into TermMax’s oracle docs assuming “backup oracle support” meant every listed asset had a configured backup.
Then I started opening the individual asset pages.
That assumption didn’t hold.
@TermMax ’s own security docs say its oracle system supports multiple oracles and backup mechanisms that can fail over if a primary oracle fails.
USDe clearly uses that redundancy.
TermMax documents Chainlink as its primary feed, RedStone as its backup, and an 86,400 second (24-hour) heartbeat.
But the setup is not uniform.
On TermMax’s published Ethereum oracle pages wbrETH and sYUSD both list a primary price feed while the published Backup Price Feed is the zero address (0x0000...0000).
That changed how I read oracle redundancy.
Backup oracle capability at the protocol level does not mean every listed asset has the same backup configuration.
To be fair a zero address backup field does not prove that an asset is unprotected or that other safeguards are absent.
It simply tells me that the published per asset configuration is different.
And that matters because TermMax’s own security docs describe oracle prices as critical to collateral valuation and liquidation decisions.
So the question I’m left with is:
When an asset’s published backup field is the zero address, where is its intended failover path documented if the primary feed cannot be used?
@TermMax #TermMax
