uint224
where the upper 112 bits represent the integer amount, and the lower 112 bits represent the fractional amount.price0CumulativeLast
and price1CumulativeLast
, which are ratios of reserves of token1
/token0
and token0
/token1
respectively. I.e. the price of token0
is expressed in terms of token1
/token0
, while the price of token1
is expressed in terms of token0
/token1
.mint
/burn
/swap
) on the pair in the current block, you can compute the cumulative price counterfactually.UniswapV2OracleLibrary#currentCumulativePrices
for 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 #sync
method on the pair. It is correct regardless of whether a swap has already executed in the current block.UniswapV2Pair
cumulative price variables are designed to eventually overflow, i.e. price0CumulativeLast
and price1CumulativeLast
and blockTimestampLast
will overflow through 0.uint256
as long as the observations are made for periods of max 2^32
seconds, or ~136 years.blockTimestampLast
is 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 2^32
seconds.block.timestamp
of 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​