Episode 374 - Lighter, Perp DEXs and Custom ZK Circuits

Transcript

[Music] Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. [Music] This week, Trun and I chat with Vlad and Morat from Lighter, a per deck with verifiable matching and liquidations built as a ZK rollup on Ethereum. Trun suggested this interview in large part because Lighter may be one of the most used ZK roll-up projects out there. And yet, it's a ZK project that most folks

in the ZK community, myself included, haven't really heard of. So, it's great to learn what they've been working on. And a quick note, Terrun is an investor in lighter through robot ventures. It's something we didn't actually mention in the recording, so wanted to share that here. In our conversation with Vlad and Morat, we dive into the world of perplexes, covering how they work, how they emerged, what previous perplexes attempted, where they succeeded and failed, what led to the hyperlquid era, how having a combination of traders and engineers on a perex team has brought some advantages, and how lighter has differentiated itself with the help of ZK. We also explore the details of their system, what led them to choose to build a custom ZK circuit instead of using a

general purpose ZKVM, what ZK actually unlocked for their system, and more. Now, before we kick off, I just want to share two things. First off, we are coming back early next month with a third season of the ZK whiteboard sessions. This video series produced by ZK Hack in collaboration this time with Bane Capital Crypto has hosts Nico and GMO going deep on some of the key concepts in ZK with some fantastic guests. If you haven't seen previous seasons, do check them out. It's a really great way to get onboarded into the key topics we cover on the show.

I'll add a link to the previous seasons in the show notes. Our upcoming season kicks off in September. Be sure to follow us on Twitter, join our Telegram, or follow ZK hack on its respective channels for more info. Secondly, I just want to point you towards the ZK jobs board. There you can find job postings from top teams working in ZK. And if you're a team looking to hire, you can also post your job there today. We've heard great things from teams who have found their perfect hire through this platform, and we hope it can help you as well. Find out more at jobsport.zerowge.fm. You can find a link to this from our website and in the show notes. Now, here is our episode with Vlad and Morat from Lighter.

Today, Tun and I are here with Vlad and Morat from Lighter. Welcome to the show. >> Thanks for having us. Great to be here. >> Hey, Tun. >> Great to be back talking about the dark arts. >> The dark arts of Perp, Texas. All right. So, today we're going to be talking about the lighter project. This is a little different from what we usually cover on the show. Lighter does use ZK, but we're going to be talking about this concept of perplexes. Hopefully, we get to cover a little bit about the history of it. I'm definitely very unfamiliar with this part of the world, this type of product. I I really haven't used it much, and when I have, it's been terrifying and like being on a roller coaster. So, yeah, I I'm excited

to learn a little bit more about what you guys are working on. Um, but before we do, let's hear a little of your backgrounds. What got you started? What were you working on maybe before? Why are you working on something like this? Vlad, let's start with you. >> Sure. Yeah. So, my background is that, you know, I kind of growing up, I did a lot of math, computer science, physics, you know, kind of did the whole Olympiad circuit and all that good stuff. And then I spent the first half of my career in quant finance early Citadel. >> Yeah. Doing, you know, high frequency trading. So that I think kind of there's kind of an interesting segue from that to what we're building now. But our team we're kind of a mix of the way I think about as like quants and cryptographers

right and so building something like lighter is pretty natural fit for us. So we experimented with a few things but lighter is the first project we've we've built. you know, I I think different people on the team have done some, you know, side projects and, you know, we've been following the space for a long time, but yeah, it took us uh a couple months to kind of find our footing in and you know, the space and kind of but but I think a lot of the skill set of kind of theoretical computer science and then understanding, you know, markets was kind of helpful along the way. >> Cool. What about you Morat? What's your background?

>> Hey everyone, I'm I'm Morat. I'm leading the technical efforts on lighter. This includes the cryptography side, the product side, the exchange sites, all those. And yeah, my background is I wouldn't say cryptography, but a lot of experience on algorithms, optimizations, data structures, which is surprisingly it aligns really well with the the things that we are doing today. So >> Oh, nice. Very cool. Okay, so I think we should introduce the audience to lighter. What is lighter? And just remember, a lot of our audience has been focused very much on the ZK side of things. Lighter is a ZK project which for some reason I feel like in our community we haven't heard that much about. So yeah, why don't we talk about what lighter is and what part of the

ecosystem it lives in. Yeah. What's it for? Lighter is a per deck, right? Which means, you know, a decentralized exchange. You know, pers are we can get into more of the details of that, but they're essentially like derivatives contracts. you know, it's kind of the the most actively traded type of contract in crypto, right? So, the you know, the new part about what we're doing though is is that it's on top of Ethereum, but it's also, you know, the goal was to build something that's very scalable, you know, cheap, fast, and while kind of maintaining the security and verifiability aspects of being on top of Ethereum. And that's, you know, I guess we can talk about how we did that and that that's kind of where where ZK Snarks really make it work. But it but

you know from like a if you're using lighter you know it's a way that you can trade you know lots of different types of derivatives and do that in a way that's cheap fast secure verifiable and you know that was kind of always our our mission from when we started. >> Can we do a little back story on just perplexes and actually even maybe perp exchanges like in our space >> maybe define perp it's already a shortening of a longer word because I think that's like >> is it perpetuals or something >> right? And it's I guess it's like become like industry jargon, but yeah, it's like perpetual future is what it is. And like the goal of of like why are those interesting in the first place is because of leverage. So you know, you can trade all the same stuff just like

you can trade the tokens themselves, right? Like you can trade BTC, you know, ETH and so on. Then you're not really using leverage. Now you can do, you know, you can like borrow from something like a and trade the spot, you know, you can do that, but but a perpetual is just a much easier way to get leverage. So let's say if the price of you know Bitcoin moves up 2% let's say you want to make more than 2% if that happens right like you know maybe if you take on 10x leverage you make 20% of if you get that price prediction correct so that's kind of why these kinds of derivatives are interesting in the first place and you know in stratfi like I think most people who want that kind of exposure like use options more but in in crypto like you know options were kind of more

difficult to do in the early days so I think perpetual futures is what the industry arrived at as something where you know you can get leverage because in trfy like futures also exist and it's a huge market but they're like a future as a you know there's like a future for 3 months out then another 3 months out so you kind >> fixed time. Exactly. And actually like there's stories where for like oil futures if you forget to exercise that future you actually like there are hedge funds that actually got like barrels of oil you know delivered to them and stuff. So, so like to avoid all of that. I think the concept of a perpetual future was, you know, thought of and it's actually something that would make a lot of sense even in trfy slow to adopt new concepts.

>> It still hasn't happened whereas like the crypto space adopted it pretty early on. I think probably Trun you might know the history of this more but like probably around 2016 2017 or maybe even before that I think there's like yeah >> some of the centralized exchanges for these right but even before the ones we know now like Binance there are some like earlier ones that did it and it basically is this way where the the perpetual part of it means that you don't have to worry about is this a June future or an August future it just kind of like automatically rolls over every hour. Hm. It's almost like until you reach what you say you want it to reach, it would just continue.

>> Yeah. Essentially like, you know, going long means that you're betting on the underlying asset to appreciate and going short means you're betting on it to fall and then while while you have that position, you know, it it kind of every hour it rolls over like cuz there needs to be something that ties the future to the underlying asset, right? Because otherwise the future if it was just like a market that had no connection to the underlying only name only then like who's to say that you know maybe the Bitcoin future could go up to you know a million like who's to say that it couldn't do that you know but because every hour there's this like funding mechanism. So what happens is that like a per exchange sees a co where's the underlying trading and if you know based on whether you're above or below that

