Unchained - Uniswap Founder Hayden Adams on How ‘Hooks’ Make v4 Different - Ep. 508

Episode Date: June 20, 2023

The announcement of the upcoming launch of Uniswap v4 sparked fresh versions of old debates. Is it OK for DeFi’s leading DEX to not be fully open source at launch? What counts as composability and what counts as plagiarism? Is Uniswap’s dominance a threat to decentralization? Founder Hayden Adams joins the show to respond to the critics and explain the novel features of Uniswap v4.  Listen to the episode on Apple Podcasts, Spotify, Overcast, Podcast Addict, Pocket Casts, Stitcher, Castbox, Google Podcasts, TuneIn, Amazon Music, or on your favorite podcast platform. Show highlights: how Uniswap was born and how it has evolved since 2018 how the SushiSwap vampire attack was a win for Uniswap  whether the new version of Uniswap brings it closer to the true ethos of Ethereum what the problems were with the previous fee model and how the new v4 approaches fee tiers an explanation of “hooks,” the most important feature of the new code what Hayden thinks the most common uses of hooks will be how v4’s time-weighted average market maker (TWAMM) feature works  whether Hayden is worried that hooks will be engineered to do rug pulls what Hayden thinks about v4’s new “singleton” approach how EIP-1153 (if implemented) will make Uniswap v4 more efficient  when Hayden estimates that the v4 code will be deployed  why Uniswap decided to go with a four-year business license Hayden’s response to allegations that Uniswap plagiarized Crocswap for its v4 code whether there’s a risk that U.S. authorities blacklist certain transactions on v4 whether it is possible to add KYC and AML compliance into v4 pools why Hayden is sad about the U.S. approach to regulating crypto why he believes that Uniswap will not become a centralizing force Thank you to our sponsors! Crypto.com TOKEN2049 OKX Guest: Hayden Adams, founder of Uniswap Links Unchained: Uniswap Releases Draft Code for V4 Uniswap V3 Forks Are Now Legal After BSL Expiry Liquidity Pools: How DEXes Allow Trading Uniswap: Our Vision for Uniswap v4 EIP-1153: Transient storage opcodes v4-core/LICENSE at main · Uniswap/v4-core · GitHub Frax Finance’s Sam Kazemian tweet TWAMM - Paradigm Learn more about your ad choices. Visit megaphone.fm/adchoices

Hi, everyone. Welcome to Unchained, your no-hype resource for all things crypto. I'm your host, Laura Shin, author of The Cryptopians. I started covering crypto a years ago, and as a senior editor at Forbes, was the first means-free meter reporter to cover cryptocurrency full-time. This is the June 20th, 2023 episode of Unchained. You know it, we know it, they know it. The system doesn't just need an update, it needs a complete rewrite. Web3 offers that rewrite. It allows us to take control trollback and to truly own what's ours. Visit okayx.com slash rewrite the system to learn how. Asians buzzing and everyone's going to Token 249 Singapore on September 13th to 14th. Paulusie Srinivassin, Mike Novagrats, Arthur Hayes and 200 others will hit the stage, joining over 10,000 attendees. Visit Token249.com for 65% off with the code unchained. Link in the description. Buy, trade, and spend crypto on the crypto.com app. New users can enjoy zero credit card fees on crypto purchases in the first seven days.

Download the crypto.com app and get $25 with the code Laura. Link in the description. Today's guest is Hayden Adams, founder and CEO of Uniswap. Welcome, Hayden. Thanks so much for having me. It's amazing that Uniswap is onto its fourth iteration already. Let's walk listeners through the evolution of Uniswap from V1 through V3. Sounds great. And before I even say that, I just, maybe you don't, I don't know if you know this, but Unchained was actually the first podcast I ever did. And last time we spoke.

Yeah, I don't know if I knew. I might have known that. It was so long ago. It was like 2018, wasn't it? Yep. Wow. Yeah, V1 launched in 2018. And I don't remember exactly when we spoke, but it was around then. Yeah, yeah. I also don't remember exactly. But amazing that it's been five years. because it feels somewhat recent to me, which is kind of funny. But anyway, I'm glad that you made Unchained your first podcast choice. Yeah, definitely. It was great back then and excited to be here now. In terms of like the evolution, I think even what you just said there, like in some ways it feel like we think of Uniswop as having been around for a long time and

AMMs and all the stuff that we talk about with OnChain trading. But, you know, Uniswap has only been around for five years. And before Uniswap, there were other projects experimenting with AMM, but it was like a relatively untested new thing. And going from Uniswap v1, which launched in November 2018, back then it was like, is this a thing? Will this have a place in the world? Will there, like, is there some need for on-chain trading and is there some need for automated market making to today where Unswap, you know, trades billions of dollars a day, has, you know, There's been over $1.5 trillion traded since then. On the protocol, and it has such an act, like, AMMs are actually the predominant way people trade between crypto to crypto assets on chain, right?

Like back then it was like, does AMM have a role relative to limit orders? And today it's like, oh, do limit orders have a role relative to AMMs in the space of on-chain trading, which is really interesting? Probably jumping the gun on some stuff there. Really, you know, Uniswifoy 1 built that initially almost as. like a solo side project. It had a lot of help along the way, but, you know, essentially was the only full-time person on it, developed it under a, you know, got a grant from the Ethereum Foundation and launched it in November 2018. It got like all this initial excitement and traction in the, in the industry. I think in part because it really like resonated with people's values in the

space at the time. It was kind of the anti-hype. Like there was all these like projects that had set huge expectations, raised huge amounts of money and then didn't really deliver on the hype. Uniswop, you know, all it had was this small grant. No one knew about it until it was live and working. And it really resonated with people and it really like matched like the level of decentralization that Uniswap reached, you know, where it was like not upgradable, you know, immutable permissionless, anyone could create, you know, an asset, anyone could add a, create a liquidity pool.

That resonated in the early days. And so it got this initial traction and excitement from, you know, almost like long-tail projects on Ethereum. And, you know, so I raised money and formed a company. I was like this, just the idea to me had been validated. So I decided to take it to the next step and form the company. And just remind people, those original pools were based on that X times Y equals K. Just explain that for people.

Yeah. I mean, it's not really that, you know, the idea is that in traditional exchanges, you have, you know, limit orders and that you're matching up buyers and sellers. Uniswap had this pool liquidity model where you deposit two tokens into a pool. They would be paired against each other, and you could buy one for the other and sell, you know, you could buy and sell between them and it would just move the price along a curve. And that curve is just X times Y equals K, where there was like a constant, you know, value. And that was how prices were set. It was very simple, very, like, simplistic, but it worked. And I think that that is like such a key to this whole story is that there was a lot of early, like, the earliest negative baby feedback that Unislaw received was like, this is too simple and too dumb. Like, you can't, you can't just, like, create a stupid dumb on-chain trading strategy and expect it to, like, make, you know, be profitable for people to do or beneficial for people to do. And I think in a way they were right, in a way it was too stupid and dumb to really, like, you know, exist forever. But at the same time, it provided, like, the benefits of it offset the downsides of it, if that makes sense.

Like, the level of decentralization it achieved, the level of, like, you know, like, like, the fact that no one needed. to trust anyone else, the fact that anyone could create, you know, anyone could create a liquidity pool without having to have like an extreme level of sophistication. Like, yes, it wasn't sophisticated enough for the most sophisticated people to want to come in and participate in it, but it was like unsophisticated enough that anyone could participate in it. And the ability for just anyone to create a liquidity pool was so different and new from anything else that was around at the time. Even other early AMMs didn't have an experience where like anyone could come in and create a pool, at least even like at the front end level,

it allowed it at smart contract level. So that was such a big unlock that it didn't matter how inefficient the system backing it was at the time. Because no one else, there was no other way to do the things that allowed you to do for certain people. From there, we spent the next four or so years basically building new versions of the protocol, improving it. V2 took it from, V1 basically only allowed you to trade between ETH and an ERC20 token. And it was kind of an interesting, very opinionated. It was my first coding project is one way to look at it. And so it was okay.

But it wasn't like, it wasn't a system on which an entire like industry could be built to put it one way. And so V2 really was just like upping like the architecture, the code quality. You know, it did add a few more features. It allowed you to trade any ERC20 for any year C20, which enabled things like stable coin to stable coin trading instead of just eat the stable coin. So it added like a few new features.

It was just like better infrastructure, easier to interact. with, but it wasn't, and like just a better code base. And that was sort of what going to at the launch of V2, probably Uniswap was doing a few million dollars a day in trading, maybe like five to 10. And that was in spring 2020, about a little bit over a year after the launch of V1. And that is sort of when things kind of like went crazy. And we had what was called DFI summer. And Uniswap V2 went from doing like five, 10 million dollars a day in trading in the spring to by the fall, it was doing, you know, it had passed a billion dollars a day in trading. There was a token added to the protocol every 10 minutes for the entire summer.

