Vlad Toie - Exploring Uniswap: The Security Engineer's Perspective

So today we're going to explore unis swap. Um we're going to talk about all the versions v1 through v4. U I'm going to talk a little bit about the innovations that each of the versions uh added as well as potential security considerations or vulnerabilities that that each of the versions had. Um so a little bit background about me. I'm a security engineer at Zelic.

I mostly do EVM uh security. um and uh everything related to it. Um I specialized in crosschain protocols uh or um stuff that's generally not DeFi, but in this case we're obviously presenting a DeFi uh presentation, so I should be fine. And I've been a red team before at Deoid. I've been doing pad tests uh for web two uh web two apps uh and web and server security.

uh and in my high school years I've been doing uh CTFs with Hegger Kashbony. Um so why why are why have AMMs been developed? Uh just as a quick background is essentially the public markets uh from traditional finance use a uh order book system. Uh but that's obviously very hard to integrate within the decentralized uh finance and especially in decentralized systems. And so somebody came up with the idea of um a permissionless market making uh which is essentially meeting the buyers and the sellers uh with through an automated process.

So no more middlemen, no more banks, no more uh you know uh essentially no more entities in between the buyer and the seller. Um and for that obviously we all you also need constant liquidity because the markets are generally generally smaller in u decentralized finance than they are in traditional finance. And so you need to access uh you need to allow um swaps between even in markets that have lower liquidity than hundreds of billions of dollars as traditional markets do. Um and obviously we do have the concept of automated pricing which involves um you know a somewhat of a trusted entity of a trusted mathematical formula that dictates the price of assets uh as a ratio of one to the other. Um and so unis swap v1 was introduced in 2018.

Uh it was almost the firstm ever uh because banker was actually the first mm ever. Some most people think that unis swap was, but it wasn't. Uh, and it used a constant product formula or x * y equals k. You probably heard of it. Um, and as a matter of fact, it's a funny story, but actually bankr um tried to um tried to infringe uh their rights to the xy x yals for formula even though the the code is open source.

Uh, and uh there's actually an ongoing case that banker sued unis swap this year. I think a few months ago uh and yeah the essentially the unis swap v1 only allowed transactions between ETH and an ERC20 token. So there was no ERC20 ERC20 pairs uh pools um and the so-called innovation but obviously didn't unis swap wasn't the one to introduce it was the x * y= k formula. Just very quickly essentially X stands for the quantity of token A which let's say in this case is ETH. Uh B uh Y stands for the quantity of token B which we can you know for this example we can say it's USDC and the current price of X uh is the ratio of X to Y in a specific pool.

And so likewise you can calculate the current price of Y to the ratio of Y to X in a specific pool. Um, and as a quick example, we have, let's say there's a pool with uh 10 ETH uh as X and then Y is 2,000 USDC and then obviously K in this case is 20,000 10 * 2,000. And then if we want to swap one ETH to uh um some value of USDC, we can do that by adding one ETH to the pool and then X prime becomes 11 E. And then we need to recalculate how much the user is owed. So we do k divided by 11s to maintain the ratio and that results in 1,818 uh as the new y right and since we upgraded the y we need to calculate how much how much USDC needs to be removed from the pool which basically implies how much USDC needs to the user needs to receive for providing one ETH and in this case the user receives 181.

82 82 USDC for the one e port and so uh as far as we know there's only one vulnerability that affected unis swap v1 uh and as a matter of fact this one was actually reported by consensus in 2019 but uh apparently not everyone respects not everyone reads audit reports so what happened is that um IMBTC essentially um was a ERC7 token which As just a quick background, ERC7 is a ERC20 that has some additional hooks before transfer, after transfer, whatever. Uh, and then uh the UNIS swap V1 was actually vulnerable and in the report it states that it should never allow ERC 7 tokens to be uh swapped in the pool. Uh, obviously they did allow it because there is pretty hard to to to guard against it. And so token loan um created a pool with their token for unis swap and then the attacker essentially the attacker was a ERC7 compatible contract it needs to implement an interface so that um unis swap can call a hook on it when it receives tokens um when it tries to pull tokens from the user I'm sorry and so what happened is that on step one the attacker tried to swap some tokens unis swap v1 pulled send e first and then it tried to pull the tokens from the attacker. But since the attacker knew that a hook will be triggered, what they did is essentially they defined a custom hook function which would simply call swap again.

And obviously since the attacker didn't even get the chance to send the tokens to the pool, what happened is that even though the total supply of ETH within the pool would decrease, the amount of tokens that that the amount of IMBTC tokens that a pool held was was still con constant. So what this resulted in was constant the the user would get constantly and constantly better rates for uh pulling all the for pulling all the tokens from the pool and you would just repeat all the steps again until the uh until the entire pool was drained until the entire pool was drained of ETH. Um and obviously there's a simple fix for this. Even if even if you were to allow uh the re-entry prone tokens of ERC 7, uh you can just pull the token allow the you can just pull the tokens first and then send the ETH. So technically that could have been patched uh beforehand.

