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