And just as a reminder, also, I think that milestone was also reached partially because of the sushi swap vampire attack. Yeah, for sure. Definitely. Like, there was, I mean, it was growing really fast over Defy Summer as like, you know, compound had launched. All these other projects had launched their tokens and more tokens were starting to come out. And so it was already accelerating.

but then definitely, you know, when sushi swap happened, it really did go parabolic at that moment. You know, Uniswap liquidity went from a few hundred million to a few billion, and then the daily trading also went up proportionally. And I think what the reason you sushi was so good for Uniswap was because there was sort of this like chicken egg problem with people, like, there wasn't enough liquidity to like support the volume to support the liquidity. And we didn't really know how Uniswap would operate at like that scale. And sushi. kind of the sushi vampire attack because of the way that it was structured really incentivized liquidity to pour into uniswap and the plan was to migrate it all at once but so much liquidity

poured into uniswap that people got to see how it how it operated at you know billions of dollars in scale as opposed to like low digit digit hundred millions and uh it sort of performed very well and so i think that you know even after the sushi vampire attack migration happened the liquidity didn't really leave uniswap i mean some liquidity did but the uniswap's liquidity after the the vampire attack was much higher than it was before. And definitely the whole, you know, and then after, after all of that, there was even more projects launching. And that was like really like a pretty kind of like a moment of a lot of change in the space.

From we had actually been working on V3 since before the launch of V2 though. V3 is the earliest ideas of V3 development were like ideas that we'd been playing around with while developing V2. And so even at the time we launched V3, we realized concentrated liquidity. was like the next step. And I think that for a while, some of that stuff felt like it was a distraction from getting to where we knew

we wanted to go with V3. I think ultimately I'm glad it all played out and it worked out for the best. And it was an exciting time. But we launched V3 about a year after V2 and about six months after the whole sushi saga kicked off. And V3 basically made the protocol a lot more, you know, V2 was a very simple price curve

and everyone had to like opt into the single way of managing their liquidity and trading it. and it was somewhat inefficient, but it was like the same for everyone, so it was so simple anyone could do it. And there was no competitive dynamics between LPs because they were all kind of like in it together for better for worse.

But I think the downside was sometimes it was for worse. The, you know, V3 came out. I think at the time of V3, there was a lot of open question. Like there was, I think it took a long time for people to understand it. I think people are still kind of wrapping their head around V3, even today.

And it came out about two years ago. And, you know, it basically, basically just let people set price ranges in which their liquidity existed. And so, you know, in the, in the sort of, you can, it can, you can, you can, you can kind of approximate an order book with it a little bit. Like, you can imagine, like, if you set a, you know, I'm going to trade this token between this price and this price in a very narrow range that looks very similar to creating a limit order. I think it's still kind of different. You know, there's sort of like a pro rata nature to it where you're still pooled with other people and it's still a long

curve, not at a single price. But all that to say, V3 increased like the, it essentially increased the capital efficiency, it increased the flexibility for liquidity providers very significantly. But maybe to lead into where I'm going with V4, like, you know, I'd say that V3 was still an extremely opinionated protocol. And what I mean by that is the way that we developed V3, V3 was essentially the best single implementation of an AMM that we could imagine at that time. And I think it did very well. V3 kind of took you to swap from like, kind of like significant market share to like, you know,

today it's like 85, 90% in on chain trading on Ethereum and has just sort of like completely outperformed the V2 style pools in terms of the share of volume and the efficiency of it. But it was like very opinionated. The process of basically designing an AMM in my experience has been like getting in a room with smart people and just like arguing for hours about tradeoffs and minor tradeoffs. And like it's just like endless bike shedding is one way to think about it. And every single decision we made impacted other things. And it's like things that benefit LPs, hurt swappers, things that benefit active, you know, the increased complexity adds new features, but like makes it harder to integrate.

And that hurts developer. And every single part of the entire codebase was just like a constant series of tradeoffs. And I think that that's what to me really exciting about where the un swap protocol can evolve with unsoft v4 is, you know, to be unswap v4 is about taking, creating a basically like an AMM platform where people can express their preferences and choose where they want to be in like the AMM design tradeoff space. And definitely it adds additional complexity. And there's a lot of things that that, you know, there's a lot of implications to that. And I think that like people are still wrapping their heads around V3.

They're definitely still just wrapping their heads around, around V4. But for me, at least, I think that I feel really confident about it as like the direction for where this protocol should go next. And so I'm, and I'm personally really excited. said it about it. You know, the Unspot protocol has become such a, like, important part of the industry. Like, it's, there are quite literally like thousands and thousands of teams and projects. There's hundreds of thousands of tokens on the protocol. There's tens of thousands of projects that are built on top of it. And to me, I view Uniswap like I view Ethereum. And it's like, it's a core

infrastructure layer for, you know, Ethereum maybe is a core infrastructure layer for more things. but Unispop is still like this core infrastructure layer for creating liquidity and trading on chain. And it serves all of these different projects. Just one thing is that when you say it's like Ethereum, it's not only Ethereum in those ways, but I feel like this new V4 is also becoming more like Ethereum in the sense that when Vatolic was dreaming up Ethereum, part of the reason was that he was noticing that people were trying to innovate on Bitcoin and the way that they were doing it was adding new features to blockchain. chains. And both of you, so with Ethereum, what he did was, you know, he stripped all that away.

It's like a programming language. And then anybody can have any idea that they have and upload it to Ethereum. And you're essentially doing the same thing but for AMMs. And you're, I don't want, I mean, I don't want to describe it, but just very briefly, you're stripping it down. So, like, other people can be like, oh, I have an idea for an AMM that, you know, does fees this way or that it, you know, does what I don't know what all the different variations are, but it's like literally the same move. Yeah, definitely. I think that totally resonates with me. And I think that, like, I definitely have, like, look to Ethereum as guidance for, you know, what I think is, like, a good, good project within the, within the crypto space and has, like, good philosophies behind it.

You know, and there are, you know, a lot that can go into that. And there's a lot that can go into that. And there's a lot that you could have back there. But definitely, like, I move towards greater expressiveness and customizability, a generalizability. And it's not turning completely. like Ethereum, but it is closer to Turing complete than, you know, than Unisvot v3, and that you can express more preferences and do a lot more with it. So aside from that, in fact that, you know, you were sort of dictating choices onto developers. There were also actual problems just like with using it and stuff. So what are some of the problems that you wanted to try to solve with Uniswap V4?

And what are the features and solutions that you've come up with? Yeah, that's a great question. let's see. So Uniswap V3, like I'd say that for me, some of the most interesting, I'd say that like one very interesting starting place is fees, like liquidity provider fees. You can ignore the other forms of fees of gas fees and governance fees and all that. I'd say that like liquidity provider fees for like the longest time in Unswap's history, it's always been like, what is the optimal fee? And, you know, how do you set it?

And all of these, you know, for liquidity providers. and the answer has always been like like the v1 it was like okay we're just going to you know we don't want like we don't want to introduce some governing system we don't want to introduce some like like let's just make it you know 0.3 percent and that that was that was the number it was the magic number and it kind of worked you know in a way actually started out as 0.25 percent and I was on a plane with Vitalik and we were having a conversation and he said and I was like oh I don't know I'm worried 0.25% might be too low. And he's like, we could do 0.3%. And I was like, okay. And I changed the code. And that's how it happened. That was all the thought that went into it. V2 kind of had a similar pattern. V3 introduced fee tiers, which was basically like anyone could deploy. You could deploy pools with a bunch of different fee tiers. And the idea here is that like the more sophisticated liquidity provision, the the more trading volume that's going through a pool, probably like very often lower fees are, are better than higher. Another thing is like the volatility of the asset, like a very volatile

asset, you might need higher fees to make up for, you know, losses that you might incur for providing liquidity, right? When you're providing liquidity, you are taking on price risk and the way that you offset those losses is you take if you earn fees. And so if an asset is very volatile, you usually want higher fees. However, there's like this other thing, which is that like, there's different forms of volume. There's some volume that is just driven by volatility, and then there's some volume that is driven by just user demand to trade an asset. And there's papers theorizing around like the optimal way to set fees based purely on volatility. And if you imagine a world where the only trades that exist are arbitrage trades,

