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 🤔
Uni v4 introduces 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.
INTRO - TRANSIENT STORAGE UPCODES TSTORE TLOAD
Language support could be added in a relatively easy way. For example, in Solidity, a qualifier
transientcan be introduced (similar to the existing qualifiers
storage, and Java’s own
transientkeyword with a similar meaning). Since the addressing scheme of
TLOADis the same as for
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:
On-chain computable CREATE2 addresses: constructor arguments are read from the factory contract instead of passed as part of the init code hash
Single transaction ERC-20 approvals, e.g.
#temporaryApprove(address spender, uint256 amount)
Fee-on-transfer contracts: pay a fee to a token contract to unlock transfers for the duration of a transaction
“Till” pattern: allowing users to perform all actions as part of a callback, and checking the “till” is balanced at the end
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
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.