like essentially there's this like rebalancing that happens >> to make sure that the price is actually kind of tethered to like the price of that underlying that part happens generally once an hour you could design a structure where that's different frequency but that's become kind of the industry standard and that kind of happens perpetually right until you get out of the contract. Okay, I have a few questions on that. Just like from a user's perspective, you put up almost like your bet on whether it's going to go up or down in the future >> and the amount that you're willing to trade. Say it goes against what you thought in the first hour.

>> Do you see a reduction in the value of your trade or like the value of your asset that you're trading with? The reason I'm asking on that level is cuz like perks have always been described also as kind of like dangerous or like that you know people who don't know what they're doing could like really hurt themselves and I want to understand why. >> Yeah. I guess few things to say here. I think for perpetuals risk actually comes from the leverage not the way like if you are actually 1x leverage but like short or long a perpetual contract it doesn't necessarily like a very risky thing to do. But if you are doing like 50x leverage, what I mean by that is like you put $1 capital, but you the the your profit and loss behaves as if you

deposited or you put like $50 of capital. >> So when you get in a position like that, when the price moves very little, you get 50x exposure to that. So that's where uh the risk part of it comes in. >> If it goes in the direction you want, you'll get the good exposure. >> Yeah. If it goes to the other direction, you you'll you'll basically lose 50x as well. So it's like symmetric in that sense. The part that is not symmetric is again there's this liquidation thing, right? So the way you need something like that is you don't want people to have negative balances, right? Because then let's say like I'm minus $10, I'm bankrupt basically and somebody has like $110 and that's the only two people in the exchange. What happens when the person with $110 decides to withdraw because you initially started with $100.

So there is it is not solvent basically to ensure that everybody has positive balances at some point you need to say okay this position is out of control exchange needs to say I want to basically get rid of this position that's where the liquidation happens when the exchange decides okay this is too risky to to ensure the solveny always there it gets rid of the the position based by liquidations >> thank you by the way to both of you for this like I'm I'm definitely the the non the non-trader asking the very basic questions. But I mean, I think some of the audience is also not using these per. We've heard about them, but this is really helpful.

>> I I guess like two things I'll add. First, my mom used a per for a first time last week cuz Phantom added pers and she was like, "What is the thing? I'm going to put $10 and do 50x." Obviously, she lost her money, but >> similar story to mine. Yeah. >> But it I think like actually the the UX for per is getting kind of so easy that anyone can use it. But another thing I kind of which Vlad touched on a little bit but I think might be worth emphasizing to understand why these are more complicated and also why you need to get the logic for proving that a liquidation happens correct >> is that in a normal futures contract say you know we write a futures contract that says next month you will give me one barrel of oil and I'll pay you $50

right now in that contract the fee is priced upfront right like I'm giving you $50 now in one month you give me a barrel of oil if you don't I I take you to court or whatever, right? But in perpetual setting, you have this continuous payment, right? So it's like not only are you betting that, you know, say you're betting like Ethereum goes up, but you're also having to pay this financing cost continuously. So like in that sense, you're doing this transformation from a discrete time cost of like I pay a single payment to I'm paying every interval. That means you have a lot more accounting to do and there's more complexity to keeping track of how much you owe versus like how much someone else because it depends on when

you enter and exit the position. So you need to sort of have the entire state. >> The other thing is that the funding is a way of like synchronizing the spot and the future. So if the funding is you know that this price is in one direction it sort of says hey arbitrageer you should try to bring it down by taking the opposite >> side. So I think another important piece and and I think Morat and Vlad can expound on this a bit is you know the synchronization method between the spot and futures price because I think that's a very important basic concept to understand before we talk about the ZK aspects of this >> right I mean I think again it's it's like there needs to be some mechanism that makes sure that because yeah unlike something like oil where you just like wait for settlement months out like you

know obviously none of that can happen you know on the blockchain so you need to like have mechanisms that make sure that those prices are actually tied to each other somehow and yeah I guess mora do you want to explain a bit more how like what happens like what exactly happens every hour yeah so essentially these per contracts are just some balance sheet that is stored in the state so you need to somehow enforce that they represent something right something in the real world which is I guess what we call the underlying asset the mechanism to make sure that the per price is somewhat similar to So like Bitcoin price, Ethereum price, whatever the underlying is, you have this mechanism called the funding mechanism.

And what funding does is you have these oracles that are uh giving you the index price which is the price of the underlying like price of the SERM on spot markets for instance. And the funding mechanisms basically does this thing. If the price of the perpetual asset in the order books or like in in the trades that are happening is like higher or lower than the the the underlying index price then basically we do this payments where longs pay shorts or shorts pay longs to make sure that you incentivize the price to go to the right direction. So it's like an incentive mechanism to make sure the market makers or the participants are moving the price to the right direction because if you try to basically move the price to something that's irrelevant of

the the spot price, you're going to be paying a lot of funding. So it becomes economically unsustainable to price the perpetual futures contract anything but the spot price. >> Okay. So that was actually a question on the the sort of like if you're going away from the individual's perspective and more towards like the market itself like what do perpetual dexes or like these systems what do they add to it? Like are they helping to find a more accurate price overall? Does it like increase efficiency or is it just like a cool way for people to get leverage?

Like this is the thing I've always sort of been curious about with these perplexes. if if it's just like putting sort of trading on steroids for the fun of it or if it's like acting as like a balancing mechanism of some kind. >> Yeah, it's hard to answer that because there are lots of different market participants and so like I think you could say that something like per is like good for price discovery, right? Because the market participants who are really good at price discovery can do so using capital like more efficiently, right? cuz you know without leverage you would have to put up a lot of capital if you're trying to trade spot right and so then you know all these different market makers and you know quant shops and all these guys who are like really good at

figuring out what the fair price >> well maybe the claim I'm trying to make is like the ones who are really good at this stuff if it wasn't capital efficient for them to do it they wouldn't participate like they would rather do it in trii or something right but like you know so that's actually a way you get a lot of really good market participants in the ecosystem. And yeah, I mean there's like a secondary question of like how do you make sure that they're not doing stuff themselves that's unfair or that hurts the ecosystem, but like overall I think you want a lot of like smart people in the in the ecosystem trading this stuff cuz that that makes for the best prices. So like arguably an ecosystem without derivatives would have more volatility than an ecosystem with derivatives >> which is kind of maybe sounds

>> funny >> like it would be the other way around but but the the reality is that you need the more rational participants there are kind of the the healthier the market is and the way to incentivize those rational participants to be there is >> leverage >> leverage because it's capital efficient right like >> interesting >> yeah at a high level I I think we believe that and it's like pretty well established how that works But but you can always find like oh yeah but what about this case where someone manipulated the market and so and we can we can talk about those you know exceptions as well but in general right like you want a lot of rational actors trading these markets that's what makes them liquid and you know make sure the price is fair and so on.

>> Got it. One thing I will add is like the historical element to like why these became popular in crypto versus other markets. And one maybe contraositive to why you would care about capital efficiency is actually inventory management. And so in 2013 to 2015, Bitcoin miners wanted to hedge their, you know, they're paying costs in dollars or remi but they're earning in Bitcoin and they wanted to lock in some sort of like expected price that they're selling at. And at that time it was actually, you know, there was only these kind of like very illquid spot markets.

