Fallback behavior on oracle failure
Sushi (SushiSwap) — v2 + v3 + Trident + BentoBox/Kashi + SushiXSwap's assessment for RD-F-051 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Kashi has NO fallback oracle. If Chainlink feed reverts or returns stale data, updateExchangeRate() returns false but the cached exchangeRate in KashiPair state is used as-is by borrow(). The Nov-2022 Kashi exploit (~$120K) confirmed this exact mechanism: borrow() used outdated exchangeRate while liquidate() used the updated rate, creating an exploitable discrepancy. No secondary oracle source or revert-on-stale behavior documented. AMM: N/A (no oracle).
Sources #
- EtherscanKashiPairMediumRiskV1 EtherscanKashiPairMediumRiskV1 ABI — updateExchangeRate() returns (bool updated, uint256 rate); no fallback oracle reference in ABIretrieved 2026-05-17
- BlockSec: Beyond the market risk — KashiPairMediumRiskV1 logic bugBlockSec Nov 2022 Kashi analysis — no fallback confirmed; stale exchangeRate exploitationretrieved 2026-05-17
Methodology #
Identify the declared fallback behavior (pause, secondary source, last-known-price, revert) when the primary oracle reverts or reports a stale value.
See the full factor methodology and distribution across all protocols →