probably going way too deep on this one, very specific thing. But if you imagine a world where like the only trade to arbitrage trades, you can like theorize around like the optimal fee to set. But you don't know how that optimal fee will impact the user's demand for trading into that liquidity. that is not driven by arbitrage, but driven by just like a desire to trade one asset for another. And, you know, some people, you kind of think of the users as like maybe the less sophisticated and the arbitrage traders as the more sophisticated. So like any, there is no like single way to set the optimal fee.

The only way to do it is in imagining an arbitrage only world. And so in the arbitrage only world, the higher the volatility. But then there's also another factor of gas costs. And the lower the gas fees, actually, the lower the optimal fees for liquidity providers. And that's because the lower the gas fees, the smaller arbitrage trades are worth making. And so if you lower the liquidity providers fees, you have a lot more arbitrage closer to the current price. And so there's sort of like this benefit of having in a lower network fee world, you also want a lower

liquidity provider fee world. So there's like all of these like, it's kind of a complex situation. And so there are like a lot of interesting ways to experiment with setting it. So with V3, we had like a few different granular fee tiers. like we had like 1%, 0.5%, 0.3%, and 0.1%. There's a few of them. And that allowed people to like better liquidity providers can make their own choices and allocate across them.

And that increased the flexibility while fragmenting liquidity a little more. And there's a gas cost imposed. The more liquidity split across liquidity pools, the more gas costs you're wasting to arbitrage between the pools. And if I want to make a trade and it's a very large trade, I now need to about maybe some portion of my trade should go to the 0.3% pool. but only up until it moves to trade 0.3%. But then the remaining should actually now,

or like once the trade, like the price impact has increased beyond, maybe a better example. So if you have imagined a 0.3% pool in a 1% pool, if you make a trade that moves the price on the 0.3% pool more than 1%, you're going to want to start including liquidity in the 1% pool because the price impact of the 0.3% pool is no longer offsetting the, the fee of the 1% pool. And so these are like very fundamental problems, right?

Like, the more pools you have, the more liquidity is fragmented. The same time, the more, like, the less you can express your, like, at the same time, like, there's no single best way to determine the optimal fee. And the way that, you know, it works on an order book is just everyone is choosing for themselves. And it's very efficient to aggregate that all on chain and off chain. And it's not very efficient to allow anyone to set any fee and aggregate all of that on chain. And so you kind of need like liquidity to coalesce around certain, certain fee tiers. I'll say with Uniswap V4, I think one of the most interesting problems is it basically just like says like anyone can create any system for how the fee is set. You can continue to do dynamic fees and you continue to do like static fees.

There probably will still be like point three percent fee tier pools. But there might be like and this, you know, fee tier moves with volatility and this fee and this fee, you know, and you can create systems like that as well. you know, I think that like it's going to be very interesting to see. Like I think like entire AMMs have been created to just experiment with fee designs. And I think something that's very nice about Uniswap V4 is you actually don't need to create an entire AMM to experiment with fee designs. You can create a fee fee like a dynamic fee hook, which is much simpler and easier to do than creating an AMM. And it's much easier to get people to trade into it. And it's much more like adoption of it.

And just explain hook because, you know, this plays a key role in Uniswap V4. Yeah, Unswap v4 introduces what we call hooks, which are various points in, you know, every transaction on Unswap has like, there's like a life cycle to a transaction. Like, you know, like for a swap, maybe like send the tokens to the pool, like the price adjusts and then the pool sends your tokens back. The idea of a hook is that it's arbitrary, like you can insert arbitrary logic. When you create a pool, you can create a, you can define like the hook logic for that pool. Like how, and you can create a hook contract that interacts with various points in the life cycle of a transaction. And so you could imagine. imagine you have a hook that before every swap, it runs some arbitrary logic. Or you can have a hook where after every swap, it runs some arbitrary logic or before anyone adds liquidity. And through these hooks, you can basically create, you can also have hooks that basically adjust the fee for the pool in real time. And maybe it's doing that by like before the swap, it checks the price. And based on the price relative to the previous price, it has some implied volatility number and adjust the fee up or down based on that. Right?

that's the type of thing that you can start doing. But at its core, a hook is like an external smart contract that's interacting with the Unoswap protocol. Is that how to think of it? You can think, I mean, that's one way to think about it. There's sort of like how the smart contract are organized is interesting with Uniswap and we could get that a little bit. But generally speaking, you could think of it as smart contract logic that can interact with the protocol at various points within, like not like today, you know, you have transactions that can interact with the pool, but they can only interact before the entire transaction has happened

and after the entire transaction has happened. But there's sort of no way that you can kind of like interject at like points within a transaction. Generally speaking, it's like logic that you're sort of guaranteed will run with every transaction that interacts with that pool. I actually thought there was a, there was a, I listened to like a 30 second clip with what is it, chopping block or the where they were talking a little bit about it,

like what's different here? And like what can you do externally versus, within a hook and what is like, I think like an example of something that you can do, that you can only do with hooks that you can't do today externally is, you know, a, like, there's a certain, like, so one of the features in, you know, Svap V2 and V3 is this price Oracle. And for the price Oracle to be, you know, to work, you need a guarantee that it will have, that it will be updated before the first swap of every single block. And to have that type of strong guarantee, you can't do that externally.

because you could build a router that checks the price before it swaps and checkpoints it, but someone else can always interface directly with the pool and avoid updating your Oracle. And so the cool thing about the hook contract or the hook design is that you can create a pool that will guarantee the properties of your Oracle in a way that a routing, a hook and a router could never do. That's an example. I think there are others. Another maybe example, part of where hooks came from is we had since been, Before V2, we've had this running idea in the back of our head.

And you've probably heard some of the, like, around like essentially a, what would amount to like a back running hook, this idea that like, if someone makes a trade that moves the price away from the current market price on USWOP, that creates a profitable arbitrage opportunity that someone else can capitalize on. And generally speaking, if you're a liquidity provider on a pool, you want, you don't, everyone wants to like internalize as much of the value, like, as they can. Like if someone else, like if you're creating a valuable opportunity for someone else, you'd rather take it yourself. And so there has been like the idea floating around for a long time of, well, can we create, can we like have a, you know, at the end of every swap unit swap trade, it calls to a smart contract.

That smart contract has the right to back run that trade if it like pays some of the the profits back to the swapper. Now is like an idea we'd been play or liquidity providers either way. And that was like an idea we'd been like playing around within our heads for a long time. And to make that work, you again, you need a guarantee that every swap. Otherwise, like, people can always, like, people won't swap for the router. Like, if there was a router that lets you back, that, like, if liquidity providers, you know, are depending on an external system to do this back running, then people are just going to trade through a different router that doesn't do that because, you know, like, so you sort

of have this, like, this ability to guarantee properties for liquidity providers, for swappers, for whatever, for external projects that you, you sort of have. you don't get with externally built systems. The other thing that I'd say is that like the smart contract design patterns of building some of these things externally are a lot more complex and messy and inefficient than building them internally with hooks. And so I think that that's like another important kind of factor where like definitely like a lot of things that could be built with hooks can be built externally.

But there are fundamental benefits to doing them with hooks in terms of like there are like, it's like, you know, it's built into the pool. you sort of have like, there are like often efficiencies or better smart contract design patterns that you get there. Just to understand, like, who is going to be contributing these hooks? Like, who develops them? How does it get decided? What gets adopted?

It's a little bit like asking who's going to build smart contracts on Ethereum. And it's like, in that like there's probably a lot of people and a lot of different reasons. I'd say that like some examples, like for one, like we've built a few hooks, like even as examples to prove the system that we find. interesting and useful. So, you know, one hook that we built is what we call T-WAM, which is we can get into what that means and what it does. But it essentially, you know, makes it much easier for people to make very large orders on the protocol that execute over a long period of time. And we think that that's like an interesting feature. We don't think that, you know, building it as its own custom AMM would be a lot more work and an infrastructure to maintain. And so we have it, you know,

developed it as a hook. We, you know, we built a limit order hook, which we find interesting. We built, price oracle hooks. So we built a few. So I'm sorry. I need to understand this because so the time-weighted average market maker is for people who it's probably like a whale who wants to make a huge order that would typically move the price a lot that would cost them a lot. So what they want to do is they kind of want to chunk their purchases out or sells or whatever out in a way that it moves the price less, which makes the trade more profitable for them. So one question is like for these hooks, is it that the person who wants to do this time-weighted, you know, average, you know, transaction,

are they saying, okay, for this liquidity pool, as I do my transaction, I'm choosing this hook, or is it that there are certain liquidity pools where they say, we have this hook. So every time you use our pool, it will always time weight average your transaction. I'm not sure. Yeah. Do you see? No, that's a good question. I happy to unpack this a little bit. So the way that I put it is, that first off the, you know, when a pool is, the person who determines the hooks for a pool, like when a pool is deployed, the deployer of that pool gets to choose what hooks are, you know, set for that pool. Like, the pools for a hook are determined at pool creation. And so liquidity

