DEV Community: Adi

Before the Swaps: A Map of Uniswap V2

Adi — Sun, 05 Apr 2026 10:00:13 +0000

Recently I did a blog post where we did a quick breakdown of what AMMs are, Uniswap specifically, and built a basic intuition of how things work under the hood. It was initially just supposed to be a quick intro, but it eventually turned out more technical. We covered the Constant Product formula, how it came to be, and how it's been the cornerstone of almost the entire DeFi space (the actual decentralized space, not the protocols that keep showing up with a multisig and claiming to be DeFi, until somehow they get compromised and begin crying that the protocol itself is decentralized and we aren't at fault — it was the keys. Just shut up, if something can put that big of a dent in your core logic then stop calling yourself a DeFi protocol. Yeah, it's DeFi until it isn't. It's unbelievable how there have been so many such exploits in the past few years, but that doesn't mean it prevents new protocols, following similar architecture, from not coming up, not getting funded and somehow not growing to a quintillion dollars in TVL. Sorry I got sidetracked, but it is what it is).

So this is the second post in the series. But before we get into the actual flows — how swaps work, how liquidity gets added, all of that — it's worth taking five minutes to understand how Uniswap V2 is laid out. Not the contracts in detail, we'll get to those one by one in the posts that follow. Just the structure. Think of this as the blueprint of a building you've never been in. You don't need to know where every room is, just where the front door is and which staircase goes where.

If some of the terms or concepts here feel unfamiliar, don't worry about it. By the time we're done with this series, everything here will have clicked into place naturally. This post is just context — a map you can come back to if you ever want to orient yourself while following along.

Two repos, one protocol

The first thing that trips people up when they open the Uniswap V2 GitHub is that there are two repositories: v2-core and v2-periphery. It's tempting to assume this is just an organisational choice (at least thats what I initially thought it was) i.e. someone decided to split the code into two folders and gave them dramatic names. It's actually a deliberate architectural decision, and understanding why it's split that way makes the whole thing easier to reason about.

Core holds the contracts that actually hold your money. That's why its the core. Nothing fancy, nothing extraneous. Because these contracts custody real funds, they are intentionally minimal and completely immutable after deployment. There's no admin key, no upgrade mechanism, no way to patch them after the fact. If a bug were found in Core, the only option would be to deploy a new version entirely. Sounds scary at first, until you flip it around: it also means nobody can change these contracts to do something unexpected with your funds. Ever.

Periphery, well, as the name suggests, lies on the periphery of the core logic. It holds everything that makes Core usable. The routing logic, the slippage checks, the optimal amount calculations, the multi-hop path resolution, all of that lives here. And we will get to it. And crucially, Periphery can be replaced. If a better router gets deployed tomorrow, users can switch to it without the underlying pools changing at all. The pools don't care who calls them.

The split is a trust boundary. Core is what you have to trust. Periphery is just convenience.

What's actually in each repo

Core has three contracts that matter: UniswapV2Factory, UniswapV2Pair, and UniswapV2ERC20.

The Factory is the registry. It deploys new pool contracts and keeps a record of every pool that exists - a mapping of token pair to pool address. When you want to find or create a pool for two tokens, the factory is where you go. One interesting detail: it uses a deterministic deployment method (CREATE2) which means any pool's address can be computed off-chain just from the factory address and the two token addresses, without ever querying the chain. Internally, CREATE2 is just a hash of multiple parameters, one of them being the salt. That means the same parameters generate the same result (the contract address, in this case) every time. If you want to deploy again, just change the salt and you'll get a new address. I'll try to write a separate post on deterministic deployment: the types, the when and why, and when to avoid it altogether.

The Pair is the pool itself. Each deployed pair contract holds exactly two tokens and handles everything: minting LP tokens when liquidity is added, burning them when it's removed, executing swaps, flash loans, all of it. It also stores the price accumulators that make Uniswap's built-in TWAP oracle possible. One thing worth noting: UniswapV2Pair is itself an ERC-20. The LP tokens are the pair contract's own token. Holding LP tokens for a pool means literally holding shares of that contract.

