uint224where the upper 112 bits represent the integer amount, and the lower 112 bits represent the fractional amount.
price1CumulativeLast, which are ratios of reserves of
token1respectively. I.e. the price of
token0is expressed in terms of
token0, while the price of
token1is expressed in terms of
swap) on the pair in the current block, you can compute the cumulative price counterfactually.
UniswapV2OracleLibrary#currentCumulativePricesfor getting the cumulative price as of the current block. The current cumulative price returned by this method is computed counterfactually, meaning it requires no call to the relative gas-expensive
#syncmethod on the pair. It is correct regardless of whether a swap has already executed in the current block.
UniswapV2Paircumulative price variables are designed to eventually overflow, i.e.
blockTimestampLastwill overflow through 0.
uint256as long as the observations are made for periods of max
2^32seconds, or ~136 years.
blockTimestampLastis stored only in a
uint32. For the same reason as described above, the pair can save a storage slot, and many SSTORES over the life of the pair, by storing only
block.timestamp % uint32(-1). This is feasible because the pair is only concerned with the time that elapses between each liquidity event when updating the cumulative prices, which is always expected to be less than
block.timestampof your observations as
uint256, and avoid dealing with overflow math for computing the time elapsed between observations. This is how the ExampleSlidingWindowOracle handles observation timestamps.ExampleSlidingWindowOracle