Um and then uh unis swap v2 essentially the innovation so to say of unis swap v2 was allowing for onchain manipulation resistant price feeds. And this essentially uh denotes some sort of a fancy way to say that hey we're doing averages of prices across a specific period of time such that you don't always rely on the current price of the token when you want to buy it or sell it. Um and it also allowed ERC direct ERC to ARC20 pair uh the token swaps. Um and so again as I just stated essentially the time weighted average price of using unis swap uh they had a function for that and essentially how it's calculated is uh you take let's say you take a specific time interval uh where the price cumulative uh just simply accumulates over a let's say a 10 block period of time um that the price accumulation always updates uh once per block at the end of the block and then essentially you take the price accumulation at the end of the interval You take the price accumulation at the beginning of an interval and you divide that by the uh by the difference of their time stamps and you get the average price for that specific interval and you can more or less rely on that for having a average price u assuming you're using a stable token pair um for a specific for a specific asset. Um and so general security considerations when developing or using unis swaps a unis swap v2 is uh essentially the dynamic risk of using a protocol's runtime price and the runtime price if you remember if we go back to uh the the the example of unis swap v1 the the runtime price in this case you would assume that you would get 200 USDC for adding one e because you know the ratio is 10 to 2,000.

So if you divide the two, you would get 200. But that's the runtime price. That's the price that the user sees. And then obviously that's not really the price that a user gets because there's a the the constant product formula uh changes in between when the user bought the asset and when the when the asset is returned. And so there's this dynamic risk of okay, how much assets do I actually receive?

And if especially if you're using a large amount of tokens, you don't want to get you don't want to get like um blown out of the way with like 10 10% difference of what the tokens that you're expecting that you were actually expecting uh to get. And obviously you need to use the unis swap's v2 because otherwise you can get sandwiched and uh uh obviously the slippage comes in into play here because you can allow let's say uh I can essentially allow only a 5% deviation from the actual price that I'm expecting. So let's say I'm expecting 200 USDC back, but I allow let's say 10% uh you know difference from the actual 200 USDC. So I can I will be okay even if I got 180 USDC back and not the actual 200. Um so very quickly I just giving an example of how a sandwich attack would occur.

Uh let's say that uh you you're you want to execute a large you know swap transaction. Uh so a a lot of uh tokens uh and in that case the bot the MEF bot could detect your impending transaction in the mele because the memple is a public for Ethereum uh and most EVM um most EVM uh compatible chains and then the both the bot would frontr run would frontr run you by purchasing the same asset right before your trade and then this action would essentially bump up the price of that specific asset within the pool and then what would happen because of the constant product formula and then what would happen is that your your transaction would be put right after theirs. You would obviously get less than favorable rates because of that and then they would background you by selling the same asset and making a small proportion a small a small profit because you you pumped up the price of the asset as well. Um and there's of course there's no known bug for unis swap v2 and we'll see that this is a common pattern from across all the unis swap versions. Uh so we can pretty much say that it's bulletproof apart from the general considerations of the dynamic pricing and so on.

Um but we we haven't discovered any unis swap v2 related uh bug and uh unis swap v3 actually was launched in 2021. So I would say pretty recently um but it essentially introduced uh concentrated liquidity uh to maximize capital efficiency for for liquidity providers. And what this implied is essentially if in unit swap v2 you could you can't really specify where you want your liquidity to be deposited across the entire price range from so essentially your liquidity spans from zero to infinite. Uh in unis swap v3 what you could do is specify a specific range for uh the prices that you want your tokens to be traded at. uh and you would only receive fees for swaps that occur within that specific time within that specific uh price range.

So if e so you kind of you know you can kind of expect that ETH is never going to be $1 again, right? So there's no point of uh you know or even $200. Let's say it's never going to be that low. So what you can do is essentially specify a range of let's say $250 uh and then specify as well a maximum range because if is never going to be you know at least for the next month is never going to be $8,000. So you can just you know cap it to a specific artificial limit and then your liquidity would only be concentrated within that limit and then you're you will gain more fees and essentially you're maximizing the efficiency of your capital as a liquidity provider.

As a as a quick example, we see here a a tick because um since since you know um liquidity is concentrated in specific ticks um and you don't want a specific spectrum and you can like essentially supply your liquidity across a specific spectrum of ticks and in this case uh each tick represents 0.5 of the total supply of the pool. Um generally the liquidity is very tightly um distributed ac across the actual like true value of the of the asset. Um and in this case for example the ETH price was 101.47 uni because it was a it was a ETH touni uh pool and the uh unit price was was uh 0009 ETH u for that specific tick.

If we go to the right or to the left, the price obviously changes. That doesn't mean your liquidity is at risk. Um, and it just means that uh the the your liquidity won't be used. Um, and very quickly consideration because I don't think we have too much time now. Uh, ticks are very easy to manipulate in practice because most of the real price is very concentrated very tightly across a specific number of small ticks.