So you couldn't really like if you happened to win a block, you would actually have too much Bitcoin to sell. >> Wow. >> So like there wasn't enough inventory. Whereas like if you could use derivatives, you could like space your selling more efficiently over time. And so that was like, you know, like the BitMX and Mexi stuff like that was kind of they were initially created where like miners needed to sell and then there were just people who wanted to speculate on the other side of the Bitcoin price >> and it just became much more efficient than the miners trying to just constantly sell spot all the time.

>> Interesting. um it allow them to like spread out their selling cuz like there's this kind of inherent thing about at least in proof of work rewards that's kind of interesting which is your expected reward might be like based on how much hash power you use like might be say one bitcoin per year >> but your realized reward might be I have one bitcoin in May and zero at all other times >> so how do I actually think about splitting my expected payout over the year because I still have to pay electricity over the whole year even if I'm >> and the other thing is in blockchain you have randomness to when you realize something in a in a way that you don't in the oil market, right? Like >> there's a ship coming from the Middle East. I kind of know where it is, right?

Like whereas in the blockchain case, it's like I randomly win the proofof work reward and so I don't know ahead of time, which is why I kind of need this like continuous time thing versus a disc. So that's a historical reason. Obviously, it kind of grew into its own world. But >> yeah, >> I think like inherently blockchain randomness kind of incentivized people to go to this micros market structure. >> Why were like the early founders though like that were building these per things like didn't they kind of get into trouble with regulators? Like wasn't it sort of seen as this like risk project?

>> Well, I think they got in trouble because like the people who are the miners were also like you know North Korea and stuff. So >> okay. Was it really was it because of who they engaged with or was it because of the concept of the I always thought it was sort of like they had introduced these markets that I don't know regulators found or deemed kind of like unfair or somehow dangerous. >> I guess it depends on the the specific case, right? But I think in in general they've just like not been regulated, right? So and I know this is changing like in the last year, right? But like before I think the perspective of the regulators was like well we don't have rules for this stuff. like may maybe it's risky, maybe it isn't, but it was like regulation by enforcement, right?

But but but it wasn't even that, you know, the regulators had a view on like, okay, 50x leverage is bad, but you know, 3x leverage is good. You it was more just like, okay, this stuff is just outside of the scope of what's regulated, so it shouldn't be traded in certain jurisdictions. there might have been like some specific issues where there were like specific bad actors involved and but but I think in in general it was just like you know outside of the scope of what's what's regulated and that's changing now right so that that's I think a really good shift that's happening in the last year >> this actually brings up one kind of good point which will allow us to talk about another aspect of lighter and hyperlquid which is kind of unique and like why this current market cycle has been

different than the last one for perpetuals exchanges. So you know one of yeah obviously if you look at the things who people got in trouble for running perpetual exchange almost all of it's moneyaundering anti-moneyaundering stuff like >> it's related to who was participating >> but there is one accusation amongst many of the early exchanges and even against Binance that kind of is sort of one reason people thought it was unfair which is the exchanges also own the market makers that were market making against the exchanges and they maybe you know like in BitMX's case there were like some examples of people claiming that they got forced liquidated. Like the exchange forced the price down, caused me to get liquidated and then you know like that that was sort of like the

the bid accusations of like 2015 to 2017. >> Yeah. >> And you know we've seen this micro structure play out a bunch of times, right? So it's like in the early days of BitMX and and Mexi and Gate and stuff like the exchanges were the market makers. In the early days of Binance, Binance was the market maker >> and early and FTX we saw this thing where like wink wink nudge nudge the exchange is not the market maker but kind of the market maker. >> But the interesting thing is DeFi in the last since FTX has kind of evolved these market mechanisms for onchain market making that's transparent >> and separated I guess.

>> Well, it it's separated in that like >> it's transparent. >> It's transparent. I I wouldn't say totally. >> So it could still be them. Yeah. Yeah. Yeah. In a lot of cases it is the teams, but you can see exactly what they're doing. So, it's like it's a lot cleaner and you know kind of what's going on. So, >> maybe a good stepping point here is for you guys to talk about HLP LLP and kind of like how that has made onchain per stexes much more efficient slash possible versus the kind of centralized exchanges because I think the big reason we've gone from pure centralized to decentralized is this market making mechanism. M also if you can mention a bit of the so there's these like other perpexs that have come out before the hyperlquid era like dydx like I don't

even know what's the first perex I don't know what it is I don't think >> yeah maybe you can just work that a little into this as well >> right I think you know DYDX they they've also gone through like a few different iterations like the one that we are quite familiar with is is their V3 which actually was the first one that used ZK. They were working with Starkware on that and they were essentially proving that the trades that they claimed that happened like actually happened. >> So they weren't proving that the matching was fair, but but at least like the trades were proved to be the the right trades, right? So >> and this is what allowed it to be decentralized, right? because before

that point you were dealing with these centralized exchanges where you were kind of relying on them I'm guessing >> and all of a sudden you have these the ZK part allows for these systems to be even built am I right? >> Yeah. Well, I guess the question is like which part of the system is decentralized, you know, which part is verifiable, you know, centralized exchange like pure centralized exchange like none of it is >> all black. >> It's all black box, right? So then >> no, you you can go all the way to the other extreme something like like a unis swap right there. It's like everything is completely transparent that there is no blackbox part at all.

>> Like if you're running well depends on the chain, right? like you know just a classic you know like unis swap on ethereum right there like everything is transparent the problem with that and I mean that's not a perfect exchange that's a spot exchange but still like a lot of the the trade-offs exists there too and it's like there it's just not very efficient right you have to like wait 10 seconds for anything to happen you know the costs are are very high and all that so it's like I think the the breakthrough that dydx because I think before it was more like okay well you can like deposit and withdraw like that that part is decentralized, but like the actual trading, everything there is kind of the same as on a centralized exchange, but like at least it's like self-custody, right? So like the

deposits and the withdrawals are decentralized, but like once you've made the deposit and committed to a position like the trading that that's like same as on a centralized exchange and I think DYDXV3 like took the first step away from that, then there's a question, okay, well, how do we decentralize or make verifiable like the part that's really important, which is the matching part? And then that's kind of I think where we got started. But but I guess as far as like what existed before Yeah. like the the DYDX V3 was I think a really strong product for its time. I mean I think it was like the market leader for probably 2 years.

>> Wow. >> Arguably it was just early in some. >> Is this before or after their move to the Cosmos ecosystem? >> Before before I mean the Starkware product was probably better than the Cosmos version. Not not this is my personal opinion. Not because the Cosmos thing had like explicit problems. I guess it did have some like validator collusion things that people found later and they had to do some like weird slashing events, but it's just like the liquidity was kind of a lot worse like like people just weren't bridging stable coins as much. So, it was >> like lost the moment.

>> Yeah. It's kind of like I I think there it had captured attention and liquidity in and then kind of moved and like it took a long time to come back and then by the time it came back competitors came I think is like the real story for them. >> Trunin, you asked a question just before about these like specific things. What were what was that? >> Well, so I think Vlad made a a a good point which is like there's kind of the spectrum between centralization and decentralization, right? And the problem with pure decentralization is you have a lot of adverse selection. Like you, you know, some user is taking a worse hit than others. And so you do need some stuff to be private or at least not totally telling everyone exactly what you're doing. But you also want it to be

verifiable, right? And so I think this trade-off space, you know, people have been exploring this trade-off over the last call it five plus years, six years. And I think Hyperlid kind of first made one version of this trade-off. And the main thing is that they kind the way they bootstrapped the market making was I mean there's a lot of things that went into their success, but one of them is the way they kind of built this verifiable market maker and I think lighter takes a step further because you have a lot of the ZK guarantees and in terms of verifiability. So I don't know maybe you guys want to talk about >> Hyperlid is not ZK.