providers choose to deposit liquidity to pools with specific hooks on them because they think that those hooks will, like, be, you know, are where they should provide liquidity for various reasons. T-WAM orders are orders that people would make externally when they, People would submit T-WM orders to pools that support T-WAM, would that have a T-WM hook because they want that feature and functionality. Liquidity providers would provide liquidity to this pool because they actually get fees from T-WM orders that execute through it. Yeah, but then one other questions. So because you said like a liquidity provider can have multiple hooks on their liquidity pool. So is it that I might use the same pool, but I'm not doing a T-WAM transaction, but I'm using a different hook that is also available on that liquidity pool?

So meaning like, because what I, I guess what I'm trying to ask is, is everybody who's making a T-WAM order, like, all doing it on the same pool? Or is it that multiple different types of transactions are all happening on the same liquidity pool, depending on how many different hooks they have? T-wams are like adding new order types to existing liquidity pool. So every single pool is Uniswap V3. Like every single pool has like the built-in logic and functionality of Uniswap V3. I can provide liquidity. Other people can swap through it. You can create hooks that, like, check if you're, if you're providing liquidity in some way and prevent you from doing it.

And so, like, you can add restrictions through hooks. But generally speaking, if you imagine a pool and then someone adds a T-WAM hook and an Oracle hook, like you can still, it's still uniswap fee three. You can still provide liquidity and swap like normal. But you also would have this option of submitting additional, a different transaction type to that same pool, which would be additional, you know, fees earned by liquidity providers on that pool. So, like, someone, like, I could make a regular swap. on this pool. I can also do a T-O-M order on this pool. Liquidity providers provide liquidity to this pool because they earn fees on both swaps and on T-Wam orders. Okay. So basically, hooks are optional for users. Yeah, hooks are optional for users in a sense. You can have hooks that, like, constrain the logic of a pool.

You can have a hook that says you can only provide liquidity to this pool if it's full range of liquidity. And so you can, like, prevent people from, like, you can add hooks that like almost like remove features to some degree. Like, you can have hooks that add additional constraints to a cool, same way you could add a hook that adds a new feature. But generally speaking, a hook that adds a new order type is an optional order type to use. It doesn't necessarily mean you can't use the other order type. And generally speaking, unless you have hooks that explicitly modify the functionality, it still is like the base, the base system is still uniswap V3 and concentrated liquidity. Okay, so in a moment we're going to talk about more examples of hooks,

but first a quick word from the sponsors who make this show possible. We've sat at once and and we'll say it again. The system doesn't just need an update. It needs a complete rewrite. Web3 offers that complete rewrite because it extends beyond just money. Staking, NFTs, Defi, Earn, Web3 has become a world of its own. But who has time to juggle between five different crypto apps? OKX Wallet is one of the best apps for everything Web3. It allows you to store, trade, earn, and manage your crypto and your NFTs across 60 plus blockchains, all in one place. And now it's one of the only self-custody wallets that doesn't require a C phrase. There's just no other wallet that says powerful yet so simple.

Give it a try at okayX.com slash web three. Join over 10,000 attendees for this year's biggest crypto event at Token 2049 Singapore on September 13th to 14th. Sandeep from Polygon, Eric Wall, Chris Berniske, and over 200 others will hit the stage, joining the industry's most influential for an unforgettable experience ahead of the Formula One Grand Prix. race weekend. Singapore will transform into a crypto hub for a week from September 11th to 17th, with over 300 side events that will make for unparalleled networking opportunities. Builders and investors at the bleeding edge of innovation will drive an agenda that covers the ever-evolving

regulatory landscape, the convergence of crypto and AI, Web3 gaming, NFTs in the Metaverse, defy, scalability, interoperability, and many more. Visit token249.com for 65% of regular tickets with the code Unchained, link in the description. Join over 80 million people using Crypto.com, one of the easiest places to buy, trade, and spend over 250 cryptocurrencies. With the Crypto.com Visa card, you can spend your crypto anywhere and get rewarded at every step. Up to 5% cashback instantly, plus 100% rebates for your Netflix and Spotify subscriptions,

and zero annual fees. New users enjoy zero credit card fees on cryptocurrency, Purchases in their first seven days. Download the crypto.com app and get $25 with the code Laura. Link in the description. The ScoreBet app here with trusted stats in real-time sports news. Yeah, hey, who should I take in the Boston game? Well, statistically speaking.

Nah, no more statistically speaking. I want hot takes. I want knee-jerk reactions. That's not really what I do. Is that because you don't have any knees? Or... The score bet. trusted sports content seamless sports betting download today 19 plus Ontario only if you have questions

or concerns about your gambling or the gambling of someone close to you please go to conicsontario.ca Back to my conversation with Hayden. So we talked about this T-WAM hook which you guys created. Are there any other examples that you feel will be either common and that you're either creating? And we also, I think, meant to address who it is that will be contributing the hooks and how they get adopted. Yeah, I think that's all great topics. I'd say that like one other maybe interesting hook example is just, and again, this is something that like people have tried to do it in other ways, in external ways, but like you can definitely have, you know, at any given moment, a lot of the liquidity pool, like a lot of

the liquidity in a pool is not being used. It's just sitting idly. And so you can imagine, you know, you can imagine hooks. And this is another example of something that is very tough to do externally because people have try to basically keep out of range liquidity in lending pools and then like every as the price starts to approach like so you could imagine an important property of un-swap is that like it is like solvent right like you need a guarantee like that is an important property you need sort of a guarantee that like liquidity that you're expecting to be in the pool will be like available when it's needed

and with externally built systems you kind of rely on people to frequently like update their like if if you have a system where some liquidity is like elsewhere but you need it for a given swap, you need to have like, you need to have people that are like managing systems that are like pulling liquidity and like every like 10 minutes or something. And then like if the price moves too fast, suddenly it's not available. The point being that like with hooks, all liquidity that's not in the current narrow price range can be stored in other contracts doing other things. But then in real time, if a price moves the price outside of, you know, like it to a point where it needs additional liquidity, you could just like pull the liquidity from those other systems in real time. You know,

basically on demand within a swap. So I think that's like an interesting category. People have talked about like, it was very tough to create pools right now for things that look like, you know, like the wrapped, state, ETH, or like very tough to create pools for like fees that, for pools, for anything. Yeah. And so I think for like interesting hook patterns will allow you to have like pools

that are like earning yield in other places, which are kind of interesting. I do think that like experiments with fee designs are one of the most important ones and will probably be one of the most used ones. There are a whole bunch of other ones. I'd say that like things around like internalizing MEP for like leaking less value, just leaking less value out of pools generally and are pretty interesting. But so I'm sure you've heard, you know, the chatter about all this because I think so many people when they heard this, the number one thought was, how do you keep this secure?

And, you know, like when I was writing my other book and I wrote about the Dow Hack, like something that I learned, and I don't know if this is still true, but the Dow hack occurred because of an interaction with an outside contract. And I believe that this is generally kind of a dangerous thing for any smart contract to have like this external contract to interact with it. So how do you prevent people from adding like maliciously designed hooks that are for instance meant to be rug pulls or in general, how does the security of these hooks get vetted? Yeah, I think that it's good to look to Ethereum, again, in part for this answer, and I'll unpack it more. But like, you know, Ethereum isn't good because you can't create unsafe smart contracts. Ethereum is good because

you can create safe smart contracts. And I'd say that, like, it is somewhat similar with hooks. Like the same way that like today, people can create tokens that are unsafe, people create tokens that are safe. And like, the same way that even like these problems right now, like, like, you know, we talked a little bit about like things can be that are, can be done internally, can also be done externally. Like, that's also the case for like things that like unsafe hooks can also be managed by creating unsafe tokens. And people create, you know, and so I think that, like, what's really important here

is actually that hooks make it easier to experiment in AMMs in safe ways. And definitely, like, how front ends interact with pools are a little bit different, right? Like maybe, and how users interact with pools, right, might be a little bit different. But generally speaking, the core thing here is that, like, the good thing about hooks,

you can create a safe hook and you can verify a hook is safe. And it is easier to create a safe hook than it is to create an entire from scratch safe AMM. And so I'd say that like how we handle what hooks appear to users in our interface, right, might be, you know, might be different even from what other people do with other interfaces, but I'd say that like I would not, you know, in our own products, right, we wouldn't want to expose, you know, random LPs to pools that have hooks that we don't know what they are and what they do. So then are, is there some process for add.

