as implemented, this function is lossy to the tune of 80 bits. this may be possible to reduce with some clever tricks. note that this also will work for divuq, which uses muluq under the hood

consider expressing this constraint as a failing unit test

@danrobinson @NoahZinsmeister pls add some details I do not get the issue

we will probably need to include balance checks to make sure that e.g. tokens which forward to a common implementation from different addresses can't be drained by feeTo

since only unbounded liquidity is fungible, it can be replaced by liquidity bounded to (min, max)

All ERC20 functionality can/should be implemented externally

Imo we should make a router that mints fungible liquidity at 1x, 2x, 10x, etc... for each pair (token namer can be moved here too)

Suggest scaling up initial liquidity tokens by 10^(18 - (min(token0Decimals, token1Decimals)) if token0Decimals < 18 or token1Decimals < 18

This will help us with a lot of wallet UX bugs and even uniswap frontend bugs (4 significant figures can be a very large string in our UI), in addition to computing useful token symbols and names

e.g.

Instead of storing the price accumulators as fixed points, we can store the ticks accumulators which produces geometric means instead of arithmetic means

because LPs can "lever up" ~200x, reserve{0,1}Virtual, liquidityVirtual, and perhaps other variables could in theory exceed type(uint112).max/type(int112).max

consider expressing this constraint as a failing unit test

Both setPosition and swap0for1 have many redundant writes and reads. Ideally these should be batched so each state variable is only read and written at most once.

This should likely be done last, since it may reduce the readability of the code (and since it may be obsoleted by further changes).

• growthOutside
• liquidityScalar

until now, assuming 1%
must be greater than ~15 bips for tick index to fit in uint16

factors are:

• gas cost of crossing ticks
• representing all possible prices
• maximum amount of leverage
• the level of allowed granularity/leverage of limit orders we want
• comparable projects allowed leverage

The getTickPrice() function should have a correct and maximally efficient implementation of 1.01^x.

blocked by leverage work

because divuq uses reciprocal under the hood, which can have precision issues because it uses floor division, divuq can also have precision issues

• swap accumulates fee
• remove liquidity

When reading price*CumulativeLast variables, all oracle consumers actually want the cumulative price as of the current block, not the last liquidity event (e.g. mint/burn/swap)

We provided a library in uniswap v2 periphery for this
https://github.com/Uniswap/uniswap-v2-periphery/blob/master/contracts/libraries/UniswapV2OracleLibrary.sol#L16

However, we should just add the view method directly to the pair getCumulativePrices() returns (price0Cumulative, price1Cumulative) that returns the cumulative prices as of the current block, even if there was no liquidity event.

Also potentially consider marking the Last suffixed variables private, if we want to force others to use this other method.

• token1Delta Calculation
• rounding the price calculation up/down

This is needed to track the growth in sqrt(x*y)/shares, which is how we plan to account for fees when adding and removing liquidity within bounds. (It's possible we may eventually be able to make do with somewhat less precision than 112x112.)

// multiply a UQ112x112 by a UQ112x112, returning a UQ112x112
// reverts on overflow
function uqmul112(FixedPoint.uq112x112 memory self, FixedPoint.uq112x112 memory x) internal pure returns (FixedPoint.uq112x112 memory) {
        ...
}

// divide a UQ112x112 by a UQ112x112, returning a UQ112x112
function uqdiv112(FixedPoint.uq112x112 memory self, FixedPoint.uq112x112 memory x) internal pure returns (FixedPoint.uq112x112 memory) {
        ...
}

this may improve our ability to trade in the router by letting the while loop pre-calculate required input amounts, and then using the flash swap callback to send the amount.

[5, 10, 30, 60, 100, 200]

related to fee voting, whenever a tick is crossed, the fee should be updated to be based on the liquidity in that tick

blocked by leverage work

For each integer in [-7802, 7802], we could call getPrice and ensure that the results are properly bounded.

these variables can be confused to mean the same thing as in uniswap v2

in uniswap v2, oracle price accumulators were modified before the first action of every block that could potentially change the price. this prevented bad price manipulation behavior via flash loans, force-sending assets to the contract, etc.

similarly, in uniswap v3, we have to modify the current fee vote before the first action of every block that could potentially change it. this will prevent someone from flash loaning a bunch of liquidity, voting for the lowest fee, and obviating the vote of existing LPs.

the median fee vote can only change on calls to setPosition and tick crossings, so we have to figure out an elegant way to update the global fee before the first setPosition/tick crossing of every block. it's possible we can piggy-back on the timeElapsed check we use for the oracle (https://github.com/Uniswap/uniswap-v3-core/blob/05ee4361f34ec5e544f0843943844d8dbab1fe9a/contracts/UniswapV3Pair.sol#L214), or there may be more efficient ways to do this.

in particular

• consider ripping out the feeVoteDelta logic
• consider using it in swap for consistency

in v2, it can be hard to calculate the value of some amount of LP shares because a) it uses reserves instead of balances, and b) when the fee is on there's some logic that needs to happen

we should make a view function to calculate the worth of LP shares, and also how many LP tokens a given amount of token0 and token1 entitle you to

we currently test that accumulating a single non-feeTo position credits feeTo with 1/6th of the fees. however, subsequent accumulations should both accumulate existing feeTo liquidity and credit it with 1/6th of the fees again.

test 1

• add liquidity
• swap
• get the correct output

test 2
swap crossing bounds

• get the correct output

• the 1:1 price is represented by uint16(-1) / 2

update the accumulator/whatever to track the vote

recalculate lp fee

blocked by leverage work

consider expressing this constraint as a failing unit test

this bitmap should be updated on any change to leverage settings/limit orders

needs to get checked in the swap function

there's 2^16 ticks, 65536 bits

this is 256 (256 bit words)

should be 1 sload per 256 bits (bytes32)

something like
mapping(uint8 => bytes32)
where uint8 key comes from the tick index and the direction you're swapping in

this could be using to standardize the behavior of non-compliant ERC-20 tokens for use in core

things it should be able to do:

• handle airdrops

in addition, formalize the math involved in taking the protocol fee

returns the amount that swaps to a particular ratio of reserves

• input is the price to trade to, aka tick
• virtual reserves for the current tick

the current forumla works, but does not include the fees paid out to the pool

https://www.wolframalpha.com/input/?i=solve+%28x0+-+x0*%281-g%29*y%2F%28y0+%2B+%281-g%29*y%29%29%2F%28y0+%2B+y%29+%3D+p+for+y

• fee denomination (bips)?
• decide on bounds (0-10000bips?)

w.r.t. fees not getting withdrawn when ticks are crossed (and still being exposed to price movements)

Uniswap v3 will likely need to reintroduce transferFrom, necessitating a safeTransferFrom function.