>> No >> at all. >> No. And this is why bridging spot assets is very weird for it. Like they have to do this kind of multisig thing. >> Oh, I see. So you're just like doing the oldfashioned bridge. >> Yeah. And so like maybe it's a great time to for you guys to talk about a little bit about like what the the benefits of ZK are for for your application and cuz like I think a very interesting aspect of lighter is you go to the website does not say ZK unless you go to the white paper and look at the Merkel root data structure, right? So like it uses it without you even knowing it, right? which I think is like I don't know that's a good success for ZK is that like people people are using it without even knowing it.

>> Yeah. I mean I think part of that right is like I think we kind of use the term verifiable as a way to encapsulate you know the value prop that comes from using ZK you know in a way that traders understand. Yeah. I think that's kind of another question of like how technical you know it's like do the traders really understand how that part works? I mean I would argue that they may not understand how it works but they know that it's like a mechanism that like we're building in public and like if if you know as long as one person knows how it works and finds a mistake then they would publish it. So it's like like the traders understand that these mechanisms are subject to like audits and like public kind of anyone can make sure that what's happening is actually verifiable

or not even if and then that would be out in the open. So, so that's that's I think a part of it. But while we were talking about like this the market making part just to kind of you know make a point on that you know our our team like I mentioned we were kind of like you know mixture of you know like quants and cryptographers and you know I think other like hyperlquid also like their founding team you know they they had a lot of trading experience to I think some of the earlier projects were not like that right like >> they were more like blockchain product people. >> Yeah. And you know, I think it's actually very impressive what they were able to do kind of without the trading experience, but like I think what Terrun said about bootstrapping liquidity and all that, I mean, that's certainly true,

but I think even just at a more basic level, like when you're building the first version of a product, like it's one thing if you're like you build some stuff, you like give it to a third party market maker and say, "Okay, we'll test this out." It's another thing if it's like people on your own team that are like testing everything in real time. It's like, "Okay, like we just improved the circuits this way. let's run the market making like right now and see if it still work you know like it's just very different kind of engineering process if everything is done by the same team and I I think or you know if you're making like APIs that other market makers can use if on day one though it's like people on your own team that are actually testing all this stuff out and so I think that that's part of

it like I think what happened in the past is that to bootstrap liquidity you know DEX projects would like make deals with market makers but even just the the process of building is much different right if you're kind of like throwing software over the wall for others to test, you know. So, I think bootstrapping >> traders, it sounds like it's like the users building the product versus building a product and then finding the users. It's sort of a classic like kind of what you described that like if there's a background in trading, you have all of the intuitions already built in for what you're looking for and what's annoying and what's going to be problematic. So the I can totally picture that the engineering process is going a little faster.

>> Right. Right. And then also kind of the fact that the way the market maker operates is completely transparent and verifiable. And not only that, like in practice once it has been launched like it's like 99% of the value generated there goes right back into the community. So I think people like those things too. It's it's very different from like a centralized exchange running a market maker with their own money, right? and keeping the profits. You know, that's But I think Morat maybe you can you can jump in here a bit and kind of talk more about how we think about verifiability since it's different, right? It's not you don't necessarily need kind of consensus, you know, if you're using ZK circuits. But yeah, maybe it's a good time for you to jump in.

>> Yeah, I guess the initial talking point was layer one building your own blockchain with consensus versus having this rollup that uses ZK. One of our principles were to have something that's verifiable. Verifiability can come from bunch of different places. It can come from like a layer 1 blockchain consensus. It can come from ZK proofs. It can come from optimistic like fraud pros or you can have like a trusted execution environment which can somewhat provide some verifiability >> but all all have their I guess advantages disadvantages like for instance when you have a consensus a blockchain like a full layer one blockchain you can't like transfer information faster than speed of light

right so you'll have network latencies you'll have like if it's like a globally distributed thing like you're not going to have less than 100 millisecond latency right? It's going to be more than that. But in in finance, you you you don't like that's not acceptable in thread five for instance. It needs to be in microsconds, not even milliseconds. So it has that disadvantage. If you want to have something that works longterm and scales as much as the exchanges on thread, like ZK is an option here basically and optimistic roll-ups are also an option. And besides that, optimistic roll-ups you have all these issues like withdrawals, deposits, like withdrawals specifically, like you need to have this grace period, right? So you can't just uh put your money out of the exchange in a secure way. Let's say like

you can have bridges and such, but they're not going to be like the sequencer can always try to do something malicious and it'll be basically like much slower compared to ZKOPS. And the hard part I guess for ZK it is really good but the bad thing about it is it is hard to build right because when you are building a blockchain layer one blockchain you already have a lot of the building blocks uh you just combine them to like get a consensus but here you need to essentially build an exchange and you need to build another exchange that can prove the operation and ZK tech also has been evolving quite a lot and that's why like it wasn't fully feasible before and now it's becoming feasible and we are on production we are

processing like 100 million transactions a day which is quite a lot right now right so >> I I mean also you had $6 billion of volume someday this week right so to me it's actually crazy you're the most so like used ZK project that people who are building ZK stuff don't know about >> yeah this is one of the reasons Tun brought you up to to come on the show too he's like you know that there's this really big ZK project you don't know about let's talk to Um, so actually one interesting thing I think that's sort of a narrative violation that that you guys have really leaned into is, you know, you went with custom circuits and I know your journey involved you testing trying to build this with ZKVMs and trying to do it in

different rollup stacks. Walk us through the journey of how you ended up back at custom circuits and like you know where you started and how you ended up at the architecture you have now. >> Right. I mean, we were pretty open-minded about which architecture to use in the beginning. I mean, we we spent like a couple months, you know, even before like committing to the architecture. I mean, it took a while to build, right? Even before we made the decision like we we tried a bunch of things and talked to a bunch of teams and did some experiments which by the way I think the earlier point about like being able to kind of iterate quickly and test everything out is important but like you know we we we thought okay well who's to say like maybe even just like like optimistic rollups like we know one

thing for sure is that you're using you know Ethereum L1 that's definitely like there's no way you could build an order book exchange there like >> on there. Yeah, that ship has sailed. There was a time but yeah >> yeah we also knew that like in 22 like on let's say on Salana there were actually order book exchanges and they had other problems some of those early projects there had like an FTX connection you know there there's some technical issues there and then some other issues kind of unrelated to that technology even right but like we didn't know like who's to say maybe like something like an optimistic rollup on Ethereum is actually efficient enough to run an order book exchange right so we we experimented with that because because you kind of have to it's not just something where you can do back on

of the envelope math and say, "Okay, it's not going to work." Cuz it's like it depends on the nature of exactly how the market works on on things like how many orders are filled, how many are canceled, like how often do you need to update the orders because you know those L2s, they're like pretty close to being efficient enough, I guess, is my point to to do this. So, it's not like you can just do some quick math and conclude it won't work. So, you actually have to try it and kind of figure it out. But we we did try it and we said okay like most markets where you need fast price discovery and you know be able to update the order book quickly and you know the where the costs aren't crazy like it just the L2s are a lot more efficient than the L1 but still several orders of

magnitude away from what would really work well. So we always knew that ZK is really powerful and like a really big innovation. And we did think, okay, well, like there's a lot you can do with with ZK struct like like building a ZKVM isn't the only thing this tech is good for like circuits, you know, you can do a lot of different things. >> They open up actually new possibilities just the fact that you're using these things. What influenced that though? Like when you were like looking around like what did you see that sort of prompted that understanding or that intuition? >> Right. Well, part of it was that the example of you know dydx v3, right? I mean that was one example. I guess we knew some folks who were part of like Zerox Spark or like kind of in the