hooks that goes through like some kind of central gatekeeper to make sure it's all safe? So it's kind of like thing is there a process for deploying smart contracts. Not really, but there is a process for choosing what smart contracts we, like the same way that like aggregators, right, have, they're trying to create as many, aggregate as many liquidity sources as they can, but they're only going to aggregate a liquidity source that they deem is safe for their users. And so there's no like anyone can create a hook to do anything. Some hooks might not need a front end. Some hooks might like be involved in the niche operations of, some specific protocol, we don't need to verify it because it's not meant for our users.

It's meant for a different project and their own users. But for us, you know, we're going to, you know, for our liquidity provision interface, we're going to like, you know, as, as hooks are developed and as, as, you know, people create liquidity and pour them into hooks, we're going to, you know, as hooks are kind of, we're going to, like, audit and verify and whatever, like, hooks meet our security bar and have some level of usage, we're going to, like, you know, try to expose those to our users. But the cool thing is that, like, I know,

So anyone, it's completely permissionless to create a hook. But it's not advisable to tell your users to go into an unaudited hook. In fact, it's extremely inadvisable. You probably should never, if you're operating a front end, or if you're building a front end, you should definitely not just expose every possible pool with every possible hook without any, you know, consideration. Okay, so essentially every front end is deciding which hooks get exposed to their users.

Is that what you're saying? Yeah, for pools that even need front end. And some pools don't maybe don't even need front ends. But yeah, generally speaking, you know, it's kind of up to front ends to decide the same way that it is up to front ends to, you know, decide what liquidity sources they integrate or what other protocols they integrate. It's, you know, it's going from a Dex to a Decentralized Exchange protocol to like a just like almost like a decentralized exchange platform. And so not every possible implementation will be safe. But I'd say that like maybe again can reference that that one, like something that came up on the, again, I watched like a two minute clip. but I thought there were very interesting topics,

but one of the things that came up was like around like this idea of there maybe there being like two types of like there's like kind of default configurations and then like scary everything else. I say that it's going to be a little bit more complicated than a little bit more like of a spectrum than that. I say that like there's probably a default configuration that like looks almost identical to uniswap v3, right? Like you can do uniswap v3.

Maybe the most popular configuration actually might be uniswap v3, but removes the Oracle. which saves gas. Because one opinionated choice we made in Unisov v3 and V2 was adding this Oracle. And the Oracle adds a gas cost for every swapper to create this public good of a price oracle that can be used in external systems. But some people might not want to pay that cost. And so maybe the most used hook will actually be zero hooks.

And that alone will be better than V3 because it's like cheaper for certain people. But, you know, I think that there are also going to be like a wide spectrum of like, I think that there's going to be a lot of development, a lot of innovation across the ecosystem. And over time, hooks will be developed that modify the pools in ways of benefit people. And they'll be tested and they'll be audited. And they'll be like, you know, and as more and more created, they'll, you know, like, they'll start to, like, more of them will start to be exposed to people. So it's not going to be like two worlds of like, like, no hooks default configuration and like any hook, oh, super scary.

There's going to be like a whole middle ground of like hooks that have started to like gain some, you know, have been battle tested, hooks that have been like, you know, like, it might be that, like, there's 10 hooks that are used, like, there might be a power law distribution. Maybe a few hooks will be, like, massive unlocks for the ecosystem, and a lot of pools will use them. And, you know, and then there will be a long tail of hooks that, like, are used only in a few pools or in niche situations or for unique specific user projects and front ends. It's kind of like tokens, right?

Like, tokens kind of have a power law of usage. There's like, but there's a massive long tail. And it's not really like, oh, there's three good tokens. and everything else is like danger territory, don't touch it. It's like, there's like a, you know, there's a spectrum. And we, you know, it's up to front ends and users to like, you know, think about how they interface with things. So one question, because these hooks can be used across multiple liquidity pools,

and we've seen in the history of crypto that there are many times when things that are audited end up having vulnerabilities in them. And so what if, you know, I don't know, like 20% of, of all the liquidity pools have this one hook in it that ultimately, you know, you guys realize that there's some kind of bug. As far as I understand, like, once you deploy, it's out there. And I think it's the same for the hooks. So then what happens?

Do you like quickly whip up another version of uniswap that like doesn't allow this hook and then try to get people to migrate? Or like, I don't even know how that affects things. Do those liquidity pools just decide we're going to abandon and deploy new ones? Or I don't know what you do in a situation like that. What are your thoughts? You always can start with like the base case, right? Like the security of like a Uniswap, like it's kind of like what happens if there's a bug in Unswap V3.

Like all it's like right now all V3 pools like use exact same logic. And it's been very well battle tested. People now feel pretty secure in it. Like I can tell you while we tested it like harder than anything we've ever tested before, like at the launch time, it was still scary as the developer because. Yeah, but wasn't there a bug like announced the other day? I meant to look this up. In V3? Yeah, in V3.

I don't know. I mean, I know the thing has processed like one and a half trillion in volume. I don't think that there are any major bugs that can cause any major. Maybe not. Somebody said this, but yeah, now I don't really see. Maybe it's referring to a bug in V4, which is reasonable. There was a bug, yeah, user bug report. You know, part of the build in public, someone had found a bug in V4. I will mention that V4 hasn't even been code frozen, let alone audited. And so the bugs are expected at the stage, right? Part of the idea of opening it up this early. I'm sure we would have eventually caught that fog and it would have made it through auditing,

but it's actually much better and faster to have people out in the wild discover them and report them and fix them. So that's kind of relating to the building and public thing. I'd say that generally speaking, the kind of idea of a hook that is unsafe is very similar to like an AMM and that is unsafe, right? People can build, you know, if people wanted to experiment with new functionality in AMMs today, they would build a new AMM from scratch. The surface area for doing that experimentation is much scarier. In that world, you don't just have to audit the entire, you don't just have to audit a hook and eliminate the entire system. So if you want to create some new AMM functionality, right, if you want the base case of Uniswap

with no new functionality, then you can use no hooks. If you want to add functionality, the surface area of what you can build with a hook is much more constrained and it's much less likely to have a bug and it's much less likely to, you know, to have a security vulnerability. And definitely there's like, it's not impossible for a, a hook to be unsafe, but it's easier for a hook to be safe. Like what what hooks are replacing is like custom logic in AMMs or externally built things. And those things are just as likely to have vulnerabilities, if not significantly more likely. The things that hooks replace are either like

things that are built externally to pools that try to like add on additional logic to it or things or entire new AMMs. And both of those are much riskier than building a hook. So to me it feels like a significant security upgrade for for people that want new logic. I totally get that. But. But, can you just play out my scenario? Like, if that did happen, what would you do? If there was an unsafe hook. But if it was one that was popular, like, you know, affected a huge percentage of the pools. I mean, I think like an unsafe hook is the same as like an unsafe AMM implementation for the pools that use that hook. So, like, definitely like, you wouldn't need to migrate liquidity to a new version of the protocol. You would need to, like, withdraw liquidity from those hooks. And if you

wanted the same functionality, deploy a new hook that fixes the bug. Like, you could migrate to a new pool, like you don't need to exit V4. You just need to exit the pools within V4 that have those hooks in that world. And also cut off any, any way in which other pools might interact with those. Yeah, I think that like generally speaking, like there's like today, right, in Univov, there's like external, like the accounting logic is partially just using like separate smart contracts. And so each car contract is keeping track of its own balances and they don't interact with each other. There's definitely like in V4 there are like all liquidity pools exists in a single contract. And so I think that that aspect does, I think, for some people,

you know, evoke like, oh, is there like some sort of like contagion type of possibility across pools? But I'd say that like, I don't know, maybe that wasn't what you were getting at, but like, I'd say that like that probability, I'd say it's still like, if there's a bug in uniswap v3, it affects all pools. And so like you still have the same like, a bug will affect everything. And so in before a bug would mean that like our counting logic is broken. that prevents pools from, like, you know, certain interactions. Like, it's sort of like, it's like a similar class to, like, a, you know, the ability for pool stock contagion between them would be a similar class of bug to like B3 having

a bug that like, you know, it's like fundamentally broken. Generally speaking, like, first, like there have been other projects that have done Singleton style designs, right? Balance of V2 has been out for many years. Before we, before you go into that, make sure describe Singleton. Like, yeah, and I totally forgot because, yes, the NU2P3, you had a new contract for every pool. It was expensive.

