# v4 vs v3 (/docs/protocols/v4/concepts/v4-vs-v3)

Compare Uniswap v4 and v3 architecture, accounting, and extensibility tradeoffs.

While Uniswap v4's underlying concentrated liquidity is the same as Uniswap v3,
there are some key differences in the architecture and accounting.

## Singleton Design
## Pool creation
**v4**: The singleton contract facilitates the creation of a pool and
also stores its state. This pattern reduces costs when creating a pool
and doing multi-hop swaps. Because pools are *contract state* and not entirely new *contracts* themselves, pool creation is significantly cheaper.

**v3**: A factory contract is responsible for pool creation. The pool is
a separate contract instance that manages its own state. Pool initialization
is costly because contract creation is gas-intensive

## Flash accounting
**v4**: The singleton uses *flash accounting*, meaning a caller that unlocks the PoolManager
is allowed to cause balance-changing operations (multiple swaps, multiple liquidity modifications, etc)
and only needs to perform token transfers at the very end of the sequence.

**v3**: Because flash accounting is missing from v3, it is the responsibility
of the integrating contract to perform token transfers, after each individual call, to each individual pool contract

## Liquidity Fee Accounting
**v4**: Accrued fees act like a credit when modifying liquidity.
Increasing liquidity will convert the fee revenue to liquidity
inside the position while decreasing liquidity will automatically
require the withdrawal of unclaimed fee revenue.

An additional parameter *salt* can be provided when creating liquidity. The
*salt* is used to distinguish positions of the same range on the same pool.
This separation may be preferred to simplify fee accounting. If two users share the same
range and state in `PoolManager`, integrating contracts must be careful in managing
fees

**v3**: Liquidity positions of the same range and pool will share the same state. While believed to
be more gas efficient at the time, integrating contracts will need to handle fee management since
the state is shared on the core pool contract

## Native ETH
**v4**: Pool pairs support native tokens, in doing so ETH swappers and
liquidity providers benefit from gas cost reductions from cheaper
transfers and removal of additional wrapping costs.

**v3**: ETH needs to be wrapped first before being paired with other tokens.
This results in higher gas costs because of wrapping and transferring
a wrapped native token.

## Subscribers
Only v4: Owners can now set a subscriber for their positions.
A subscriber contract will get notified every time the position's liquidity
or owner changes. Subscribers enable staking / liquidity-mining, but users do not need
to transfer their ERC-721 token.

**v3**: Staking in v3 requires users to transfer their ERC-721 token to a contract, putting the underlying assets at risk for malicious behavior.