ecosystem and you know they weren't all building ZKVMs, right? So it's like cuz I think the the narrative from like I don't know for someone who doesn't really understand it like for like someone I know like like a VC they might just say okay are you using ZK or you're not using ZK and to them ZK just means building a ZK VM and that's that right? >> Uhhuh. >> Well they they they did ruin the notion of ZK meaning zero knowledge versus succinct proof. So >> they us >> hey I'm part of the day. So I'm I'm like including myself in the the the the day there.

>> But but like we we did try if ZKbased L2s were efficient enough to run an order book exchange like we would have done that, right? It's not like we weren't just like trying to like >> use cryptography because it's cool. >> Yeah. Right. I mean that's a nice benefit, you know, cuz it's like it's really it really gets the team pumped to like use interesting stuff. But but no, like if there was an easier solution, we would have done it. And the fact that no one else had done it, I mean, I think every even dydx who were the closest, they actually like moved away >> from the Ethereum world, right? >> And ZK part, the Cosmos thing.

>> Yeah. So I guess that's kind of a narrative value because like no one else was thinking about it this way or maybe they were but didn't execute on it, right? So >> cool. >> Well, I Okay. I I think maybe maybe for the ZK audience the benefits that you get in the exchange performance-wise or oracle wise or withdrawal wise like these tangible benefits can you describe which you know which ones the ZK pieces has been uniquely important to and like which how how that kind of improves the product. >> Yeah I guess few things to add here. Yeah, as we had mentioned like there are bunch of existing optimistic roll-ups, ZK roll-ups, EVMs that you can deploy set of contracts to like the thing here is like as I mentioned like we were processing 100 million like transactions right now. It can actually do like a

billion but maybe we need to do like 10 billion a day right in the future. >> It's a lot of data. You can't you can't just post all those data or like all the state to to Ethereum. There's not enough like blobs data available to there. So you need some type of hybrid structure where things are in the states like orders are in your state tree but you don't actually post the data about those two to your base layer. You can't do that with like offtheshelf like EVMS, right? You need like a lot of custom like it needs to be customizable. You need to like that's that's the reason like why our bit deploying these things to arbitrum or like optimism zk zk sync polygon whatever like it it it just doesn't scale because there's not enough data space on Ethereum for your

>> but you're talking about zkvms there. Yeah. >> Could you use could you have used ZKVMs like the new batch like why did you have to create I think just going back to that question like why did you create that custom circuit? So the thing is yeah like you need to as I mentioned you need to have a custom data availability structure you maybe you don't want to post all of the data right like the point of posting the data here is we want everyone to be able to reconstruct their portfolio account portfolio how many dollars they had what what positions they had all of those should be reconstructible on Ethereum but like for instance you create an order it doesn't change your portfolio right that data does not need to be posted on Ethereum and uh exchanges like the the things that exchanges process is

dominated by like order operations not by trades not by deposits withdrawals is dominated by create this order cancel this order modify this order so you you need to basically like to to get the 100x data improvements you need to have a custom data availability structure where you post some of the state not all of the state >> I can give you an analogy on the like so this is the data availability cost there's also the like proving costs right like using an offtheshelf VM ZKVM versus building your own thing. Like let's say these Snark frameworks are like bunch of Lego blocks and you can like different types, different sizes, different colors, different purposes.

You combine them like if it's a ZKVM, you com combine these to build a car, right? Like but what you can do is like you can get rid of all the pieces you don't need because we are operating operating an exchange. We don't need to have >> a virtual machine that can calculate the NS Fibonacci number or something, right? So basically you get rid of all the unnecessary things uh and you build your own Lego blocks that is like an engine for instance. So so that you can build the car efficiently. You don't need like a huge engine that's you built from Lego blocks for running the car right so it gives you a lot of efficiency on that side. So you don't need a lot of things and you need certain things that are not efficient to do with >> with the current offshelf. Yeah. Yeah.

Exactly. One question related to this is like when I was in trading, I remember you'd all you know you never implement a level in an order book as a a tree. You'd always implement it as like you know skip list or something where like you could take advantage of caching. But an interesting thing in your white paper is you have this very easy to merkealize representation of an order book. You know do you actually use that in practice? cuz like in the white paper I thought that was like an interesting thing where like in normal nonzk land you'd implement something different for performance reasons. But in ZK land it actually makes more sense to represent like this cuz it merkealizes more easily and stuff like that like like I feel like trade-offs like that seem to be more akin to things that would make it

better to be in a circuit. Yeah. What are the types of techniques and data structures and stuff you're using that that are kind of optimized in your circuit? Uh one of the things I mentioned earlier like to build a ZK exchange I mentioned you need to build an exchange and you need to build a prover for that exchange right so like for instance the data structure that is mentioned for order book uh in the white paper is only used in our circuits and when we are generating the input data for circuits sequencer actually uses the most optimal version of that data structure as possible and sequencer works as fast as possible because that type of structure you don't need inclusion proofs to give users It's like soft finality right so you actually can get a like use a different data structure in the circuit side yeah we

have that data structure it is being used right now that data structure I guess white paper also mentions it uh it provides you inclusion proofs but on top of that you can also do a lot of things where like you can ask it to give you the the best order with the best price and you can ask it to give it like give to you like if I were to buy like $100 worth of this contract how many how any contracts I can get it can give you like quotes proofs as well. So those are the things functionality that that's that that you would need from the data structure and we try to design something that is optimal to like just for those things right because you can like you can do stuff like you can implement uh some type of sorted link list using

regular Merkel trees but it's not great the depths of the tree needs to be bigger you need to send like maybe two Merkel proofs instead of one to to verify the inclusion proof. So there are a lot of things that are less efficient. So we need we try to like custom like build something super customized and that is just good for what we wanted to do not for other things. >> One reason I I bring up the the data structure thing is like this is kind of something I think if you hadn't tried implementing an exchange or like a trading strategy where you have to implement an order book. You wouldn't really think about this, right? You just go to a VM and say like hey I have this register machine like here's my linked list like go make it for me. But if you

actually look at the size of the proof and like the num the depth of the the checks, it's like could be orders of magnitude more than like what you're getting in your custom design, right? That stuff is like a a secret, you know, like it's like people don't talk about that type of optimization. >> Interesting. You know, we actually have a lot like this is not the only thing. There are some things like very more specific optimizations that we do in the circuit level that is not I guess in the white paper. Maybe we will publish some like writeups around those for instance there are a lot of things that's we optimize by so like in in a VM you have like maybe you have like words right like 8 bits 16 bit whatever bits words and the actual underlying prime fields of the of the snark framework is not

actually that that word right it's actually something bigger like for instance like you can allow like you have like 8 bit words let's say and you can multiply them the the result is going to be like 16 bit let's say But if you are doing this in a existing off-the-shelf VMs like it's going to do a bunch of rain checks, it's going to do like uh it's going to reduce it whatever. But here you can actually allow it to just like it's not going to overflow, right? Because your prime field is actually bigger. So you don't need to actually do the range checks here. Maybe like you can do bunch of these operations still make sure that you don't need to do any reduce it doesn't overflow your prime field. You can do those reduces like after you do a lot of computations. So a lot of