Now you're going this Singleton contract route. So describe what a Singleton in? Yeah, Singleton is just that all pools live within a single smart contract. And that makes it much today when you do a trade that routes across many pools and has many interactions, the sort of need for pools to communicate with each other, tokens to be transferred between pools directly. That adds a lot of gas cost. And the cost of deploying a pool involves creating an entirely new smart contract. With Singleton, the cost of deploying a new pool is just like updating a little number within a smart contract.

And so the gas cost of deploying pools goes down 99%, which is pretty nice, approximately. Code is in frozen, so you can't really promise gas benchmarks. And then the cost of trades that route across many pools, all internal transfers between pools, you don't have to really pay nearly as much gas cost for them because it's like updating internal balances instead of transferring them between smart contracts. And so ultimately the purpose of this is to create much greater gas efficiency when routing between multiple pools and to significantly lower the gas cost of deploying pools as well. Okay. So, yeah, because you're right. When I framed my question to you about if there's a malicious

hook, I was thinking about the different pools as being different smart contracts, but you're right. Thank you for reminding me. So then that makes it feel even more alarming to me. But why are you seemingly not very alarmed? Yeah, I mean, I think that this is one of the reasons why we really benefit from being in this ecosystem where a lot of development is happening. And like, we've got, we've, you know, even like seeing that like, Bouncer did it and like it has worked for a long time for them has given additional confidence. But I say that like generally speaking, like, you know, these, these smart contracts, like they're, they're, they need to be very well tested and they need to be, you know,

very well audited. And we've seen, you know, other projects have done similar designs. I mean, like, generally speaking, we need to like, yeah, like you need to like test it like a spaceship, right? It's not, but at the same time, like that was already the case. Like you could have separate pools and you'd still need to, like, if, like, V3 was like also terrifying in its own way because there's like a complex smart contract go to base. And the probability if they're being like, you know, a bug in Singleton is not significantly higher than the probability. They're having been a bug in V3.

And I'd say that the kind of process, one of the, one of the reasons I'm really excited about this like slower build and public rollout process is it gives a lot more time for a lot more eyes on the code before it goes out. So it's like an additional layer of security from that. And go into detail on that. So like, you know, you just made an announcement about V4, but you didn't actually deploy it, which is what you did previously when you had a new version. So you've now publicized a code. So what are the steps before you actually deploy? Yeah. I mean, I'd say the steps right now, there's no specific timeline. The steps right now is like, we put it, you know, we put out a version for what we think UNiswifold V4 should be.

if we were to follow a V3 style path and we hadn't put it out, like what we'd do from now is we'd probably spend like several months cleaning up the code base and improving it and optimizing it. What's happening now is that it's public. There's like a time for people to read and digest the codebase would be integrators, would be hook builders, people who have like experience with AMM design, people have an opportunity to look at the code base,

think about our vision for it, give, you know, we have contribution guidelines in the GitHub repo. people can open issues and with things that they think are good about, you know, need to should be changed or are bad about it. They can, if there are open issues that, that,

you know, they can create, they can write the code themselves and create full requests and, and propose modifications to the code base. They can, you know, look for bugs. They can fix documentation.

All of this has already started to happen. People have already started, you know, finding bugs, finding optimizations, opening, opening issues. And it's like massively accelerated how fast certain things have been like,

like, we would have eventually probably, but it would have been like a much longer process. And I'd say there are a few things that might factor into when this thing actually launches. I'd say that one thing that probably factors in is like definitely you need like several months of it being public. I'd think to like really adequately have time for people to give their input, discover optimizations, discover bugs. Obviously there'll be a, so that's part of it. There is a kind of interesting aspect where this singleton system we created is combined with this other thing that I don't need to really get into called Flash Accounting, which is really just how we do the logic for the accounting logic

in a way that like is more optimal for routing across many pools. And the, and that the, the optimal form of this like this, the way that we handle Singleton in the accounting logic of creating all, keeping all pool solvent and efficiently routing across them is made significantly more optimal by an upcoming Ethereum upgrade, EIP 1153. And it was, you know, It's slated for inclusion for the Cancun Hard Fork. It's a very like, it's not only useful for us. It's useful for many other projects in the space. It's a very cool upgrade that just makes it cheaper to, you know, to temporarily store things within smart contracts.

It's a transient storage. It's just about, it's like a temporary form of storage, meaning that it's like similar to like a flash loan where you can borrow something as long as you pay it back of the end of the transaction. Transient storage is just you can use storage as long as you delete it by the end of the transaction. In the world where you do that, the cost to Ethereum for temporary storage is much lower. The cost on an Ethereum node for temporary storage is much lower than the cost for permanent storage. Kind of intuitively maybe makes sense. And because, you know, it's one thing that the nodes all have to update and store something new forever. And the other one, you know, nodes don't need to actually update it.

They just need to like verify the logic. And so that upgrade makes NOSOPP4 significantly more efficient. And in my opinion, it probably should not be deployed until, after, until after transient storage goes live on Ethereum. And then there are some modifications that would need to happen to the smart contract at that point to integrate with transient storage. So if you were to like give a ballpark estimate of when you might actually deploy, what would you say now?

I say that like essentially what you need is you need to, you know, there's several months of community input and feedback. Then there's probably like as a code starts to ossify, hopefully, you know, it's probably like in the world where the community kind of goes with like post, post transatlantic Transient Storage, which I think is very likely because it's just much more optimal. Probably it would be like a few months after Cancun Hard Fork at the earliest because you kind of need time to integrate with with Trantian Storage and then after that freeze the code and then go through an auditing process. And so you don't really want to audit the code too much until the code is

frozen. You don't really want to freeze the code until you've made any modifications. If the transient storage, you know, so I'd say that like if the, you know, Cancun Hard Fork happened in September, and I don't know if it will, but it might, then maybe it could go live in like November, December, something like that. That could be a timeline. But I don't know. It's not really fully up to me. It's like there's going to be like a social, you know, there's been a lot of conversation on social consensus. I think there'll be a little bit of like social kind of convergence on, on what makes sense to do here. All right. So I'm sure you've also seen in addition to the chatter about potential security issues,

with Uniswap v4 that people also are talking about the new business license, which this appears to have happened after the sushi swap incident when famously a copy the code and did a fork and did this vampire attack on Uniswap, as we discussed. And I wondered, you know, after that, you went to this two-year license where people could not use the code for two years. They could see it, but not use it. And with this version, you've extended that to four years. Why did you decide to go with a business license of that length? Yeah, I think it's a great question. And I think that there's also been like kind of general chatter around like, what is open source? What is source available? And I think that like there's definitely like definition. And I think that like,

definitely be, BUSL is like, you know, different from GPL and MIT. And I think that like people say that's source available not open source is like fairly fair and like you know i don't think that there was any like intention to like muddy the language there on our part okay yeah people yeah took issue with the tweet that says we've open sourced v4 i think that like source open sourced is like a verb source available isn't but but we've made source about again it's fair i think it's fair there wasn't like an intention in that i i do think that busel for what it's worth is a little bit categorically different from other, you know, types of proprietary licenses in a pretty meaningful way. And I think there's a reason that it has had significant, definitely like we were one of the first

projects to use it, but many other projects use it now today. And I do think it's like categorically different than, then, you know, a fully proprietary license. And what I mean by that is, you know, the way BUSL works is that after some amount of years, it sort of is like forced to go GPL. It's guaranteed to be GPL. And it can only be accelerated. It can't be extended.

And that GPL is when projects can use your code? GPL is copy left, which GPL means that, like, yes, anyone can fork it, but they also have to go open source. It's sort of a, there's like two types of open source. It's like, you know, like, like, GPL is kind of like the viral form of open source where like anyone can integrate it, but they also have to become open source. Is that also the term copy left, GPL and copy left is, okay. And then MIT, like anyone can use in any way and they don't need to open source. So for an MIT code base, someone can integrate it into their project and have that project be closed source. And so it's not like viral in the same way.

I'd say that what's interesting about BUSL is that it's like guaranteed to eventually be open source. Right. So after four years or at four years or earlier, V4 will be GPL. So there's like sort of like a there's like a time window for which it is proprietary and it's like fixed at start and it can only be accelerated. So both Unoswap labs and Uniswop governance can independently, you know, grant like additional licenses or, and governance can actually shorten the, the period of time for which it is, for which it is open source. Or until it goes, until it shortens the BSL time and makes it full GPL. I will say that like a lot of the like early, I think open source, first off, we're like massive open source fans here. Like almost everything we do, our wallet fully open source.

which is more than more than most wallets for what it's worth. Our web app fully open source. Uniswap v3, which was BFL two years ago, is now GPL and a fully open source. Unswap v2. The things that we've built have been forked thousands of times. We've benefited from those forks. We've benefited for the innovation that's happened on those forks.