UniswapV2ERC20 is just the base ERC-20 that Pair inherits from, standard token functionality plus EIP-2612 permit support, which lets you approve and act in a single transaction rather than two.

Core also has a couple of utility libraries — Math.sol for the integer square root used in initial LP token calculations, and UQ112x112.sol for the fixed-point arithmetic used in price accumulation. Nothing you need to think about much right now.

Periphery is anchored by UniswapV2Router02 — the contract users actually interact with. Every function you call when using a DEX frontend, or any other integrator, sits here. It handles all four operations, wraps and unwraps ETH for ETH-involving swaps, enforces deadlines, and calculates the optimal amounts before anything touches Core. There's also a Router01 in the repo, but it's effectively deprecated. Router02 replaced it with better support for a broader range of token types.

Supporting the Router is UniswapV2Library, a stateless utility library that handles all the computational work: looking up pair addresses, fetching reserves, calculating swap outputs, walking multi-hop paths. None of this needs to touch state, so it's compiled inline rather than deployed as a standalone contract. And there's UniswapV2OracleLibrary, which provides helpers for building TWAP oracles on top of the pair's price accumulators — if you've ever wondered how protocols get manipulation-resistant on-chain price feeds, this is part of that story.

The helpers that don't live in either repo

Two external utility packages get pulled into V2 that are worth knowing about, mostly because you'll see them imported in the contracts as you follow along.

The first is TransferHelper from @uniswap/solidity-lib. The problem it solves is a real one: ERC-20's transfer() is supposed to return a boolean indicating success, but a surprising number of tokens, USDT being the most notorious, don't return anything at all. A naive require(token.transfer(...)) would just revert on these tokens even when the transfer worked fine. TransferHelper wraps transfers in a low-level call that handles both cases gracefully. It's a small thing, but without it the Router would silently fail on a large class of tokens that people actually use.

The second is FixedPoint from @uniswap/lib, which provides fixed-point number types for the oracle library. Solidity has no native floating-point, so cumulative price values need a way to accumulate fractional ratios over time without losing precision. That's what this handles.

The call flow in one line

For every operation, the path is:

User → Router → Pair → User

The Factory sits to the side, consulted by the Router to find or deploy pair addresses when needed, but not in the critical path of every transaction. The libraries are silent infrastructure, compiled into the Router and never called directly.

That's the map. Keep it somewhere in the back of your head as we get into the flows. Whenever you see the Router calling something on the Pair, or the Pair checking something via the Library, you'll know exactly where you are.

Here are all the contracts and repos referenced in this post, if you want to poke around yourself, although you definitely don't need to do that just yet.

Router: https://github.com/Uniswap/v2-periphery/blob/master/contracts/UniswapV2Router02.sol
Pair: https://github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Pair.sol
Factory: https://github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Factory.sol
TransferHelper: https://github.com/Uniswap/solidity-lib/blob/master/contracts/libraries/TransferHelper.sol
FixedPoint: https://github.com/Uniswap/uniswap-lib/blob/master/contracts/libraries/FixedPoint.sol

Next up: adding liquidity to a pool. This is where the constant product formula stops being theory and starts getting its hands dirty.
In case you missed the intro: x * y = k, and Other Things I Should've Learned Sooner

x * y = k, and Other Things I Should've Learned Sooner

Adi — Sat, 04 Apr 2026 23:01:33 +0000

Getting into blockchain as a smart contract dev is a different experience than entering almost any other sector. Every field has its niche things, sure, but you mostly learn by understanding well-known patterns and implementing them. In smart contract development, though, you actually have to read other people's contracts. Not just snippets, the whole thing. That's how you grow, and the best way to do it is to go through some of the most battle-tested protocols out there.

