Quanstamp initial report

[acenolaza]

DFP-1

• Acknowledge
• Commit: 94ae5e9
• Response: The absence of explicit bounds checks for the int256 to int224 cast in ProductApi3ReaderProxyV1.sol and NormalizedApi3ReaderProxyV1.sol is a deliberate trade-off for gas optimization in the read() functions. This design choice means that silent truncation may occur if the intermediate int256 result exceeds int224 limits, a behavior now clearly documented in their respective NatSpec comments.

For InverseApi3ReaderProxyV1.sol, the read() function's formula was updated to value = int224(1e36) / baseValue;. With this change, the division occurs directly between int224 types, and thus the specific concern regarding silent truncation from an intermediate int256 cast is not directly applicable to this revised calculation. Its NatSpec comment has been updated to accurately reflect the current operation.

DFP-2

• Acknowledge
• Commit: e0595d4
• Response: The ProductApi3ReaderProxyV1.read() function intentionally returns block.timestamp. This design choice by Api3 reflects that the timestamp accurately marks the on-chain computation time of the derived product value. Aggregating timestamps from underlying feeds is avoided due to complexity and the potential for misinterpretation. Integrators are responsible for checking the staleness of individual underlying feeds directly if required, as per Api3's integration guidelines (https://docs.api3.org/dapps/integration/contract-integration.html#using-timestamp). The contract's NatSpec documents this behavior.

DFP-3

• Acknowledge
• Commit: 2ff87d9
• Response: The potential for the read() function in InverseApi3ReaderProxyV1.sol to return 0 due to integer division underflow is an intentional design choice. This prioritizes maximum gas efficiency for this "highly unlikely" scenario, rather than adding an explicit check to revert. This behavior is now documented in the contract's NatSpec comment for the read() function.

DFP-4

• Acknowledge
• Commit: e70c71f
• Response: The potential for precision loss when downscaling values in ScaledApi3FeedProxyV1.sol is an intentional design choice. This approach prioritizes flexibility for integrators who may require feeds with fewer decimals, rather than restricting the contract's scaling capabilities. The responsibility for assessing and managing the impact of any such precision loss rests with the integrating protocol. This behavior, including the use of integer division which truncates during downscaling, is now clearly documented in the contract's main NatSpec.

S1

• Fixed
• Commit: ecfd948
• Response:

S2

• Fixed
• Commit: 16751b3
• Response: Reverting with the custom DivisionByZero() error is more gas-efficient and provides clearer error semantics than Solidity's default panic, with minimal gas impact on successful reads.

S3

• Unresolved
• Commit:
• Response: The current latestRoundData implementation uses named return variables for explicitness and consistency with Api3ReaderProxyV1.sol from the @api3/contracts repository. The potential gas savings from switching to a direct tuple return are considered negligible and do not outweigh the benefits of the current approach in terms of code legibility and established patterns.

[Siegrift]

👍 LGTM

[Siegrift]

Suggested change

	/// The initial multiplication `int256(value1) * int256(value2)` will revert
	/// The initial multiplication `int256(value1) * int256(value2)` may revert