An Dialect Older

Two constants and three addresses. Line 15 is a fixed number. Line 16 is the first four bytes of a hashed function signature, the selector you met when you read a raw call. Neither has a storage slot and neither can ever change.

Lines 18 to 20 are the opposite. No `constant`, so all three sit in storage, and two of them hold nothing at all until something writes them. These are the lines that fix a pair to one particular pair of tokens.

Lines 22 to 24 are the ones to slow down for. Two reserves at one hundred and twelve bits each, and a timestamp at thirty two. Add the three widths together and you get two hundred and fifty six, which is one storage slot exactly, and the comment says so out loud.

Lines 26 to 28 are plain `uint` and take slots of their own. Two of them accumulate a price multiplied by seconds. `kLast` holds the product of the reserves. Hold all six names, because everything below moves one of them.

Line 30 declares a `uint` holding one, and lines 31 to 36 are a modifier written by hand. You read modifiers in act two. This one is four lines long: check a value, write it, run the body, write it back.

The underscore on line 34 is where the decorated function's own body is spliced in. So the value is zero for exactly as long as that body runs, and a call arriving at line 32 inside that window fails the check. Tap the four lines in order.

Nine lines between them, and every operation in the file leans on both. `getReserves` hands back three values at once by naming them in its signature and then assigning to those names, which is why its body contains no `return` statement.

`_safeTransfer` builds a call by hand out of the selector on line 16 and sends it with `token.call`. Line 46 is the half worth reading twice: it accepts either no returned data at all, or returned data that decodes to true.

Four events: one for each operation, plus `Sync`, which goes out every single time the reserves are written. Then a constructor that stores exactly one thing, the address that deployed this contract, and calls it the factory.

Line 66 is the other half of that arrangement, because the two tokens arrive afterwards rather than in the constructor. Line 67 is one comparison and a short string. Custom errors did not exist in 0.5, so every message in this file is text.

`_update` is private, and every path in the file ends here. Line 74 refuses balances that would not fit in a `uint112`. Lines 82 to 84 write the three packed values and line 85 announces them. Nothing else in the file touches the reserves.

Lines 79 and 80 are the other half of the job, and they run only inside the condition on line 77. Work out what that condition is really testing before you read any further.

Line 90 calls out to the factory and asks where a fee should be sent. If the answer is the zero address then `feeOn` is false and almost nothing in this function runs. Everything under line 93 depends on somebody having turned that on.

When it is on, lines 95 and 96 take square roots of two products, the stored one from `kLast` and the current one. If the first has grown, lines 98 to 101 mint new shares to that address. Growth in the product is what gets paid.

The first of the three real operations. Lines 112 and 113 ask each token what this contract holds. Lines 114 and 115 subtract the reserves from those answers. What arrived is the difference between the balance and the count, and nobody passes in an amount.

Line 119 splits two cases. An empty pool gets the square root of the product, less a small fixed quantity minted to the zero address. Otherwise line 123 takes the smaller of two ratios. Then line 128 makes the count agree with the balances again.

Line 140 reads this contract's own balance of its own shares. They were sent here before the call, exactly the way the tokens were for `mint`, and whatever is sitting here is the quantity being returned.

Lines 144 and 145 work the two payouts out from the balances rather than from the reserves, and lines 148 and 149 send them. Then lines 150 and 151 read the balances a second time, because the two transfers have just changed them, and line 153 writes that result.

The third operation, and the one to read carefully. Start at the signature on line 159: amounts out, a recipient, and a blob of bytes. No price, no input amount, nothing at all about what the caller intends to pay.

Lines 170 and 171 send the requested tokens out. Line 172 calls the recipient back if any bytes were passed. Lines 173 and 174 then read what this contract actually holds, lines 176 and 177 subtract to find what came in, and line 182 checks a product.

Balances and reserves can drift apart, because anyone may send a token to any address and nothing in this file is consulted when they do. The last two functions are the two ways of ending that disagreement, and both carry the modifier from line 31.

`skim` sends the excess on to an address of your choosing and leaves the reserves untouched. `sync` does the reverse, calling `_update` with the balances so the count rises to meet them. One moves the tokens, the other moves the number.

Two hundred and one lines with the comments dimmed away. A pinned compiler, a library for addition, six state variables, a four line modifier, one private writer, three operations and two reconcilers. That is the entire core of Uniswap V2.

Not one word of it was new to you, only older. So be exact about what these lines settle, and equally exact about what they cannot settle, no matter how carefully anybody reads them.

Nothing here was harder than the act behind you. It was older. A pinned pragma, a library where an operator now suffices, short strings where a custom error would go today, widths chosen so three values share one slot. Those are the marks of a year, not of difficulty.

And the beat worth carrying is line 11. The file you read in week two, byte for byte, holding up half of a contract that has held billions. You had already read half of this one before you ever opened it.