So what you could do if the if the liquidity is tight enough what he could do is like burn through the tick where the liquidity is concentrated and pump up their price highly and that happened in and that happened in the RA fuse hack because Rari fuse it was essentially a lending protocol that used VUSD to US uh USDC uh oracle pricing and only had $500,000 worth of liquidity. So the hacker bought all the available VUSD which jumped the oracle price to like $1.96 trillion uh which is insane and then they deposited the VUSD which they which was highly valued to borrow as collateral to borrow against rap bitcoin die USDC and so on. Um and why was the attack possible? Well, basically just just as I stated, the liquidity was very tightly concentrated across specific ticks and the user had enough collateral to essentially burn through this through these sticks and uh pump the pump the price.

Um, and this is how the front end looked like like it's a crazy number of uh essentially the the asset price and very quick. Oh, again no known bugs across from apart from this architectural uh issue with u you know unis swap v3 in general and the ticks. Um yeah and obviously Twitter hack the the CEO of unis swap got hacked with a swim swap um sim swap attack and very quickly we're going to talk about unis swap v4 and the most important things you got to learn here is the fact that unis swap 4 is using hooks which are kind of like extra add-on functionalities to the uh actual swap of the pool. uh and it was launched this year so it's pretty fresh but there's already a huge hack that happened. So very important the pool there's only a singleton pool manager contract.

There's no like individual contracts for each pool and there's a concept called flash accounting. We don't have time to go into details here but essentially uh there's like a lot of operations that happen within a specific uh transaction and then only at the end of the transaction the net effects uh the net balances are updated. Um and it seems like the security responsibility is shifted towards uh towards the hook developers. So it seems like unis swap with each iteration is kind of like shifting constantly the responsibility towards the users or the developers that implement on top of unis swap which is kind of interesting and that's why probably a lot of hacks happen. Um so the general architecture is that you start a swap uh the there's a before swap potential before swap hook and then the actual swap happens and then there's a after swap hook and then you end the swap.

This is for the swaps but there's also for supply and liquidity and yeah so hooks cannot be added after the the pool is initialized and uh very quickly we're going to talk about um very you know some security consider some overall security considerations here is that technically they're back durable because you can make the hooks upgradeable and in that case you you know you obviously need to respect the general architecture that unis swap has defined and we already have an example of somebody that didn't respect the general architecture which is a cork protocol. Um cork has some special tokens which involves some you know crazy financial engineering but essentially what they did is what was that their hook of before swap who was only supposed to be called by unis swap's pool like the pool manager singleton contract anyone could call it. So he could like essentially up their entire, you know, pool mechanism of actually supplying the tokens and uh retrieving the tokens. And so the attacker essentially created a fake a fake pool ID, a malicious one. And then uh they kind of tricked their way into into the mechanism of cork in and by calling the before swap before swap call back directly and that resulted in the 122.

5 million uh hack. Yeah, that was all. Thanks. [Applause] Amazing. Glad you went through it.

And I must admit I hate a goddamn methbot. They destroyed my transaction so many times until you started working on the transactions themselves. How did you feel when Metbots first came out on the market, especially through unis swap and front run everything?

Well, honestly, I think it's a it's a pretty interesting mechanic, right? Because it seems very natural that, you know, as long as transactions are public and we want to maintain that openness about transaction in general, there's obviously someone that can profit from that transaction. And I don't find it particularly wrong to profit from transactions because they're public.

And so considering that the mechanism of the pools are respected and you use swap or you use u some specific slippage for your spe for your particular swap, you got to, you know, you got to think of it as fees, right? Uh there's no like banking fees, but it's like okay, you own your own money in a ledger or in your own wallet. You might as well, you know, expect to have some drawbacks through that. And you know obviously flashbots sorry obviously MEV and u you know similar similar very natural very like you know nature mimicking um uh mechanism are to be to be expected.

I have to be honest I turned off auto slippage a year ago when everything started it was crazy. So I want to ask do we have any questions from the audience since I saw nobody's scanning today but I know somebody has very curiosity on how everything on the chain goes with unis swap.

Yeah I knew he had one. He always have a good one. uh you're an auditor at Zelich and I was wondering if Zelich or Zelic um has conducted any audits on Unis swap or participated as uh uh auditors in the open source contests like honant or something. I don't remember a particular unis swap engagement but we do have u audits that focused on unis swap v4 hooks. Uh so it wasn't unis swap before unis swap specific but it was people that implemented on unis swap.

Um and similarly we audited similar forks of unis swap and stuff like that. Well, thanks. As we know, every inter iteration with unis swap and anything that comes out, everybody tries to find a loophole to misuse it and get through it, especially with the hacks you were going through. So, Vlad, again, I want to thank you for coming in and everybody, let's go for lunch and give a big hand for Vlad for coming. Thank you.

Sing it.