optimizations like that you can you can do like we have a lot of things like this. Yeah. >> Do you actually this is maybe another kind of dumb question but do you do do you end up doing like mixed precision like one order book will be represented as like 17 bit words another one is like four or do you actually you know use like fixed word you know precision cuz like I could imagine and I remember kind of doing this in trading where like the difference between trading like something that's you know very tiny micro cap versus like large stock precision wise was so big that actually you would I lost speed from like representing the kind of large number and fewer bits and the high precision one lower bit like like >> in the order book we don't actually like

we just store the prime field. We don't actually have like a word for it. We just store the prime numbers in the prime field. >> Oh, you store them directly. You don't take a binary representation. >> No, we just we just store them. >> Yeah. Yeah. Yeah. That's actually that's interesting cuz like that that's like another thing I guess on a VM you don't do right? >> Yeah. Exactly. These are the things that gives you advantage. can you don't need a lot of the things that VMs VMs do for all your operations. >> Well, I just think like all of this stuff is like it's interesting I think from a sociological standpoint that the types of people who find the optimizations for this type of stuff are like the people who have it's like necessity is the mother of all innovation type of thing, right? Cuz

like I think in ZK land everyone's really been focused on like client side proving ZKVMs like general everything, right? And like I think in some ways that's made it harder to find applications that are unique, right? Because it looks kind of the same as a nonZK environment. And it's like well can I figure out what I'm getting a benefit from verifiability. >> But here you have a very distinct reason that you care in that your users need to need to be able to trust that you're not like rugging them and that you're market making correctly and that like the order book is behaving a certain way.

>> Yeah. Also if the users cannot distinguish I guess your ZK rollup from like a centralized offchain matcher or from like a colloccated very high TPS L1 means like ZK is working right it's it actually scales >> what flavor of ZK are you actually using you talk about a custom circuit but I'm assuming you're using something >> that or maybe talk about your starting point and what proving system >> so we are currently using plunky 2 which works really well for our current scale uh we are active ly working on PL there's plunky 3 there is something that start grade develops S2 right and there are other things that are coming in as as as mentioned like I guess in the beginning so we are not really married to any type of proving structure our

goal is to constantly upgrade it to be the you for us to use the state whatever is the state-of-the-art for us so we are currently actually working on upgrading from plonet 2 to a faster brewing system >> and yeah we we are expected to yeah push something to production later this year or early early next year. But uh we are still optimizing a lot of things just with plunky too. Like you can have a pretty scalable thing even with plunky too which is which is a good thing. Yeah. >> I mean in that very custom circuit though so like you're looking for these optimizations. It sounds like part of it is in the build itself. But I'm wondering like the ZKVM space is heating up. It's getting faster and faster and more exciting and there's all these new proving systems and techniques and all these things. Do you think there is a

moment where the efficiency gain from what happens over there could actually be useful or do you have to like because of the way this thing is built, do you have to stick to a custom circuit? >> Well, custom circuits are like our thinking is custom circuits are always going to be like it's not going to be slower, right? Because if it was actually slower than you would just build the the VM for it, right? So, it cannot be slower. Our bet is like we saying it's going to be much faster because that's what's happening like that's what's happening in all the industries, right? Like maybe Vlad you can like share some stuff on the H like HFD word right like people build hardares right they don't use like your regular off-the-shelf CPU or whatever >> by the way this is why I was asking about mix precision cuz I used to

unfortunately have the misfortune of writing FPGA code for this type of stuff. >> So this is this is the case of everything else. So we think it's going to be the case for ZK as well. If you want something really really optimized and does exactly what you want it to be not everything but just the exchange operations let's say the best like most scalable approach we think will always be a custom roll up but you can always like have things attached to your custom rollup for composibility right like you can have like an EVM that runs on the side or like another VM that runs on the side your order operations exchange operations still go through your like exchange circuits like custom exchange circuits but you can have something on the site.

>> Yeah. So, so these these innovations that are happening with you know teams like succinct or you know we're also we spend a lot of time with Ean and you know his team like so a lot of that I think that will be useful >> to later not not to replace the custom circuits for the core exchange but like to compose it with other like let's say that we want to allow builders to come in and like write smart contracts that would share the sequencer with the core exchange for like stuff that's that needs to be official. but doesn't have to be like extremely efficient, you know, like lending, right? Or am all these other things that exist in DeFi that don't have to be, you know, you're not talking about like hundreds of millions of orders, but they still have to be efficient, though, right? So,

I think these innovations are going to be helpful for that reason. >> Interesting. So you're saying like the ZKVMs and the the work that's going on there might actually help add sort of flavor to some of the things that people can do with your platform but that core trading product or that that part of it is going to stay on the custom circuit. >> Yeah. Also I can show like some numbers maybe. So since our launch in back in January we have processed like 5 billionish transactions. Like Ethereum in its lifetime for instance processed 3 billion. Like imagine proving all of Ethereum right? like we we did like in five six months and proved everything and it's all on chain right now.

>> Okay. >> One thing I also I think is worth noting is like >> this fast path slow path thing is very common in finance where >> you have sort of like the fast path that's super optimized for like one thing and then the general purpose stuff runs slower like next to it. Like Hyperlquid is doing the same thing with HypM generally in finance and tech over the last 20 years 30 years like the advice has always been in finance like reduce latency at all costs and then in tech it's always just been like use the general purpose thing because the general purpose thing will win right like >> why why has Nvidia kind of crushed AS6?

It's because like the general purpose stuff was able to like survive long enough for like someone to find an application like AI stuff that happened to fit in it well. >> But I I kind of view finance as like focused on optimization and tech is focused on like exploration. So there's kind of like this natural exploit versus explorer trade-off. And that and I think in general you're not going to really be able to do that with a VM, >> right? like no exchange in the world that is at low latency is running their order book in a virtual machine.

>> I mean they they they are sort of indirectly but like they're they're usually super optimized for exact like the particular transaction types, right? So >> interesting. >> I think like it it's interesting that I think ZK maybe took a little longer for people to realize that. At least that's my that that's sort of the thing I find interesting is like people in ZK have been doing all these low-level bit optimizations for a while but they didn't think about making applications that took advantage of them. Well, it's like, you know, I guess an analogy like when I was in TRF, right? We would do all these, you know, all the stuff with high frequency trading where we were do being doing like millions of trades a day and with like very low latency, right? And that stuff would be super optimized and then at the end of the day

like the back office, you know, the accounting department, they would bring like stacks of paper. They would like print out because that's like the slow path, right? Like at the end of the day, they had to like reconcile. So they actually Yeah. they they they had these like huge stacks of paper and of course that's not on chain but like I guess this is kind of like the onchain analog of that right so it's like and and it's it's a lot faster than end of day but you know the the the verifiability part that the proofs that are generated that doesn't have to happen in milliseconds right I think if that happens in minutes or even hours that is generally you know good enough but like the actual trading when the markets are moving quickly you know that that part can go kind of as fast as

hardware allows you to go and then you're still kind of generating the proofs that it all happened fairly. And if it didn't then the whole thing breaks down and there's a kind of incentive mechanism for you know the sequencer not to cheat because if it does then like it can't post anything until it's reconciled and then you know within a certain amount of time like there's like this escape hatch too right so then like if the sequence rewarded sheet and couldn't fix the problem then eventually you can just take your assets out from Ethereum which you know like other architectures like Hyperlid that have their own L1 they don't have that feature right like if their L1 breaks or it's compromised kind of that said like there's no security layer >> underneath.

