6.1 Calculation of latestAnswer introduces minor precision loss due to double rounding
The OracleSubmitter contract is designed to function as a Chainlink-compatible price feed adapter. It exposes functions like latestRoundData(...) which return the latestAnswer state variable, representing the price of the base asset per share (assets/shares).
This latestAnswer is calculated and set in the _updateLatestAnswer(...) function by inverting the priceD18 value (which represents shares/assets). The issue is that this process involves a double-rounding error.
- The incoming
priceD18 value is typically calculated externally (e.g., in OracleHelper) using Math.mulDiv(...). This division calculates (shares * 1e18) / assets, rounding the result _down_ (floor); - The
_updateLatestAnswer(...) function then takes this already rounded-down priceD18 and uses it as a denominator in another division: 1e36 / priceD18;
function _updateLatestAnswer(uint224 priceD18) internal {
// @audit The priceD18 value is the result of a previous division that rounded down.
// @audit-issue Using this rounded-down value as a denominator in a new division
// causes the final result (latestAnswer) to be rounded up, amplifying the inaccuracy.
latestAnswer = int256(1e36 / uint256(priceD18));
updatedAt = uint32(block.timestamp);
}
Because the denominator ( priceD18) is slightly smaller than its true value (due to the first rounding-down), the final latestAnswer (which also rounds down) will be slightly _larger_ than the true asset/share price. This introduces a minor but persistent upward bias in the reported price. While this value is understood to be an _effective_ price, reflecting vault state (including continuous fees and queued actions), this specific rounding behavior is an artifact of the calculation method.
Recommendation
Consider documenting this calculation behavior. Since the protocol's price already represents an effective rate rather than a "spot" price, this minor precision artifact may be acceptable. However, any integrator relying on this oracle as a Chainlink-compatible feed should be made aware that the latestAnswer is subject to a small, persistent upward bias due to this double-rounding.
6.2 The latestRoundData() function returns misleading timestamps
The OracleSubmitter contract provides a Chainlink-compatible latestRoundData() interface. This function is expected to return five values, including an answer, a startedAt timestamp (when the price round began), and an updatedAt timestamp (when the answer was last updated).
The issue is that the latestRoundData() function implementation uses the contract's internal updatedAt state variable for _both_ the startedAt and updatedAt return values.
// src/oracles/OracleSubmitter.sol
function latestRoundData() public view returns (uint80, int256, uint256, uint256, uint80) {
uint32 timestamp = updatedAt;
// @audit-issue The same `updatedAt` value is returned for both `startedAt` and `updatedAt`.
return (0, latestAnswer, timestamp, timestamp, 0);
}
This internal updatedAt variable is set in the _updateLatestAnswer(...) helper function. This helper is called in two scenarios:
- In
submitReports(...), _only if_ the submitted report is not suspicious; - In
acceptReports(...), when a (previously suspicious) report is manually accepted;
// src/oracles/OracleSubmitter.sol
function _updateLatestAnswer(uint224 priceD18) internal {
// ...
// @audit `updatedAt` is set to the current timestamp of finalization.
updatedAt = uint32(block.timestamp);
}
function submitReports(...) external onlyRole(oracle.SUBMIT_REPORTS_ROLE()) {
// ...
// @audit This is only called if the report is *not* suspicious.
if (!report.isSuspicious && asset == baseAsset) {
_updateLatestAnswer(report.priceD18);
}
// ...
}
The problem arises when a report for the baseAsset is submitted and flagged as suspicious. The submitReports(...) function will _not_ update updatedAt. Only later, when acceptReports(...) is called, will updatedAt be set to the _acceptance_ timestamp.
This means that for a suspicious report, latestRoundData() will return the _acceptance time_ as both the startedAt and updatedAt time. This is misleading for consumers of the oracle, as it hides the true submission time (when the "round" effectively started) and the latency between submission and acceptance.
Recommendation
Consider revisiting the logic for how timestamps are stored and returned in latestRoundData(). A more accurate implementation might distinguish between the initial submission time of a price report (which could be considered startedAt) and the time it was finalized and accepted (the current updatedAt).
Alternatively, if this behavior is intended, consider adding clear documentation to the latestRoundData() function explaining that both startedAt and updatedAt will reflect the finalization timestamp of the latest valid price, especially in cases where a suspicious report is manually accepted.
