Oracles
Facets quote prices, yields, or reference rates. To keep those look‑ups transparent, every oracle contract or data feed used by a MORE Vault must first be listed in the Oracle Registry. Like the facet catalogue, the registry tells the ecosystem where a data point comes from and whether the DAO considers it reliable. It never blocks usage on‑chain.
Two-Tier Model
Permissionless Oracle Registry – Any address may publish an oracle’s address and metadata. Builders can reference the entry immediately when deploying a vault.
DAO‑Approved Oracle Registry – The DAO elevates an oracle after verifying its implementation (e.g., Chainlink feed, Pyth feed, Redstone relay, on‑chain TWAP) and liveness guarantees.
Front‑ends default to DAO‑approved oracles, while advanced users may opt into permissionless feeds.
Each registry entry stores:
oracleAddress– the contract read by facets.quoteAsset– ERC‑20 or symbol that the feed returns (ETH, USDC, etc.).decimals– number of decimals in the price.latestRoundData– provides the latest price, round ID, and timestamp. Helps risk engines flag stale reads.publisher– address that registered the oracle.
DAO approval criteria
Before promoting an oracle, the DAO checklist includes:
Implementation audit – Verified that the contract cannot be paused or manipulated by a single key.
Data source review – Confirm the upstream source (e.g. Chainlink aggregator, TWAP window) and fallback rules.
Liveness test – Feed must have updated within the last
maxStaleseconds at proposal time.
If passed, the DAO calls addOracle(oracleAddress, quoteAsset, decimals, publisher).
How facets use the registry
latestRoundData(token)helper in the core looks up the oracle entry by (oracleAddress,quoteAsset).If the oracle is permissionless, the call still succeeds. Front‑ends may show a warning.
Facets can cache the registry pointer to save gas, but they must revert if the oracle entry is later flagged as deprecated by the DAO.
Last updated