>> I want to understand then what you just described is that actually how you're built like are you using ZK custom circuit for the actual trades for the actual per part and then also like another ZK proof system for this verifiability or is it all built into the same thing? I guess the last part that Vlad was mentioning. So we have this different circuit different set of circuits where you can use the publicly available data on Ethereum the blob data to reconstruct your account state and you can like in the case this escape escape hatch mode is triggered you can use the public data generate a different proof that says I have this much USD in in my portfolio at the time of the latest state upgrade like state push on

the on Ethereum. Uh so that that's a set of circuits and the other set of circuits is the same like a single multi-layered I guess circuit. What it does is basically it proves everything that happens in the exchange like everything that changes the state is proven there including the order creations, order cancellations and and the trades. >> Earlier in the conversation we talked about some of the things that were being verified but I wasn't entirely clear on what you're verifying and maybe let's like compare it to what Hyperlid is verifying. So I think you said like market maker verification or something like or verified market maker rather is something that I think they pioneered potentially. Is that correct?

>> I think maybe it was GMX that but yeah I mean Hyperlquid you know they >> they have that. >> Yeah. Well I I think there is there is something to be said about you know the GMX and Jupiter versions which are more like AMMs versus like the order placement versions like hyperlquid and lighter. So, so it might be worth talking about the history of these kind of like in the wake of FTX maybe maybe I'll do the GMX and Jupiter and then you guys can do hyperlook later. So like in the wake of FTX, I mean GMX actually launched before FTX blew up, but like basically it didn't really have that much usage. And then after FTX, people were like, is there an onchain purp that I can use? And it was on Arbitum. And so in like early 2023, like February 2023,

something like that, you started to see its like usage go up a lot. Uh, and around that time basically I think I think they got to like a few billion of of of TVL. But the way that their market system worked is there's this kind of like liquidity pool. Think of it like a a unis swap style a pool where I deposit assets in and it it works in a way where the pool lends its assets to the perpetual trader. So a perpetual trader basically says I want to go 2x long a I'm simplifying this. you I wrote a paper about this. So if you really care about right reading the details, you can go read that. But I'm going to be a little fast and loose to make it easy to understand. So imagine that there's a pool that has Bitcoin and USD in it and

a user wants to make a trade that says, "Hey, I'm 2x Bitcoin." So they put up 1x Bitcoin and then they borrow 1x Bitcoin from the pool to get the 2x leverage. >> And then they pay a fee on that borrow effectively like which is like this financing rate. And if they get liquidated, their Bitcoin goes back to the pool. So the pool might take a loss if if the the price decreases sharply enough, but otherwise the pool will kind of earn the yield that the user is paying to keep the position open. >> But these are more like AMM. So they're fully algorithmic and the rebalancing.

There's like an arbitrage game of like people creating and redeeming a little bit like a unis swap style arbitrage. Okay. So GMX, the interesting thing is like they were able to show it was stable. like you weren't able to offer that much leverage and they did have a couple like incidents with like oracles issues but generally speaking it was stable but very capital inefficient right because I'm lending you the entire position effectively but that around that time Solano started taking off especially because of memecoin trading and Jupiter basically copied more or less like the the the GMX model and and that grew a lot at the same time Hyperlid was like hey we're actually going to have an order book and an order book you can't really use this I You can kind of use this lending model, but it's

insanely inefficient. >> And so, you know, I'll let Morat and Vlad explain how HLP works and how LLP works, >> right? With Hyperlquid, right? Because it's its own L1, the verifiability happens as a function of that, right? So, it's like >> consensus validators, >> right? >> Is it is it proof of stake? I'm assuming it is. >> Yes. But the hyper core is not open source. So, who knows what the the >> Oh, okay. Okay. >> The the EVM is open source. Yeah, you can decompile the binary. The binary is publicly tested. >> Okay. All right. Just to continue what you're saying, Vlad, there's a consensus like just the fact that there's a validator set consensus. That's what's verifying what's happening. That's what's proving that it's like correct,

>> right? You know, there's that. And again, there's the whole question of like, well, how how secure is that L1? But putting that aside, I mean, I think everything that happens there, you know, you could see it on the block explorer of that L1 and and that includes the operation of the internal market maker, you know, HLP. And, you know, HLP has certain rules. >> What is HLP? Is that its token or its system? >> Uh, it's it's basically just like the name of that, you know, market maker there. And, you know, you could like anyone could deposit funds into it. There's some rules about like you can only withdraw after 3 days and stuff like that. These are all enforced by contract though. So it's like it's not like a private market maker agreement.

It's like you can go deposit USDC in it right now if you want. >> Yeah. Also, it is not the only market maker. It's just a like an extension thing on top of a regular exchange where others can depose money into but you don't need to. It's just an extra feature on top of the the centralized like current centralized exchanges. It's not like a part of the protocol in a sense. >> Cool. But like importantly those funds can only be used to trade you know on that exchange and you know you need like signatures to deposit and withdraw. It's it's not like they can just take those funds and do other stuff with it. Again that's if you trust the L1 but like assuming that we do then that's how it works. Now for for us verifiability is enforced through ZK proofs right so there it's like

>> and Ethereum >> and Ethereum. Yeah. So even if we wanted to cheat we couldn't. >> So I mean I think that's even a stronger guarantee. But so we we also kind of created this LLP, you know, lighter liquidity pools to bootstrap liquidity from the beginning, right? And it's something that our quant team developed in tandem with our cryptography team like I was saying before, right? So it kind of we made sure that all works in the beginning before making the API available to other market makers. But that also, you know, again, it's like the same rules, you know, it can deposit, you can withdraw, like everything that happens needs to be signed. like you you know they can't you know there rules that this LLP has to follow and everything you can see in the block explorer like it's all transparent so it's you know so that that's kind of

what it is but the purpose for it is that the community can deposit funds like rather than some third party market maker extracting profits right like why not just have the community itself provide the capital and then they're making yield from it cuz you know market makers in general make money right like otherwise companies like Even in Trifire, right, like Citadel or Jane Street, you know, they like they're not just doing it for fun, right? Like, you know, and and it like I think market making no one has a problem with market making being profitable. I think what what is problematic is if they go too far and like, you know, manipulate the price or do things like kind of backroom deals. But like if it's transparent and you can see, okay, yeah, the market maker, you know, it makes 10 20 basis points a day. You can get the yield. You

can see exactly what it's doing. That's fine. And again other market at this point on lighter we have a bunch of other market makers too but LLP was a very useful to bootstrap the liquidity on day one. >> Wait one one one important thing and I think this is where again I I always like to think of the historical things here is like crypto kind of had this thing of like 2017 everyone to launch token you had to have a market maker. The exchanges generally ran their own market makers. So it was kind of a little bit of a mafia shakedown >> uh when you wanted to list a token. Then you know during the bare market unis swap came out and it was like hey I could actually list my token without paying the mafia price to get listed on the exchange. But the problem is that

while that was democratized like anyone could earn the yield from it. Anyone could also cause you adverse selection via all the 5 million ways of doing me all the jit attacks like you know all the stuff we've covered in different episodes. But I think now we're at this place where like people realize you need some privacy for a market maker, right? Like a market maker shouldn't be like telling everyone exactly what its strategy is at all times because someone's going to frontr run them. >> And that's what UniS swap actually was. Everything was so open. >> It's so open, right? So the verifiability is I can be a verifiable market maker where I prove to you that I'm not using your money somewhere else.

