Oracle staleness check present
Circle USYC's assessment for RD-F-059 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
No on-chain staleness check confirmed in Teller source. The GenericNextPriceAggregator stores _updatedAt from transmit() and returns it via latestRoundData(), but no staleness guard at the consumer (Teller) layer was confirmable from the ABI. For an issuer-controlled push oracle, if the reporter goes offline or is compromised, stale NAV is accepted silently. This is a material gap: BSC holds $2.86B TVL and BSC-side oracle architecture is not fully confirmed.
Sources #
- EtherscanTeller Implementation ABI - EtherscanTeller implementation at 0xF8724D6b9E6fF55Bc4496fddb3437DC691CD26EB - ABI does not show a staleness-check or checkUpdatedAt functionretrieved 2026-05-16
- GenericNextPriceAggregator Oracle Implementation - EtherscanGenericNextPriceAggregator at 0x6DeaA761bc131Ac5f1D562EE71819E846EF11624 - transmit stores _updatedAt; latestRoundData() returns it; no staleness enforcement in oracle itselfretrieved 2026-05-16
Methodology #
Determine whether the protocol rejects oracle reads older than a declared maximum age (i.e., checks `updatedAt > block.timestamp - maxStaleness`).
See the full factor methodology and distribution across all protocols →