This will enable us to have optimisations and simplifications over the generic OZ one.

Personalisation of the transfer function:
If the to address is the PoolManager, and the PoolManager is locked, automatically burn the tokens and update the account delta - no need to call the receiving hook

reduce pool creation cost using proxies, with minimal overhead on each pool action

Uniswap/v3-core#492

https://github.com/Uniswap/core-next/blob/8a72014f8efb67ed2f78b20deec09804b43659af/contracts/libraries/Tick.sol#L29-L37
think this can be improved
https://www.wolframalpha.com/input?i=simplify+%282**128+-+1%29+%2F+%28%28%28%28%28C+%2F+x%29+*+x%29+-+%28%28-C+%2F+x%29+*+x%29%29+%2F+x%29+%2B+1%29

we have a few opportunities to use custom types, probably most obviously all the *X96 variables

we have implementations of the solidity compiler (incomplete) and geth with eip-1153 support here

NethermindEth/nethermind#4126

these would behave as limit orders, and probably need to be measured as tokens instead of liquidity

when crossing these 0 tick span regions, all fees would go to the limit order liquidity

start by trying to move the fee collection and accounting logic into hooks twamm feature into hooks

To start writing some tests using Forge (the Foundry testing framework like hardhat) to try it out and get it integrated into the repo

rationale is since fragmentation within the singleton is cheaper, it's not as important to limit it at the factory level

pros:

• gov minimization
• market driven parameter

cons:

• fragmentation

alternately, make the fee -> tickSpacing a pluggable contract, which stores them as immutables
this still costs as much or more than the current code, but can be more flexible in allowing well-spaced tickSpacings

https://github.com/Uniswap/core-next/blob/7091f20f6134b0632436f2c049adfc490bf9221e/contracts/PoolManager.sol#L242
this should be #afterDonate

sara caught this here 7091f20#commitcomment-72240735

i think we have the problem here that there may be less than controllerGasLimit gas left, and the call will be made with that much gas instead of controllerGasLimit but the transaction will still succeed even if the fetch protocol fee call ran out of gas. we need an explicit gas check here to prevent the caller from sending a gas amount that will result in less than controllerGasLimit being allotted to fetching the protocol fee

https://github.com/Uniswap/core-next/blob/9e329dcce8d908e898f8f807b29d0c9a4fde45dd/contracts/PoolManager.sol#L385-L389

there is runtime overhead to using the mocked _blockTimestamp() and piping through time to libraries, we should just mock this in the vm instead

since hooks can affect price or liquidity "between" blocks, e.g. add liquidity based on time, or execute swaps based on time, the oracle feature is incompatible with pools that have these kinds of hooks

we should consider externalizing any time based features to hooks (e.g. seconds per liquidity and tick/seconds per liquidity accumulators)

the nice benefit is that since these can be opt-in via hooks, pools that don't need the features will be cheaper to use. it also removes all references to time from the pool manager, which makes the code more portable to networks where time is unreliable or more manipulable

these non-revertible positions would not be kicked back in when you cross back into the tick range

similar to #21 but with less complexity because they don't need special casing / don't represent effectively infinite liquidity

@danrobinson to spec this out more

this warning is being logged in the tests, I see the error defined in both Pool.sol and Oracle.sol

v3 stores them at the pool level, v4 can store them per-token at the singleton level, making protocol fees relatively cheaper at runtime (e.g. swapping across 3 usdc-eth pools with protocol fees turned on does not cause 3 sstores for protocol fees)

https://github.com/Uniswap/core-next/blob/718cb055823bf68dfb34b2c90d8517b3e1f0f2b1/contracts/libraries/Pool.sol#L86

https://github.com/Uniswap/core-next/blob/b18e172a151e9c6e7c22a63011bc048a2e393790/contracts/PoolManager.sol#L263

let's get this running on every commit/pr

Consensys/mythx-cli#267

this should be much easier to do now that pool logic is in a library. verify that via calls to modify position and swap, all positions will always be solvent. we should probably use mythx for this. tried it with forge, but it has some drawbacks over echidna/mythx style fuzz tests, mainly does not test sequences of transactions, but handling reverts is also painful
b18e172

it seems like it's possible that donate could allow overflowing fees earned to type(uint256).max, but needs investigation

#36

this is useful for hooks, which may need to execute their own swaps, mints or burns on pools before the user interacts with the pool

• Using initial bits to determine which hooks to call
• Define where the hooks will be
• In Hook constructor user specifies where they want hooks to be called
• have some validate function that checks the address is valid given where they specified the hooks to be called (put this in a hook library)

library Hook {
	uint256 BEFORE_SWAP_BIT = 0b000001;
	uint256 AFTER_SWAP_BIT  = 0b000010;

	function validate(params) internal {
		if (params.beforeSwap && address(this) & 1 != 1) revert();
	}

	function shouldCall()
}

interface IHook {
	function beforeModifyPosition(ModifyPositionParams calldata params) external;
	function beforeSwap() external;
	// ...
}


contract MyHook is IHook {
	constructor() {
		Hook.validate(
			HookValidateParams({
				beforeSwap: true,
				afterSwap: false,
				beforeModifyPosition: true,
				afterModifyPosition: true,
				...
			})
		);
	}
}

• Before first interaction in each block (swap/mint/burn/etc.)
• Before mint
• Before burn
• Before swap
• After swap
• Before tick crossing

similar to #22 but orders span 1 underlying tick instead of 1 tickSpacing. this would give limit order placers a tighter range/lower likelihood of partial fills.