I'm not doing, you know, FTX where I'm like borrowing it and investing anthropic. I have like some constraints that are enforced and I'm proving to you that I'm very using it, you know, using it to generate income, but I don't have to tell you the strategy. >> And and I think this thing is like, you know, I think it hasn't been explained that way, but that I think is the reason these things have taken off is because they kind of are a strict improvement on the fully public. Like we went from like fully non-public >> to fully public to like somewhere in the middle. And like the middle seems more sustainable for perpetuals. I don't know if I you guys can if you guys think differently, but I I think that that that's always how I would argue how the micro structure evolved in the last 10

years, >> right? Yeah, you could say why why not like open source the market making strategy and it wouldn't cause a problem for the protocol directly, but what would happen is then like then all the third party market makers would like because their stuff is like they're not obligated to open source their stuff, right? So then they they they could just like frontr run the community market maker. >> So it's closed source then that LLP. Yeah. But but there proofs that what it does is within the rules of like like it can't take too much leverage or it can't just like move funds from your account to another account. You know, it can't do anything like that. But within the rules of what it can do, that's closed source.

>> And the the proofs that you just described, are those EKPS as well or is it more like proof because of I don't know something in the white paper? >> Yeah, I can say a few things here. So LLP is essentially an account just an account that can do anything that like most of the things that an account can do but it has this extra thing where people can buy into this account right you can say I'm going to give you like 10 bucks use this 10 bucks to market make but I'm going to take your profits as well like you you are basically buying into the account it cannot do like it cannot just withdraw these things like if if someone sends you $10 you cannot just like transfer that to somewhere else you can only do >> but how do you prove it

>> the strategy itself is again like when when a market maker runs a market making strategy they they run it right like we don't like they don't send us an algorithm and we prove that we run the correct algorithm they just say create me this order cancel this order all those LLP is the same basically LLP has an operator that operator says create this order cancel this order all these order operations are verified >> but like the fact that LLP couldn't just like move capital from one account to another the circuits enforce that right >> okay so it is the circuit It's like the ZK part of it.

>> Mhm. >> That's cool. >> Yeah. Imagine like all these things the lighter exchange does. Like imagine we moved all of all of our code to like smart contracts, deploy them onto Ethereum and the exchange is running there very slow but it's running and then everything that Ethereum guarantees that's is verifiable in that scenario is is what we prove right now. So we don't have like loopholes where we prove certain things but not the other things. just said like whatever these these features of the exchange does everything is proven as if they were just deployed to >> sort of the rules but not the strategy. >> Yeah. Exactly.

>> Okay. >> And rules are how the how the matching works. >> Got it. Okay. Okay. >> Yeah. >> Cool. Uh yeah, you just you sort of just talked about like the privacy for for a second. I thought you were using sort of the ZK privacy part like ZK in the traditional sense, but you're not really saying that like the privacy is is created by having it be closed source. the strategies offain or offain. >> Like you can almost just think of it as like there's an oracle that you can't control. That's just like giving you a bunch of orders, but it it's constrained in that that account can't do anything other than add or remove at a certain rate and like >> can't add too much because it'll cause too much leverage like like it has rules and those rules are enforced in CK. So

it's it's this is what I mean by it's like verifiable market maker like I can verify that the strategy is within this box >> defined by these rules like these constraints >> but I don't actually know the exact position. I'm treating it like an oracle and you could make that more zk like I don't know run in a te or something. I know people are have been trying to to do that but I think from a pragmatic standpoint this is the fastest way to bootstrap while also providing guarantees to the depositors. So, you know, I have obviously have been enamored with the idea of like ZK being used in this way. There's I sort of weirdly funny. There's like a very tiny intersection between ZK and people who like trading stuff, but it's like

nonzero. It's definitely non empty, but it's like it's much smaller than either of the two sides. But one thing in general I've just been thinking about is like what are other things you can do, right? this idea that you have this verifiable market maker that you can get a lot more efficiency while also like giving guarantees there's a sense in which the ZK could improve behaviors of exchanges even more so like you could have better capital efficiency in some way you could change how you onboard collateral you know I think one interesting thing about hyperlquid is I sort of think it's almost a bug not a feature that you have to use this like separate protocol in hyperunit to to bridge spot assets Whereas in with ZK,

you don't have to think about the assets you bridge. You can have assets on other chains that are, you know, doing other things that you bridge kind of just in time, stuff like that. So, what benefits do you see ZK providing lighter in the future? like what are kind of features you want to develop as you expand and kind of improve and and what you know in some ways like what are the things that you think will make lighter more successful because it's in in ZK in the future not just like the current stuff which you know we covered but but where it goes from here one just like this architecture enables lighter to be on top of Ethereum right which other architectures I don't know salon or other things wouldn't would not have so so that that's that's just like there there's still a lot more value to get

from from that right in terms of not not just in terms of security but in terms of composability with kind of other protocols on top of Ethereum. Second point is yeah this whole idea of like using collateral like imagine kind of where any asset that's kind of in in the Ethereum ecosystem can be kind of natively used as collateral for lighter so you can kind of keep those assets and trade and then you know the liquidation if you get liquidated then only then are those assets touched. So I think that's definitely something that you know the ZK architecture allows to do. I guess Rod maybe you can jump in on this.

>> Yeah. So basically it's Ethereum native assets you have like this native fully secure bridge as you mentioned like for other chains you can deposit some like soul token to Solana a contract in Solana and there can be like a ZK proof of it which then can be used to again securely mint that soul token on lighter so that they can use it. There are also like other things that comes from composibility for instance like we mention we talked about LLP but we also have the infrastructure for other people too or like other actors to yeah deploy these type of pools public pools we call them. Imagine that you have a public pool that's maintains like a 3x leverage Ethereum long position right when someone deposits it increases the

position when someone withdraws decreases it and it rebalances when the price moves. uh you can natively tokenize this public pool and it can be on Ethereum. So you can have like a native 3x ETH token on Ethereum which can be I don't know used to to to lend to a or something. So you can have like those type of things and as Ethereum scales as like rollups as as they start like sending their proofs more and more frequently then you would have this native composibility layer through Ethereum between like different alus as well. So like longterm this is going to like composibility is one of the bigger things that's going to get better and better. Also there's the since we are using ZK there's the privacy part as well right this is something that like

like we are not using like utilizing ZK part yet >> but there is something that actually you can turn on and get some like advantages from it because there are people that would prefer to market making in like a more zero knowledge environment. >> I mean a stupid thing is like iceberg orders right I probably would want a private iceberg order. I don't exactly. >> Exactly. Yeah. >> H interesting. Cool. Vlad Morat, thanks for coming on the show, sharing with us sort of explainer almost introductory episode or introductory part just about perexes, how they work, a bit of the history of perplexes, the new generation, and then your project lighter and how it kind of uses ZK in

these novel ways to Yeah. to actually like make this onchain per experience make more sense. Yeah, very cool to to learn about everything you're working on. >> Thanks for having us. Thanks for having us. >> Glad to glad to be back and glad to to bring a little bit of the dark side to to to ZK this podcast because I feel like I feel like everything the dark arts. Yeah. >> I feel like there's lots of dark arts floating around. Maybe Perpex is >> Well, I just think it's like it's this thing where like if you're not really staring at it, you don't you kind of are like it sounds like a scam or what, you know, like how I think about your reaction in the beginning. You were like uh like I I thought they were like illegal. Yeah, >> I know. But I hope you don't mind me

taking that perspective. It is It is sort of the way it's been fed to me. >> But on the other hand, I I watched someone who didn't know what a perp was use it the other day, and I'm like, "All right, well, I think we've like come across the Rubicon." >> Yeah. Cool. All right. Thanks again. I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Kai, and to our listeners. Thanks for listening. [Music]