I think we're really big fans of it. I do think that some of the early open source kind of philosophy didn't necessarily factor in this world of crypto where you have like, like within days economically incentivized, you know, thousands of economically incentivized forks. There was a period of time where there was probably like 20 Uniswf v2 forks per day. And they were all creating incentives and there were all somewhat low quality as well. And so I think that the idea of like BSL is a little bit like one, I think that like first off,

it's in part an acknowledgement that maybe it's not just labs that should make this decision. So uni holders actually do have, there's an ENS subdomain that is like uniswop dash license. Uniswap.e that governance controls directly. And if they want to like modify, like if they want to make it GPL, there could be a vote today. So part of it is like going beyond labs, other, other stakeholders can have a say in this decision, which is interesting and kind of an innovation in licensing on its own, right? And I'm sorry, you said the token holders can do that? Yeah, there's a, the Uniswap governance directly controls an ENS name, unswap.eath. And there are subdomains to that ENS name that can be updated by governance votes. And the official license of Unifovv4, if you read the text,

says, you know, the change date, which change date is when it goes from BSL to GPL, is, you know, four years from now or sooner at any date specified by the text in this ENS file. And so governance can actually directly vote to shorten that if it wants to. So part of it is like maybe this isn't even just our code base. Maybe this is like a community's code base. And they can decide if they, if they wanted to be forcable sooner. But how did you come up with four years after you already did the two years? Because the two years was kind of controversial. But now you've doubled it. So why? Yeah. Yeah. I think that like, I think that, you know, the two years, look, partially, I think that the two years, like, there were probably like voices. Like, I think that like, first off, the license kind of,

like, worked pretty well at a sense where, like, it prevents. did a bunch, like a lot of local all day folks from happening super early on. I am interested to see how people build on top of V3 at this point. But at the same time, I think that like, I don't know, I kind of think that that decision should also be up to like the broader community and ecosystem. And I think that like there were definitely, you know, concerned with the community around like maybe this should have gone on for a little bit longer. And I think one thing that is really interesting is that we actually, one of the reasons we chose two years is that we thought Anyone can rebuild this in two years. Turns out no one could. And so I think that three years is

interesting as well, or four years is interesting as well. I think it's partially just like a decision you can't reverse. So I say that like you can always, we can always, you know, it can always be shortened through a governance route from four to three to two to one. But you can never extend it. And so the thought was that like it was kind of successful for the youth swap community, the BSL license. And I think it's a big reason why a lot of other projects have adopted it. Did that issue with the wormhole thing on deploying to B&B, I don't remember what the whole thing was. It was like, you guys wanted to deploy there. And then there was this issue about the bridge and blah, blah, blah.

And then it was like getting close to the deadline of the two years. And then you were worried that somebody else would deploy uniswap on B&B. Did all that play a role in trying to extend it beyond two years? No, I actually barely follow. I thought I barely actually followed that that one. Funny of it. I'd say that like there definitely were, I'm trying to. remember the situation. I think that like definitely there were like governance votes on the BNB

chain deploy in part because the license was going to expire and there was some desire within the community. I say just maybe when you say you, I'd say that it wasn't, I actually wasn't like, you know, but, um, but yeah, there were like proposals, um, governance proposals that were voted on and there, there was like a timing consideration mentioned in those proposals. Um, but no, I don't think that that was like the, the, you know, sole influence. I think it's more just about like, maybe just in everything in V4 design, we like kind of favored some level of like flexibility and optionality. And like the sort of period of BOSL is like irreversibly in one direction and not irreversible

in the other direction. And so, you know, if the community really like does not, and again, there's sort of like different communities, right? But like if the Unstop community doesn't like the four year license, there can be a vote to shorten it. It can never be a vote to extend it. So that's like the kind of the core. Yeah, but mostly for PR reasons.

It's not like they literally. couldn't extend it. It's just that. No, no, they legally can, there's no. Oh, really? Like, the license is no reverse. Like, it legally cannot be reversed. Uh, in four years. No matter what the vote, no matter what the community votes on, it can never, it is guaranteed to be GPL. And that's what I say, when it's like, when I say BUSL is like categorically different than GPL. Okay.

Is that it's like, or sorry, nothing GPL, obviously it is. But then, then like, a different proprietary license because it's like forced to go GPL after, you know. And so there's nothing I can do or anyone can do to make this code proprietary beyond four years from now. Okay. I see. So I also want to address another thing that people have been discussing. There was some chatter that Uniswap kind of borrowed some features from Crocswap. Initially, people were using stronger words like plagiarized, but once I dug into the details, it's more like maybe it was inspired by, perhaps the more exact phrasing. But I just wanted to give you an opportunity to address any of those criticisms or just clear up what happened. Yeah, I'd say that,

like, generally speaking, definitely there was no plagiarism. In fact, a different protocol recently accused us of plagiarism. And then because they thought that the code was written, because they looked at like a commit that showed it 11 days ago, but if you actually look at the real commit history that extends from before it was open sourced, our implementation happened a year before their implementation. This was not Crock swap thing, but there was another thread that came out. But definitely no plagiarism. I'd say that like generally speaking, like there's this funny conversation that happens, which is like, who invented Uniswap? That's a really good question, right? Because some people say I invented Uniswap. Some people say Bankor. The Bankor team says the Bankor team

invented Uniswap. Some people say, you know, some people say that Alan Liu from NOSP, he wrote a blog post that inspired some of Uniswap work. And some people, say Alan Liu invented uniswop. Another, you know, interesting question that people say invented uniswap. This would be like, I believe Tarun, Tarun answer would be like this math economics professor in the 1970s invented Uniswap. And like the reality is that like, you know, everything is built on top of everything. And everything is like, and also, and it's like two different ways.

Sometimes you like, you look to inspiration. And like I say that like even like seeing how like balancer handled Balancer v2 in the singleton, like did like make us. feel a little bit better about Singleton as a design pattern. And it wasn't the way we implemented is actually very different from the way they implement it for what it's worth. Like we have a pretty different approach to it. I like I, there's a lot of protocols out there.

There's been many protocols. I've heard of Crock swap, but there have been many protocols that have claimed, you know, Swap plagiarism that I haven't even heard of before until I've seen the tweets claiming plagiarism. So I say that like generally speaking like good ideas like like like of all like some things are like kind of like convergent. Like if something is a good pattern, like multiple people sometimes converge on it as an idea at the same time. Additionally, like sometimes like, you know, sometimes you do hear things and they make their way into the common sphere and you think about

them and you, they influence what you're doing. I think good protocols do take the best patterns that they see around them for sure. It's not plagiarism to like, you know, learn from, learn from the industry you're operating in. You know, plagiarism is directly copy, you know, directly copying code in like drag like so i'd say that like generally speaking we exist in this world there's a lot of innovation that's happening around uniswap there's a lot of interesting design patterns we're learning from them we're also having our own ideas and we're like converging on what we think is the optimal aimm design and i don't know like the specific features i i don't even know if croxwap is open source yeah i don't know the specific features of that protocol um yeah yeah it was something

like whatever, they used some technique for one problem, and then you guys had borrowed the technique to a different problem. It wasn't like apples to apples or anything like that. And I think that two people are friendly. But, you know, again, it's like, I think they had one of those licenses, whatever it was that, yeah, the copy left one, where if you use it, then you should be also copy left. Again, they didn't, you guys didn't copy it exactly. so that doesn't apply really. But anyway, I just saw so many people talking about it. I figured we should just address it.

Yeah. There was another one where there was like that came up like also the fact. Again, a lot of people want to be like, oh, yeah, we didn't. But there was like one that came up where like there was like an MIT version and a GPL version of a library. And like we linked to the GPL version even though there was an MIT version. And the MIT version we could have. And so we like, you know, accidentally linked to the wrong version. But like, so there's like, there's things like.

that come up, we like always appreciate like, you know, these types of things. But at the same time, like, you know, we've also like some of the, like, we've been like, like, V4 is built on ideas that we've been like trying to build for like five years. Right. It's like, it's not, it's not. And we've tried to learn from the best of our contract patterns in, in the industry. But there's no, no specific accusation I've seen felt feels like it's had any real weight. Yeah. So Sam Comesean of Frax tweeted, underappreciated benefit of all pull tokens living in a single contract in UniV4. Every stable coin's blacklist function is effectively dead. And I saw that in the replies, Columbia Business School Professor Austin Campbell said

