Uni V4 hooks & the Cancun fork - Q4 23

Uni V4 hooks & the Cancun fork - Q4 23

Jul 12, 2023·

3 min read

The way we use Uniswap will change forever.
Uniswap Version 4 will be out by the end of 2023.
Ethereum Foundation will introduce new upcodes to the EVM

Uniswap V4
Uni v4 i
ntroduces a new "singleton" contract, where all pools live within a single smart contract. This is a new exchange architecture not compatible with Uniswap v3 - It introduces the following features:

  • A single contract acts as the only liquidity pool in the system.

  • A single contract eliminates the need for asset transfers between parties. And instead, the contract handles internal "flash accounting" using the new EVM transient storage upcode to handle internal pool balances. Using transient storage reduces costs against loading data from memory.

  • Intro Uniswap hooks plugins to customize how pools, swaps, fees, and LP positions interact.

  • Liquidity providers will customize their way of interacting with the main pool.
    The ability to introduce complex logic contracts to interact with the funds optimally brings new opportunities for developers via hooks or plugins. The community is expecting components like:

    • A time-weighted average market maker (TWAMM)

    • Dynamic fees based on volatility or other inputs

    • Onchain limit orders

    • Depositing out-of-range liquidity into lending protocols

    • Customized on-chain oracles, such as geomean oracles

    • Autocompounded LP fees back into the LP positions

    • Internalized MEV profits are distributed back to LPs

  • Introduces pool lifecycle – before or after a swap moment, or before after an LP position is changed.

Cancun Fork


  • Language support could be added in a relatively easy way. For example, in Solidity, a qualifier transient can be introduced (similar to the existing qualifiers memory and storage, and Java’s own transient keyword with a similar meaning). Since the addressing scheme of TSTORE and TLOAD is the same as for SSTORE and SLOAD, code generation routines that exist for storage variables, can be easily generalized to also support transient storage.

    Potential use cases enabled or improved by this EIP include:

    1. Reentrancy locks

    2. On-chain computable CREATE2 addresses: constructor arguments are read from the factory contract instead of passed as part of the init code hash

    3. Single transaction ERC-20 approvals, e.g. #temporaryApprove(address spender, uint256 amount)

    4. Fee-on-transfer contracts: pay a fee to a token contract to unlock transfers for the duration of a transaction

    5. “Till” pattern: allowing users to perform all actions as part of a callback, and checking the “till” is balanced at the end

    6. Proxy call metadata: pass additional metadata to an implementation contract without using call data, e.g. values of immutable proxy constructor arguments

These opcodes are more efficient to execute than the SSTORE and SLOAD opcodes because the original value never needs to be loaded from storage (i.e. is always 0). The gas accounting rules are also simpler since no refunds are required.





Special thanks to @jacoboLabs for compiling the summary of the TWAMM paper.