ideally could be implemented via packing additional accounting data into the "starting" tick, and treating the tick+1 as a special case that might not need, for example, an entry in the tick bitmap.

we need to prevent this somewhere, probably in initialize

this was prevented in createPool and enableFeeAmount before https://github.com/Uniswap/v3-core/blob/ed88be38ab2032d82bf10ac6f8d03aa631889d48/contracts/UniswapV3Factory.sol#L44
and
https://github.com/Uniswap/v3-core/blob/ed88be38ab2032d82bf10ac6f8d03aa631889d48/contracts/UniswapV3Factory.sol#L67

https://www.paradigm.xyz/2021/07/twamm/

• SubmitOrder / Order Expiration

  • Decide whether expiration should be set by date or by n-intervals. I was fooling around with deterministic orderIds in which case only date works. If by n-intervals, expiration (which is the stored value) is not determined until tx is mined. with weiroll type txs, deterministic id's may not even be important at all, but weiroll is a bit gas guzzling. Honestly I just like the deterministic aspect of expiration timestamp better. But maybe length-of-time is the bigger usecase?
  • Then make expiration calculations to set accordingly.

• Cancel LongTerm Orders

  • Do calculations for order cancellations
  • Update user deltas in Pool Manager (#34)

• ClaimEarnings

  • Update user deltas in Pool Manager (#34)

• executeTWAMMOrders (@ewilz currently looking into this)

  • Use pool state + twamm state to calculate new state sans fees/initialized ticks
  • Introduce pool fees into calculation
  • Introduce Initialized ticks into calculation
  • update twamm state (OrderPool earningsFactor params)
  • execute swap on pool
  • update TWAP state if necessary
  • Address order pool with 0 trades conditions

• Edgecases to test/address:

  • TWAMM pushes pool price past highest/lowest price
  • when checking for tick crossings: don't return true if initialized tick directly after target price (might be a bug rn)
  • if executed exactly on expiry, order should be fully complete (must do +1 rn)
  • ddos attack on less active pools (too many expiries to process before gas runs out)
  • large orders trading over too little liquidity currently causes math overflow
  • try testing with "extreme tick spacing" (getting out of gas error with tickspacing of 1)
  • swapping on 0 liquidity pools: single pool sell + both pools selling
  • single pool sells to max/min

• Features

  • Optimize expiry lookup with bitmap of active expiry periods.
  • Add Events??

• ABDK to fix math

right now, the protocol fee on swap is inclusive, i.e. 1/6 or 5 bips of a 30 bips pool

if the protocol fee on swap is turned on, it might be less mental overhead if it were exclusive, i.e. 5 bips on top of a 30 bips pool, for 35 bips total

we should do two additional validations for hooks to limit the number of duplicate pools with invalid hooks, i.e. hooks that are never called, or hooks that are called but do not contain any code (e.g. arbitrary random address with no code)

• we should check that when calling a hook the return value is the selector of that hook, or we revert, e.g.:

if (key.hooks.shouldCallBeforeInitialize()) {
    require(key.hooks.beforeInitialize(msg.sender, key, sqrtPriceX96) == IHooks.beforeInitialize.selector);
}

• we should validate in initialize that the hook address either has at least 1 set upper bit (called at at least one hook point), or is the address 0

https://github.com/Uniswap/core-experiments/tree/singleton

lower gas fees for hopping between pools
allows you to flash across all pools (helps swap+add)

tracked here: https://github.com/Uniswap/core-experiments/tree/singleton

benefits:

• lower gas fees for hopping between pools (no transfers are necessary)
• fewer storage slots for tracking a token's balance
• aggregation is way cheaper
• allows you to flash anything across all pools (e.g. any combination of swap/mint/burn for any pool, huge network effects)
• allows you to flash borrow the entire aggregate balance of a token from uniswap

• also requires refactor of calculateExecutionUpdates for gas savings & logical flow.
• TWAMM pushes pool price past highest/lowest price
  • case 1: There is no liquidity at the highest/lowest prices so final price should not be max/min price.
  • case 2: There is liquidity at the highest/lowest prices so final price should be max price or min price.

future:

• when checking for tick crossings: don't return true if initialized tick directly after target price (might be a bug rn)
• if executed exactly on expiry, order should be fully complete (must do +1 rn )
  • also check exact expiry for both selling pool condition

https://github.com/Uniswap/core-next/blob/718cb055823bf68dfb34b2c90d8517b3e1f0f2b1/contracts/libraries/TickBitmap.sol#L64

this calculation can result in 255 * TickMath.MAX_TICK
TickMath.MAX_TICK = 887272 = ~2^19.75 (takes 20 bits) so this overflows the int24 container since 255 is another 8 bits

that way any deltas left in the singleton can show up in user wallets

this might be useful to other hooks, but would probably be necessary if we wanted to charge fees on gross and make twamm a hook

the following are missing any events and probably should have them:

• pool initialize
• modify position
• swap

don't emit events and maybe shouldn't

• settle (paying will emit an ERC20 transfer to pool)
• take (taking will emit an ERC20 transfer from pool)

probably as a rule of thumb anything that deals with transient deltas wouldn't need events

instead of lock() and lockCallback() have a method called execute(bytes calldata orders)

the orders would be all the calls to pools that modify positions, swap, etc.

even external calls or static calls should be supported

accumulate the deltas in memory instead of storage

not really a good practice to label every contract with a brand

i think the optimizer can potentially make these equivalent (enums are constants, bit shifting a constant by an enum should be optimized), while reducing the redundant unit testing and error boundaries

this also reduces our risk of a bug

Should be more granular than protocol fees
Should be controllable by governance