that this poses the risk that the U.S. could put a freeze order on uniswap v4 or blacklisted. I don't know. Have you looked into that risk and is this something you're trying to mitigate for? I don't think that, I think that like things like this. Like people, USDC is a token that has a blacklist function. Like, they could already be like, you know, they could already like blacklist any unit spot pool. This idea is definitely that like, oh, maybe you like the, you, to blacklist one, you have to blacklist all of them. But I think that like, the way that USDC blacklist has been used historically has been always to like, you know, targeted at individuals, not at like entire, you know, protocols, right? Like technically could like, you know, it could like also like mess with like,

you know, MakerDA or Avey. And, um, I don't think. that this is like, you know, they're like, it's sort of idea of like, I don't know, I don't, to me, it doesn't feel like there's any like categorical difference here from like what's already been out there in the world. Like there is some like, oh, it's like harder to be like more targeted at specific unstop pools or something like that. You could still like freeze like USDC for any, like user who would want to withdraw from their unit swap. Like, and again, it's not, I don't know. I think it's like it's like a funny observation, I guess in a sense, but it's not like a, in my mind, it doesn't really change the like fundamental, you know, dynamics of what, what is possible

and it's impossible with the USC blacklist. I think it's like about the same in, in some, capacity. I don't know. Okay. So now I have a question. And you, I'm sure, are very well aware that U.S. regulators are looking at ways to regulate defy. And one of the suggestions that we saw potentially making its way through Congress last fall was the notion. that the front ends would be regulated. And when I was, you know, learning about kind of these hook contracts and everything, I couldn't help but think,

oh, could a hook be used to implement like K-Y-C-A-M-L? And, you know, maybe that might require us to have like blockchain-based identities. So it could be like super far in the future. But I just thought, oh, is that like something that hooks could be used for? Like, is it possible to create, I mean, it's like trivially possible to create pools For what it's worth, it's already trivially possible to create pools that require KYC. Like you can create a token and the transfer function requires KYC. And then people will only be able to swap with that token if they are KYC'd.

So like that's already a. Yeah, because there's already KYC and D5. Yeah. Okay. Right. And so like, yes, you could instead do it within a pool instead of within a token. I don't think there's like, again, like I don't think there's like a categorical difference in terms of what is possible. I think that maybe like is it more galsified.

maybe it is. I don't know. But it doesn't like that doesn't to me seem like a like a meaningful like like difference in like capabilities in terms of like what you know how regulation plays out. That's obviously very, you know, that's that's like a separate thing. And I think that like there's no like, I don't think that there's like a direct suddenly uniswap v4 like it's like categorically different in how it interfaces with something like that. I'd say that like, you know, yes, it is possible to create hooks that do that. But I don't think that like it's, it's, it's, it's, also possible to create pools. In fact, people have already created pools that do that historically. People have created tokens with white lists that, you know, and created pools on Unswoff with them. And

like those have existed for actually that those, there were ones that existed back in the V1 days that did that. Oh, interesting. There was that project, uh, realty, uh, it was like real estate. They were tokenizing like houses and they created a white list and you could only, you know, we, I don't think we like, anyway, long story, short, there was like, there have been projects. that have been playing with this concept since like the beginning of time or since the beginning, like for a long time. But like I don't think before it's different on on that front. It's like always been possible.

It's never been like hard coded into the protocol as a requirement. I think it's like a DC. It's like, you know, I see Uniswop like I see Ethereum like I see the internet. It's like a decentralized piece of infrastructure that, you know, that you can that can, that can, you can do a lot of things with and you can definitely like it's you can you can you can both break the law on the internet and comply with the law on the internet the internet. The internet is the internet and I'd say that like you know when you're building a product on top of a decentralized protocol like you should definitely like like we obviously always like you know like there are a lot of things that we do in our front end to make

sure that we're compliant with like the laws that that that you know in in the jurisdictions in which we operate like we have lawyers we we you know we do things to protect our users et cetera and so I'd say that maybe the only thing that I'll touch on with, like, laws making the way through is, like, generally speaking, what is a little bit sad and unfortunate is that, like, the U.S.'s approach to regulating crypto has been, you know, has not been very, very thoughtful or very good. And it feels like the U.S. is, like, way behind other countries in terms of how they think about crypto and how they're approaching regulating it. we're starting to see like European countries, you know, France, the UK, like start to like try to understand Defi and like study it and be, be thoughtful around how they interact with it and what to do with it. And then you have the U.S. where it feels like it's mostly like political grandstand. Unfortunately. And are you thinking about moving anywhere at because you live in the U.S.? I mean, I'd say that like generally speaking like I, first of all, I mean, I love living in the U.S.

I don't want to move. I'd say that like, we do always consider like, oh, like, should we ever open up an office somewhere else? But I'd say that like, generally speaking, you know, Uniswap has users all around the world, right? The U.S. isn't the only country that exists as much as sometimes people pretend it is. And so like 70% of our users are outside the U.S. I, you know, I don't know. I like where I live.

Don't intend to. I also, you know, do my best to, you know, I just, I, you know, I don't feel like. like, oh, I'm like in like legal danger living in the U.S. because I, you know, I'm very thoughtful about the legal risks I take on. And people get very mad at me sometimes when, you know, our company makes decisions based on, you know, managing our legal risk. But sometimes you've got to do it. So, um, we've alluded to this throughout. Um, but it does seem that, you know, the way this is going, other projects that might have thought of building their own automated market

makers might instead now just build on uniswap. And, you know, because of all the customization and everything, it sort of feels like it could become kind of like the Amazon of this type of activity, you know, this sort of like everything store for anything swap space. So I was wondering if you thought that would affect the core principle of decentralization that crypto is built on. Look, I think that, you know, I don't really, I don't think so. I think that like, look, anyone can always, you know, compete with it.

Anyone can always, like, you know, build an alternative AMM system. I'd say that like the ability to customize more with it. Like I'd say that like if people are using un-swap because it is better than alternatives, it's not really like it automatically essential. Like the important thing is that like you can compete with it. Like it's definitely, I'd also say that like there's a difference between like the types of powers.

Like it's still like the cool thing about USB4 is it's still an immutable smart contract. Right. Like even though like it might gain like momentum and traction and network effects like that doesn't give me Hayden Adams as like the person who created the company that did a lot of the initial development of it, I still don't have the ability to like steal everyone who uses its funds, right?

Like I still don't have the ability to like prevent someone from like I don't have the ability to prevent someone from using uniswap V4. Like someone can build a project on top of uniswap V4 and I, you know, and yeah, too soon I guess. But other like like the sort of like fundamental like what matters like the fundamental properties, right? like Ethereum gaining market share relative to other L1s doesn't like centralize the industry

necessarily. I'd say that like it's, you know, in some ways like the bigger Ethereum grows, like the more decentralized it is. And so I don't think that like, you know, in a world where like I had a secret backdoor to uniswap, like maybe that would be really bad. I think that like generally, I mean, not maybe. That would obviously be very bad. And that would be a very centralizing force.

But I'd say that like the protocol, you know, in a sort of like decentralized state that it reaches and the sort of way that the smart contracts are immutable and all of that, I think, is like if it continues to gain in market share and growth, it doesn't automatically mean greater centralization because there's no, like, single person who has, you know, inherent control over the system. And so, you know, there are, yeah. Yeah, that's such a good point. I just realized you're right. Like, it just creates like, almost like, God, I'm not a biology person. So hopefully an environmental person listening to this won't get mad at me. But, but like I think of like certain ecosystems or, you know, like you go into like a forest where

there's moss everywhere and you just imagine like there's all kinds of activity happening on that. So it kind of creates like some sort of habitat for like all different types of developers and whatever to build on. So, um, all right. Well, Hayden, this has been such a fascinating discussion. Thank you so much. Where can people learn more about you and your work? Yeah, people can learn about me and my work. I guess I'm often on Twitter. Uniswop on Twitter at Uniswap. Uniswop.org.

You can read about the protocol, contribute to it at, you know, on the Uniswop GitHub. You can download our mobile wallet if you like mobile wallets. You know, Uniswap wallet launched recently. But yeah, learning about our work, just, you know, listen to this podcast. episode you already finished, I guess.

Listen to other podcasts I've done recently. Read our blog. I don't know. All right. It's been a pleasure having you on Unchained. Yeah. It's been scraping here. Probably shouldn't wait five years until the next time.

Yes. We'll have you back sooner. Yeah. It's my fault. Not your affecting. All right. Thanks so much for joining us today. To learn more about Hayden and Uniswap V4, check out the show notes for this episode.

Unchained is produced by me, Laura. with help from Kevin Pukes, Matt Pilchard, Zach Seward, Juan Oranovich, Sam Shregrim, Ginny Hogan, Jeff Benson, Leandro Camino, Kimajumdar, Shashonk, and Margaret Courier. Thanks for listening.