And Uniswap is the obvious place to start. It's been one of the cornerstones of DeFi for as long as I can remember, long before I even got into the space. So every once in a while I'd think, alright, today's the day. Then I'd open the repos. Two of them, and a couple of utility repos too. Multiple contracts cross-referencing each other. An actual whitepaper with actual math in it (and with my just-above-average mathematics, I wasn't exactly jumping for joy. I still am not). The tab would go into hibernation, and I'd tell myself I'd pick it up properly once I got through whatever I was currently working on.

Procrastination, basically.

If you're in the same boat, whether for the same reasons or just because you actually have other things that keep getting in the way, this series is what I wish I had. I went through the entire thing, cross-referenced everything against the actual contracts, and wrote it down in plain English with math I could understand myself. The goal was to cover it completely, without cutting corners, but in a way where you could open the contracts side by side, follow along, and realize by the end that you'd essentially read the whole thing without it ever feeling like you were.

Turns out Uniswap is one of those things where the more you understand it, the simpler it gets. Not the other way around. The surface looks intimidating. Underneath it is one equation. Once that clicks, the rest assembles itself pretty quickly.

So. Let's get into it.

The thing that I kept pushing to "later"

Uniswap launched in November 2018. Quietly. No token, no VC fanfare, just a blog post and a GitHub repo. It really must have been different times altogether, feels medieval almost. By the time DeFi Summer hit in 2020 and the entire space lost its mind over yield farming, Uniswap was already the backbone of a significant chunk of on-chain trading volume. While Aave and Compound were building decentralised lending, and Curve was figuring out how to swap stablecoins without destroying the peg, Uniswap was the place where the long tail of tokens actually got traded. New project launching and wants liquidity on day one without negotiating with a centralised exchange? Uniswap. Protocol needed a price feed that couldn't easily be manipulated? Uniswap. It became infrastructure almost by accident.

The protocol has gone through four versions now, and the version history actually tells you something useful about what problems were being solved at each step.

V1 was the proof of concept - launched in November 2018, it worked, but every token could only trade against ETH. Want to swap USDC for DAI? That's USDC → ETH → DAI. Two hops, two fees, and you're briefly exposed to ETH's price in the middle of a transaction you intended to be completely stable. It proved the core idea was sound. It didn't quite prove the model was ready for everything people would want to throw at it.

V2 fixed that. Direct ERC-20 to ERC-20 pairs, better resistance to price manipulation, flash swaps, and a cleaner architecture overall. It shipped in May 2020 and became what most of the DeFi ecosystem actually built on top of. The forks alone tell the story: Sushiswap, Pancakeswap, Quickswap, and dozens of others across every EVM chain that launched afterward were essentially V2 with a different coat of paint. If you've used a DEX on any EVM chain other than Ethereum mainnet, there's a good chance it was running V2 logic underneath.

V3 arrived in May 2021 and introduced concentrated liquidity — LPs can now choose specific price ranges to deploy their capital into rather than spreading it uniformly across the entire curve. More capital-efficient, but meaningfully more complex to reason about. We’ll cover this too. Sometime. Soon. Hopefully.

V4 launched in January 2025 and is a different kind of upgrade altogether — it turns Uniswap into a developer platform. The headline feature is hooks: modular contracts that let developers inject custom logic into pool creation, swaps, and liquidity management. On top of that, a singleton architecture consolidates all pools into one contract, making pool creation up to 99.99% cheaper than before. It's powerful, and it's going to be interesting to watch what gets built on top of it. Yeah, considering me, covering this one “soon” might be a stretch.

V2 is still the right foundation to understand first. V3 and V4 both build on concepts that V2 establishes i.e. concentrated liquidity, which makes no sense without first understanding uniform liquidity, and hooks customize a swap flow you need to already understand. You can reason through V1 in about five minutes once you have V2. Everything else follows.

So V2 is where this series lives.

How does it actually work?

On a centralised exchange, there's an order book, which is a live list of people willing to buy at various prices and people willing to sell at various prices, with a matching engine pairing them up in real time. The price at any moment is just wherever the last match landed. It works because there are enough participants that someone is almost always willing to take the other side of your trade.

Uniswap has none of that. No order book, no matching engine, no counterparty. Just a smart contract sitting on-chain with two tokens locked inside it, ready to trade with you any time you want. You want USDC, send it ETH. It'll give you USDC back. The question that actually matters is: how does it decide how much?

Think about it from the pool's perspective for a second. It holds some amount of ETH and some amount of USDC, and it wants to behave like a reasonable market. It has no external price feed. It has no idea what Binance is doing right now. All it has is the ratio of what it holds. And that ratio is actually enough, because the ratio is the price. If the pool holds 100 ETH and 200,000 USDC, the implied price of ETH is 200,000 / 100 = 2,000 USDC. Simple division.

The problem is keeping that relationship stable in a sensible way as trades happen. If you just let people take whatever they want, the pool drains. So the pool needs a rule. And the rule it uses is this: whatever you do to this pool, the product of the two token balances cannot decrease.

If the pool holds x of one token and y of the other, then at all times:

x · y = k

That's the rule. k stays constant. You want to take some ETH out? Fine, but you have to put in enough USDC that the product of the new balances still equals k. The pool doesn't care what the "right" price is — it just enforces that one equation, and the price falls out automatically.

Work through a concrete example. Pool holds 100 ETH and 200,000 USDC. k = 20,000,000. You want to buy 10 ETH. After giving you 10 ETH, the pool has 90 ETH. To keep the product at 20,000,000, it now needs 20,000,000 / 90 ≈ 222,222 USDC. It had 200,000, so you owe it 22,222 USDC for those 10 ETH.

At the pool's implied price before the trade, 10 ETH should have cost 20,000 USDC. You paid 22,222. The extra 2,222 is what buying 10% of the pool's ETH supply in a single trade does to the math, and it points to something important that we'll come back to in a moment.

Here’s an image I found that visualises this nicely. The quantities of token A and B act as x and y, and every valid state of the pool lies somewhere on this curve defined by k. Trades don’t change the curve — they just move the pool along it.

This is the Constant Product Formula. The name, at this point, is fairly self-explanatory. The product stays constant. k doesn't move. And the system built on top of this - a smart contract that always quotes a price, always accepts a trade, at any size, at any time, with no humans or order books involved, is an Automated Market Maker. It makes markets. Automatically.

Whose tokens are in there, and why

Uniswap doesn't own anything. Every token in every pool was put there by someone who wanted to earn a return on their capital, and those people are called liquidity providers, or LPs.

The word liquidity here means roughly the same thing it means in traditional finance, i.e. the availability of an asset for exchange without significantly moving its price. A pool with $10 million worth of tokens in it has a lot of liquidity. A pool with $50,000 in it doesn't. When you deposit into a pool, you're increasing its liquidity, which is where the term comes from.

To deposit, you have to provide both tokens, in proportion to the current ratio of the pool. You can't just throw in ETH and call it done. You need the matching USDC too. This is to preserve the existing ratio, because depositing in a different ratio would shift the pool's implied price, and that's not something the pool will just let happen without the math demanding compensation for it. In return for depositing, the pool mints LP tokens and hands them to you. These represent your ownership stake. Deposit 5% of the total pool value, you get tokens representing 5% of the supply. They're regular ERC-20 tokens which are fully transferable, and your ticket to getting your deposit back whenever you want.

Every swap that goes through the pool charges a 0.3% fee. That fee doesn't get sent anywhere; it just stays inside the pool, incrementally growing the balances above what k alone would predict. Since LP tokens represent a share of everything in the pool, and the pool is quietly getting larger with each swap, those LP tokens are gradually becoming worth more. When you eventually do want out, a process the contracts call burning, you hand back your LP tokens and receive your proportional share of the current pool: original deposit, plus your cut of every fee collected since you put the money in.

The total value of all tokens across all pools in the protocol is what people refer to as TVL — Total Value Locked. It's the number that gets cited when people talk about how large a DeFi protocol is, and it matters practically because it determines how smoothly the pool handles large trades without moving the price too much.

What actually happens to the price when you trade

Back to that example. The pool had 100 ETH and 200,000 USDC, and you bought 10 ETH for 22,222 USDC instead of the "expected" 20,000. That gap exists because of something called price impact, and understanding it is probably the most useful intuition to take away from this entire post.

The spot price at any moment is just y / x — the ratio of the two balances. Before your trade: 200,000 / 100 = 2,000 USDC per ETH. After your trade: 222,222 / 90 ≈ 2,469 USDC per ETH. Your single trade moved the price by about 23%.

That's an extreme example. Buying 10% of the pool's ETH supply in one go will always hurt you, but the shape of the relationship is what matters. Look at the formula: spot price is y / x. When you buy ETH, x (ETH in the pool) shrinks and y (USDC in the pool) grows. Smaller denominator, bigger numerator, price goes up. When you sell ETH, the opposite happens. The pool is always drifting toward whatever ratio reflects the last trade, which is what keeps it loosely aligned with external market prices. If the pool's implied price drifts too far from, say, Binance's price, arbitrageurs come in and trade it back into alignment, profiting from the gap and correcting the pool's ratio in the process.

The gap between the price you saw when you submitted your transaction and the price you actually executed at is called slippage. It comes from two sources: your own trade moving the pool (price impact), and other transactions executing before yours and moving it first. Larger pools suffer less from both. A 10 ETH trade against a pool with 10,000 ETH barely registers. Against a pool with 100 ETH, it's significant. This is why liquidity depth matters, and why a newly launched token with a thin pool on Uniswap can swing 20% on a single moderate trade.

There's one more property the formula has that's worth appreciating: the pool can never be fully drained. To get all the ETH out you'd need to send in an infinite amount of USDC, since as x approaches zero, the price climbs toward infinity. The curve is a hyperbola, and the pool always lives somewhere on it. Every trade just moves you to a different point.

Uniswap didn't invent AMMs but it defined the template

Once V2 proved the constant product model worked at scale, a reasonable question was: what if the formula were different?

Curve Finance, which had launched around the same time, looked at the stablecoin problem and noticed something. If you're swapping USDC for USDT, two assets that are both supposed to be worth $1, the constant product formula still moves the price noticeably on large trades, even though economically, the price essentially shouldn't move at all. Curve replaced the formula with a hybrid that behaves like constant product near the edges of the curve but much more like a flat line near the peg, where stablecoin trades actually happen. The result is dramatically tighter pricing for like-valued assets. Curve became the dominant venue for stablecoin and liquid staking swaps for exactly this reason, and still is.

Balancer took a different angle entirely. Instead of two-token pools with equal weighting, it generalized the model to support up to eight tokens with arbitrary weight ratios. A pool could hold 80% ETH and 20% USDC, and the AMM mechanics would keep it at that ratio automatically as people traded against it. Effectively a self-rebalancing index fund that earns swap fees. Don’t worry if some of these terms feel a bit unknown, by the end of the series, you’ll be flowing through these like a proper crypto bro.

Both of these, and the dozens of AMM protocols that came after, are built on the same underlying insight Uniswap established: encode your pricing rule as a mathematical invariant, let the market trade against it, and price discovery happens by itself. The specific formula is a design choice. What Uniswap figured out first was the architecture. Four versions and nearly $3 trillion in cumulative trading volume later, that original insight is still at the centre of all of it.

The four things you can actually do

Everything on Uniswap V2 is one of four operations, and this series is going to go deep on each one in the posts that follow.

Swapping is the one everyone has used — send in one token, get back another, rate determined by the constant product formula, 0.3% fee taken from your input.

Adding liquidity, which the contracts call minting — deposit both tokens in the right ratio, receive LP tokens representing your ownership stake, start earning fees.

Removing liquidity, which the contracts call burning — hand back your LP tokens, get your proportional share of the current pool returned to you, fees and all.

And flash loans — borrow any amount of tokens from the pool with zero collateral, do whatever you want with them within the same transaction, return them before the transaction closes. No approval process. No credit check. Nothing. If the money isn't back by the end of the transaction, the whole thing reverts as if it never happened. The EVM's atomicity is the security model, and the whole thing was designed this way deliberately. It's used for things like arbitrage across protocols, liquidating underwater positions in lending protocols, and swapping collateral types without needing upfront capital. It's one of those things that sounds like it shouldn't work until you think about it for a minute and realize it couldn't possibly not work.

Each of those four flows has a lot going on underneath — the actual contracts, the exact math at each step, and a handful of design decisions that look strange at first and make complete sense once you trace through them. That's what the upcoming posts are for.

If the constant product formula is starting to feel intuitive rather than just symbolically familiar, you're in exactly the right place to continue.

Next up: Before the Swaps: A Map of Uniswap V2