Why the Periphery Changed

Key takeaway: V3's core never calls transferFrom — nobody ever grants a pool an allowance. Instead the pool computes what is owed, invokes a callback on msg.sender (uniswapV3MintCallback, uniswapV3SwapCallback, uniswapV3FlashCallback), and verifies payment arrived by checking its own balance afterward. That design pushes a sharp obligation onto every integrator: your callback is a public function that hands out your tokens, and anyone can call it directly unless you verify msg.sender is a genuine pool. Because pools deploy via CREATE2 with constant init code, PoolAddress.computeAddress derives the only legitimate caller from (factory, token0, token1, fee) offline, and CallbackValidation reduces the check to one require. On top of this payment protocol the periphery adds what users need and the core refuses to know about: slippage bounds, deadlines, multi-hop paths, WETH, and NFT position accounting.

The Core Never Pulls Tokens

Search the pool code you wrote in Parts 1 and 2 for transferFrom. It is not there. mint, swap, and flash all follow one shape: compute what the caller owes, snapshot balances, call a function on msg.sender, then require the balance grew by at least the debt ('M0'/'M1', 'IIA', 'F0'/'F1').

This is the callback payment protocol. In V2, users approved the Router, and the Router pushed tokens into pairs before calling them. In V3, the pool trusts nothing about how payment happens — an EOA cannot mint, swap, or flash against a pool directly, because an EOA cannot implement a callback (the debt-free functions — burn, collect, observe — remain EOA-callable). The core is a settlement layer for contracts; convenience is the periphery's job.

Three callbacks exist, one per debt-creating operation: