Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Lighter EVM Q&A with Axiom
Recorded: April 3, 2026 Duration: 1:05:51Space Recording
Full Transcription
ん Thank you. Thank you. Thank you. Thank you. Hey guys, we're just about to get started.
A couple more folks are coming in and we'll get right into it. Thank you. Thank you. Thank you. Hey guys, okay, so we're going to get started.
We're excited to talk about the
LiDAR EVM. We have with us our partner from Axiom, Yi Sun, who's, you know, Yi and his team have been very helpful as we build out LiDAR EVM. We also have our lead architect, Murat,
who will be joining us for the discussion as well.
He's usually in the middle of these hard technical problems,
so it's special to have him here for the discussion.
But to get started, LiDAR EVM is our way to enable developers
to interact with the core primitives of LiDAR
in a way that's programmable and customizable.
I mean, the way that LiDAR is able to achieve such efficient performance
as we have while being on top of Ethereum is through our custom ZK circuits,
which have a lot of advantages but are not that easy to build on top of directly.
And with LiDAR EVM, you can get the best of both worlds
where for evm based applications and infrastructure providers you can actually write smart contract
code while sharing the sequencer with uh with the core of lighter and um this would be useful for
any applications such as stable coins bridges lending, lending, protocols, oracles and many others.
So yes, we'll be diving into the details and taking questions, but Murat can explain a bit more how Lighter EVM works.
works.
Yeah, thanks.
Thanks, I think your description is, yeah, I guess describes what you're building high
level.
But yeah, just to reiterate, we are building the EVM as a programmability layer for the
core execution engine of LIDR, which is going to provide primitives that requires very high
throughput, like market making risk engine to the EVM side.
And we're going to allow just builders to directly use these primitives to
build maybe more exotic instruments, trading instruments,
maybe like some markets that we are not officially supporting.
So it's going to be essentially the programmability
layer of of the exchange uh to to expand the ecosystem
and he thanks uh for joining uh i would love to hear your perspective as well before we dive into questions.
Well, hey, everyone.
Yeah, just talk through some of the challenges of actually making LiDAR EVM work with the extreme performance requirements of the existing LiDAR exchange.
So for LiDAR EVM, we had to integrate very deeply at the sequencer and ZK verifier levels.
And the end result is that users of LIDAR EVM are going to be able to synchronously read from the LIDAR exchange state
and also asynchronously write both from the LIDAR exchange to LIDAR EVM as well as to the LIDAR exchange from LIDR EVM, as well as to the LIDR Exchange from LIDR EVM
to place orders or manage positions.
And our goal here has been to offer all these features
without imposing performance or security trade-offs to users.
What that means is that LIDR EVM is going to feature
the same security guarantees that LIDAR provides today, in particular
having ZK verified state transitions, as well as escape hatches for users to Ethereum
L1 itself.
So happy to dive into these throughout this Q&A.
Awesome.
And we're really happy to have Guy Wole with us here, who's been one of our earliest supporters when we even first started building Lighter.
And he's going to help moderate the discussion.
So I'm going to turn it over to Guy.
Awesome. Thank you, Vlad.
It's great to be here with you all.
I suspect you all know who Vlad, Dysun, and Murat are.
So just briefly about myself, I'm a GP at A16Z Crypto,
and it's been a lot of fun to work with Vlad and the Lighter team over the last couple of years,
and I'm really excited about what they're building with Lighter EVM.
You guys gave a great introduction, but I thought maybe, Vlad,
I could ask you to orient the importance of LiDAR EVM in the broader LiDAR ecosystem and what your goal with LiDAR EVM is.
Yeah, absolutely.
enable developers to tap into the liquidity and, you know, the markets and later in a way that enables lots of different applications, right?
So, you know, there's some things that make sense to build in the context of the custom circuits.
And we've done a lot of that already, you know, including perps, markets, RWAs, spot.
But there are many other applications that could be built.
And LIDAR-EDM will enable all of these applications
to coexist and share liquidity and composability.
And it'll also be a really important part of serving as kind of the connectivity why we're so excited about finally being at a point
where developers can start integrating with it.
Yep, that's great. That makes perfect sense.
And I know we were talking a little bit earlier today
that Later EVM is not just another EVM rollup,
it's kind of structurally a different thing. And you were referring to it a little bit as
a programmable proxy. And so maybe for you, Vlad and Murad as well, what differentiates
Later EVM from other rollups? Yeah, no, Murad, you've been really excited
about this programmable proxy idea. So do you want to expand on that?
Yeah.
Yeah.
So the main goal of building the LiDAR EVM is not necessarily like building an EVM.
The goal here is to provide users or builders an experience where they can use the lighter primitives
synchronously, I think, which is the important part.
We are starting with synchronous reads and a synchronous writes,
but the goal here is to provide full synchronously where you can write to lighter states
by creating an order, by settling a market or whatever and you can actually read the
the result of that transaction that you sent through the evm directly on the the lighter
evm side and take action accordingly you can combine these primitive calls with each other to
do all types of all types of exotic things um so yeah the goal here is not like scale, like we're not coming with the
like, oh, we are scaling Ethereum type of approach here. Like the goal of EVM is synchronous
programmability layer for LIDAR, which also acts, will act as a proxy between Ethereum and
LIDAR execution matching engine risk engine itself. So we are seeing like a long-term world where an application deploys their atomic execution logic directly to Lighter EVM,
but users actually interact with this protocol directly on Ethereum.
So yeah, using these primitives, building like a big protocol with these building blocks
is going to happen on EVM side, but user interactions can happen on both Ethereum and Lighter EVM.
So it is essentially a programmable atomic proxy between Ethereum and Core Lighter.
And Murat, you were touching on this a little bit, but just to ask you explicitly to clarify,
what roles do Lighter EVM and Ethereum L1 play?
What different roles do they play with respect to Lighter Core?
Yeah, again, the main...
So our goal is to tap into full Ethereum liquidity, full Ethereum composability, but because of the very high requirements, throughput and latency requirements specifically to run a matching engine and order book.
and also with app-specific circuits with ZK.
And to enable developers to build things on these primitives,
to have the best experience against synchronicity
is one of the most important things here.
So you'll be able to write to the state,
read from the state directly.
So EVM's role is going to be essentially being
the part of the layer of the system where
people can build these things with atomic interactions.
And Ethereum is going to be the main hub where people long-term interact with these protocols
through, again, the EVM.
And what this unlocks is, yeah, again, like simpler developer experience for users where
they can directly interact with it.
And on our side as well for the instruments, again, that we don't want to like natively build into the core site,
which can be for like many different reasons.
People will be able to use the primitives because when you are building like a,
basically the primitives you need, you need an order
book, you need maybe a risk engine, those primitives are going to be the building blocks
and like will allow people to basically build all types of things they want on the EVM.
But hub is still being there.
Fantastic.
So now we have a sense for what later EVM is, a programmability layer, and why it matters. I would love if I can ask you,
Vlad and Yi, to talk for a few minutes about the sorts of applications that you're most excited
about on Lighter EVM. Yeah, absolutely. So, you know, I think I'll start with some of the basics,
and then I think I'll turn it over to Yi for some of the more exciting applications as well.
But, you know, some of the basic ones we'd want to have are, you know, I think right now, for example, deposits on LiDAR are, you know, kind of are going from, you know, if you're depositing from one chain, like that's not Ethereum, you have to first
go to Ethereum and then from there to LIDR, like you can actually have direct CTP that,
you know, lives on the LIDR EVM. So that would make deposits a lot faster. Working with folks
like Layer Zero would make bridging
much more efficient. We could have intent-based bridges as well.
I think borrowing and lending
would be another application that
we're already talking to
builders in the space about obviously. And yeah, I think there are a bunch of other ones
that we're thinking about.
Yi, I'd love for you to weigh in here.
Yeah, definitely.
As Vlad mentioned, there's a number of ways
that just the existing EVM ecosystem can be helpful for users of just the existing LiDAR exchange.
But beyond that, we're pretty excited to see programmability really play a role in LiDAR through the EVM.
And so to walk through a number of ways we can see that happening, the first most obvious application would be vaults, basically having smart contracts
that could dictate more programmatic trading logic and allowing users to participate in that.
A couple examples would be sort of synthetic RWA spot assets, tokenized basis trades, or even
more discretionary vaults where there are curators that are empowered to trade, perhaps with some constraints on their actions that are enforced in EVM logic.
So there's a lot of prior art on these types of applications from across the EVM ecosystem.
And with the more substantial liquidity and tighter spreads that are available on LiDAR,
I think it's much more compelling in this context.
Beyond that, I think there's the opportunity to integrate EVM into LIDAR itself more deeply
through managing different markets.
For example, having listing auctions for permissionless assets, perhaps involving some type of staking.
And then also enabling developers to create more exotic types of markets,
things like prediction markets or
binary options, we foresee a way for Oracle providers to actually integrate into LIDAR EVM
instead of the core exchange. And so we think that could be just a much easier and more secure
integration that taps into how they already integrate into EVM that works more broadly
while enabling these more market-based
applications. And then finally, as LiDAR enables permissionless market creation and definition,
we see the EVM as a way to codify that logic in a way that's both smoother for LiDAR development,
but also more transparent and easier for developers to interface with.
So in the short term, there's a lot of very clear UX wins for users for LIDAR exchange,
but as LIDAR grows for different market types and market employers, we see the EVM as a way to facilitate that. Yeah, I thought the last two things you said were really interesting,
the idea that developers can now manage and create new markets on Lighter. I'd love it if you can walk through what primitives
are exposed to developers on top of Lighter's order book and how, for example, a developer
listening here should think about the opportunity that presents.
Yeah, definitely. So at launch, developers are going to be able to manage orders and positions.
So what that means is that you'll be able to place and cancel
an order on the LIDAR Exchange from a LIDAR EVM smart contract.
In addition, developers will be able to manage their accounts.
You can create special sub-accounts that correspond to specific vaults,
or just do traditional account admin from LIDAR EVM.
As the system evolves, or just do traditional account admin from Lider EVM.
As the system evolves, we do expect things to involve market creation,
and I'll let Murad actually talk through how that might look like.
Yeah, yeah, thanks.
I guess that kind of ties to the Oracle thing that we just mentioned previously as well. So the goal here is to have the admin basically allowing people to
deploy different, this can be perpetual future markets or other types of markets. This can be
something that Lighter Core itself does not support but provides the primitives to build
this type of market where the EVM side is going to be the admin basically of this,
and it will manage, for instance, the oracles.
In the case of perpetual markets,
the index and market price inputs for the market
is going to be coming from, for instance,
an oracle provider, decentralized oracle provider
that is deployed on the EVM side.
So we are going to, what we are trying to do here is to, to
have, like having a trustless system where people can deploy these markets.
And when you are using these markets to trade, we want users to be, users to know
exactly what types of risks are associated with it.
If it's coming from like an Oracle on chain where you can see the code and you can see
the trust assumptions versus having something where it is just the market operator just
sending numbers in a data feed to the exchange.
But again, like these are, this is just an example.
The broader thing is the management of these markets where core serves as the price discovery layer and EVM side serves as the administrative actions on the market.
Yeah, I think a really interesting question here is that obviously with lighter EVM, you're opening up a really interesting opportunity for new developers to extend lighter core and, you know,
perhaps to build their own really compelling businesses on top of lighter. How do you guys
see the relationship between what should and, you know, will in the future exist as part of
lighter core is native order book liquidity, and then third party DeFi protocols that have been built on top of later EDM.
Yeah, I think, you know, I'll talk about it a bit from the high level.
So, you know, I think some applications require kind of, you know, really low latency, right?
And so in that case, you know, the native order book is really important there.
And, you know, lighter EVM would allow third parties to offer kind of more custom experiences that don't require the same latency guarantees.
And I'm curious to get Yee's perspective here as well.
Yeah, definitely.
My feeling is that with lighter core, the core exchange,
there are certain operations, things like very low latency liquidations
or just hft
level trading experience that you do really need both this very specialized sequencer as well as
the very custom zk circuits to offer both enough throughput and latency to developers whereas i
think if you look in uh the the space of financial products, the vast majority actually do not require that performance and actually involve very episodic transactions.
These would be things like most structured products, things like offering baskets of spot assets that are rebalanced more periodically to users or most types of vaults.
And so I think those are places where
customizability and programmability are more important.
And we see Lighter EVM as offering the opportunity
for developers to come and build those.
And then one thing that kind of jumps out to me
that might make a lot of sense on Lighter EVM is the opportunity for structured products that take advantage of Lighter's matching engine as the underlying value.
Maybe, Vlad, Murad, I can throw it back to you guys and ask for your thoughts on that idea.
Yeah, Murad, do you want to take this one?
Yeah, yeahad, do you want to take this one? Yeah, yeah, sure.
You know, basically thinking about like structured products where you could use, you know, you
can have the markets that already exist on lighter the perps on the spot but leveraging
kind of the full programmability of the EDM.
Yeah, like one, I guess, obvious instance of that is like, I guess you mentioned the
volts, right?
You can have something that's indexed essentially that preserves like a basket of assets and
like just rebalances every once in a while when it
needs to that still taps into so again like most of the the throughput requirements uh lighter
cork is coming from quest discovery and market makers sending orders, canceling
them, repricing all those.
But the action of taking can happen on EVM's side for these books, which does not require
the same throughput.
Perfect.
That makes a lot of sense. So now we understand what Lighter EVM is and kind
of the opportunity to build compelling applications on top of it. I think the place my mind goes
next and immediately is what the developer experience looks like. How does building
an application on Lighter EVM work today? And maybe Yi, I can ask you to take the first stab at that
and then pass it over to Marat.
Definitely.
So Lighter EVM is just a fully EVM equivalent rollup.
So what that means is that developers can use
just existing EVM tooling that they're already familiar with
and it will work kind of just exactly how they expect on Lighter EVM.
Now, of course, the key feature of LIDAR EVM is the interoperability with the LIDAR exchange.
And so that is mediated through a special set of pre-deploys and pre-compiles that are incorporated into the EVM itself.
And specifically, at the initial launch, we're going to support transferring tokens to and from LIDAR core, as well as linking certain EVM tokens to assets that are listed on the LIDAR core exchange.
In addition, users are going to be able to call pre-compiles to open and close orders, as well as track and manage their positions on the letter exchange.
And as we later roll out more admin actions for markets, things like configuring, setting oracles,
settling markets, those are going to be mediated through the same mechanism.
So maybe to sum up, the goal here is to offer a developer experience that users are already extremely familiar with
from Ethereum 01 as well as other EVM-based chains,
but with these special capabilities
that enable them to really use the core LiDAR exchange.
Perfect.
So now we have a sense for what LiDAR is,
the opportunity for developers,
and I'm sure that's prompting not just a question of how do I develop,
but how does LiDAR EVM work under the hood?
And I thought maybe we could spend a few minutes going through some of the technical details there.
And, E, given the fact that Axiom has been essential in ensuring that LiDAR EVM is well verified,
maybe I can ask you to talk about how LiDAR EVM is verified
and how that relates to the existing LiDAR exchange.
Yeah, definitely.
And this was the basis for the beginning of our collaboration with the LiDAR team.
So LiDAR EVM is being verified using zero-nalt proofs, just like the rest of LiDAR.
And so for the EVM, we are actually using this OpenVM zkVM, which is developed by the
Axiom team.
So the idea here is that the EVM,
unlike the LiDAR exchange,
requires extremely general purpose computation.
So we believe that the best way to verify this is using
a ZK virtual machine as a sidecar
to the custom circuits that LiDAR already supports.
Now, one key aspect of this integration
is that LIDAR already has an extremely high performance
and battle-tested system that's been running in production
to verify the core LIDAR exchange.
And so LIDAR EVM is actually going to interoperate
with the system without modifying the existing LIDAR system.
And so the idea is that the ultimate joint state transition
function of both the LiDAR Exchange and LiDAR EVM will settle together on Ethereum through a single
ZK proof. And the goal here is to offer users kind of both the performance of custom circuits,
as well as the customizability of ZK virtual machines.
And one thing I wanted to mention is that you might imagine it's hard to combine different
ZK systems.
And so a key property of OpenVM that we're able to leverage here is that it's very modular
and extensible.
So it's able to interoperate with existing lighter circuits while offering performance
on the EVM side.
Can I ask you to take just a second and expand a bit more on what OpenVM is and why it was such a
good fit for LiDAR? Yeah, definitely. So OpenVM is what's called a ZK virtual machine. So that's
something which can generate a zero-knowledge proof of the correct execution of an arbitrary computer program,
in our case written in Rust and run on a RISC-V ISA.
So that's in contrast to LIDAR's existing
custom circuit model where the specific low-level operations
of the LIDAR exchange are modeled
in what are called ZK circuits
and then verified in extremely high-performance way.
So in general, ZK virtual machines like OpenVM
are more general purpose
and as a result have a performance trade-off
against having the specific custom circuits
that are specialized to specific computations.
So yeah, OpenVM is able to verify
the state transition function of LDAR VM as well as
the interoperability between LiDAR EVM and the core LiDAR Exchange, all written in a
set of Rust programs.
Perfect.
And then Yi again and Murat perhaps as well, what is the security model for LIDR EVM?
If something goes wrong,
what are the escape hatches for users?
Yeah, so the goal for LIDR EVM was to actually maintain
the exact same security guarantees
as that LIDR has today while expanding the functionality.
And so the idea is that users should have
cryptographic guarantees on their assets while still enjoying the high performance of the rollup architecture.
And so to walk through those guarantees more specifically, all the state transitions on both LiDAR, EVM, and LiDAR are cryptographically verified using zero-null proofs.
And then, of course, that's not everything for security. A couple additional ones are that we are using state diffs in the rollups. So state diffs are actually posted in blobs on Ethereum L1. And then users are able to trigger force-included transactions on Ethereum L1.
And then, of course, that's not everything for security.
Ethereum L1. And finally, in the worst case scenario, let's say that lighter and lighter EVM
both disappear. If force inclusion is not respected, then user actually have an escape
patch on Ethereum L1 to get their assets back. Amrath, let me know if you wanted to add anything
to that. Yeah, I think that sums it up pretty well. Yeah, in general, escape patch, just to, I guess,
well uh yeah in general sk patch just to i guess uh extend a little bit on that so essentially
users are able to construct their full state including their positions the worth of their
positions the assets for assets they have on the exchange as well as evm by just looking at the
data that is posted directly to a theorem using the data blocks. They can, using a public open source code,
they can generate proofs of their asset ownerships
and they can get their assets back.
So the security guarantee overall,
like the system has its users.
Funds are always non-custodial.
Exchange always operates with, again,
public code that describes the execution,
which is, again, reproducible.
Using the code we have, you can actually reproduce the verify contract that we have on Ethereum to see the exact rules of the exchange.
And once EVM is live for the EVM as well.
Yeah, essentially, yeah, just operating the exchange on a publicly
defined rules, set of rules, and having this force inclusion transactions
that are basically forces the rollup to execute.
If not executed, if censored, then using the available data on Ethereum being able to exit
from the exchange, again, all maintaining the non-custodial and verifiability
of the draw.
So it seems like certainly one of the benefits Later EVM gets from being a rollup is this
really nice security model.
But for Vlad and Yi, are there other things that made you guys decide to have later be a roll-up
and benefits of later EVM being a roll-up?
Yeah, I mean, I think that having permissionless access to assets and liquidity from, you know, from Ethereum L1 and eventually like the broader Ethereum ecosystem, that's really important to us, right? from a technical perspective can be collateral on LiDAR and applications that use LiDAR.
Obviously, if it's a risky asset, there needs to be a conservative risk model around that,
but having that technology be possible in a permissionless way is really important.
I guess Yi, did you want to add anything to that?
Yeah, and to talk through how we see the ZK verification playing in here,
I think an important property of LIDAR and LIDAR EVM as a rollup system is to
enable users to use their assets in more venues and in these low latency and
high- ways, while
still having the guarantee that even in the worst case scenario, they will be able to
have custody of their assets and get out.
And so we see the role of ZK verification, as well as all these other mechanisms built
into the system as providing users that ultimate worst case guarantee.
system as providing users that ultimate worst case guarantee.
Yeah, just to add a little note, what Rollup provides, being a Rollup provides for
Lighter is essentially horizontal and vertical scaling because you can actually run the proving
engine of Lighter in parallel. If you need more throughput, you can just run more provers. This structure enables us
to scale. What we have right now is much more than what we had when we had the initial launch,
and what we are planning to have in the future is much more than what we have right now. So this
structure allows us to scale to the extreme demands, essentially,
to scale to the extreme demands, essentially,
both in terms of throughput and more importantly,
maybe even in terms of latency.
And that seems like a nice segue, throughput and latency
into kind of the last technical question
that was on my mind at least,
which is how the sequencer works for Lighter EVM.
I remember that was a real focus for Lighter Core,
and so I'd love to know what the MEV and transaction ordering guarantees are for Lighter EVM.
Yeah, so the sequencer design is that the Lighter Exchange and Lighter EVM sequencers run side by side,
and there's low latency synchronous communication between them
to facilitate the interop features,
particularly today the synchronous reads.
And so it's actually pretty important
that these sequencers are able to talk to each other
with very low speed
to facilitate block building within a necessary time frame.
And yeah, Murat can talk through more of the MEVM transaction side.
Yeah, yeah. Essentially we want to keep for the initial launch
and for the foreseeable future as well,
we want to keep the first-in-first-out ordering on the EVM,
the same as what we have on the core side.
In the future, we're actually exploring
ways to use encryption techniques to make sure that sequester,
while sequencing both for EVM and core,
to not know what the transaction is actually about.
This can be done through like different methods.
So we are exploring that as we speak,
but yeah, currently first and first thought ordering
is gonna be preserved for the EVM as well.
Perfect.
Well, I think this might be a good opportunity to turn it back to you, Vlad, and then open
up for questions from the audience.
How does that sound?
Yeah, absolutely, I think we already have two folks
who have wanted to ask more questions,
come up to the stage, so maybe we can start there
and then if others wanna come up,
please indicate that.
Tarun, do you want to start?
Sorry, do you mind just repeating that?
Oh, just yeah, we're going to open it up to questions.
So I think if you wanted to jump in.
Yeah, I guess, questions, I guess in terms of applications,
in terms of the first things you've seen,
I'm just sort of curious what,
which types of protocols you've seen a lot of demands for and what types of products you've seen, I'm just sort of curious what, which types of protocols you've seen a lot
of demands for and what types of products you've seen.
Because, you know, I think one of the advantages, you know, you can kind of build these products
into the exchange versus having the exchange and the composability be separate.
So I'm curious if you've seen anything that's you know sort of unique that takes advantage of maybe
different types of markets you have different types of funding rate properties etc
yeah so i i think uh we've we've definitely there there's been a lot of interest from
there's been a lot of interest from a bunch of builders
kind of in the space of, you know,
lending and, you know,
folks looking at vaults or, you know,
funding rate strategies and things like that.
I guess another really interesting one is prediction markets, right?
Like that's an area where certainly it would be interesting to have those markets kind
of share liquidity with core lighter.
But, you know, in a lot of cases, they don't require the same kind of, you know, I mean,
they can be operated in different models from the high throughput order book model.
So that's another really interesting one.
I guess, Yi, I know you've thought a lot about this as well.
Yeah, I would say, like, I think the biggest opportunity I see
is to just add greater transparency
and, frankly, easier operations to things like user-defined perps
or user-defined prediction markets
by putting the settlement in EVM execution.
So obviously in the broader Ethereum and EVM ecosystem,
there are many people that have done a lot of work on how to define oracles,
how to secure them, and all that work is through EVM smart contracts.
them and all that work is through EVM smart contracts.
And so if Lighter EVM can offer the ability to pull that out of the Core Lighter Exchange,
it can just make the overall system potentially more transparent and also easier to operate
securely.
For example, securing an Oracle with multi-sig management or rotating keys can be done in
a very standardized way on an EVM, whereas actually in a custom system, it's a bit more
difficult.
Yeah, I guess just to extend it a little bit, like for instance, one hypothetical can be
maybe someone wants to build a futures market price and the way for instance this flow can
can go is someone comes in and deploys an order book which is just an order book you can send
orders to it and basically they keep the state of the the futures positions on the evm side in
smart contracts.
And people, market makers, market makers
through directly interacting with the core,
which requires the high throughput,
but you have a way to read the state on the EVM.
So the liquidations on these future markets
can happen on the EVM side where a party can come,
say this is the state which you'll be able to read
the state of core synchronously. So they can come, say this is the state which you'll be able to read the state of core synchronously
so they can come say this is the state and using the oracle flow that you mentioned they can
basically show that this user needs to get liquidated and they can perform the liquidation
action or this can be actually settling the futures market as well which would use the the
oracles on the evm so essentially using the order book primitive,
which requires the highest throughput,
you can build a futures exchange.
And I think just to wrap this up on this point,
you know, I think we've been in touch with
a lot of builders, but as we're rolling this out, please get in touch with us if you haven't
been already.
We'd love to talk to anyone kind of who wants to build on top of a lighter EVM, or obviously
a lot of applications we haven't thought of yet.
We'd love to hear from you.
So with that, I guess, let's move on to the next question.
Hey, Vlad, can I jump in with a question?
It's a professor.
Yeah, absolutely.
Yeah, so just for as a use case, coming from options world,
theoretically with lighter UVM,
if someone was interested in creating a vault,
because I know that options is somewhere in the roadmap.
I think you mentioned it earlier in
the Q1 update video that you recorded earlier,
that options is in the roadmap.
But if we wanted to run
like a delta neutral strategy with options and maybe some hedging with perps, that would
be a good use case example.
Am I correct there or off base?
Right.
I mean, I think it depends on the implementation of the options.
You know, I think in some cases, it would make sense to have those use the core infrastructure.
less liquid assets or, you know, if they're executed in a model that doesn't rely on high throughput,
then it would be a great application for later EVM.
But importantly, like, all of these would be, would kind of share, can share the same balance sheet and the same sequencer. And so you could trade those kinds of markets
and hedge them with perps on lighter
or spot assets and so on.
So I think that's why all of these pieces fit together.
Okay, great. Yeah, I was just trying to think through some of the potential use cases and wanted to clarify. So appreciate the additional color there.
Okay cool more questions. Let's say maybe perhaps, I know you've just come up.
Yeah, hi guys. So, there's some facets.
Your microphone is very low, Will. That's just for me.
Maybe it's using my phone microphone. Is that better? That's just from me.
Maybe it's using my phone microphone.
Is that better?
Yeah, that's getting better.
Do you want to start over?
Yeah.
Well, first of all, thanks for taking the time.
I was wondering how fast the asynchronous writes are and what's the blocker
to make those synchronous?
Yeah, for sure. I guess
I know
Rod, you guys have been thinking a lot about this.
Do you want to win?
Yeah, right now the writes should be definitely sub-seconds.
But in terms of making it synchronous, the bigger concern is we want to make sure that no feature of LiDAR EVM imposes performance costs on the Core LiDAR exchange,
since that's the more performance and latency sensitive part of the whole system.
And so I think Murat can speak to some of the considerations there.
Yeah, yeah.
So as mentioned, we are starting with synchronous reads and asynchronous writes.
The reason for that is you don't need to interrupt the core execution
when reading from the state of the exchange on EVM.
But if you are doing it the other way,
when EVM tries to execute something in the core,
that interrupts with the remaining operations,
executes this and sends a message back to EVM.
So both sides kind of need to wait for each other
for this to happen.
So that is the reasoning.
But our goal is as these things are like faster and faster as we improve
these flows, we'll get to the points where writes can also be synchronous.
But as you mentioned, initially we are starting with sub-second writes
where you write something and you are able to reach the results of that synchronously.
So do you think that transactions originating from lighter EVM would be able to skip the
speed bump given that there's already some latency there? I think, yeah, like we, I guess depending on the accounts, so the initial thing we're
going to start with, yeah, like just you will have your account type still in the state
and when you're writing something, it's going to apply the same bumps if you are, like depending
on the market, of course course if you are accessing to a
core market that is going to be applied if you're accessing some markets that is outside of the core
then that's going to have its own logic uh but yeah the the right now the way these bumps work
is um the it's not the time sequester uh reads it but it's not added to the time when sequester reads it,
it's actually applied to the time
when the transaction is queued.
So this top second actually,
like if the latency you are getting from the write
is actually more than the bump that you are getting
for your account type,
you would actually get,
like you wouldn't actually be bumped
on top of the
the latency that you are getting from the uh got it from the rights thank you i guess one
those don't add up like essentially it's going to be taking the max of those two things got it
uh one one more practical question uh you know obviously there's a ton of future applications that could be built with these
new primitives, but it seems like the most immediately applicable gain for perps traders
is faster deposits and withdrawals, reducing cost of capital and making it easier for market
makers and traders to move money back and forth.
Are there any new security to to think about there
what do you mean by security concerns exactly like uh you, the entire collateral base of LIDR right now is, you know, run through Ethereum L1.
And, you know, I think I read something somewhere that, you know, Layer Zero is involved with this in some capacity.
And I'm just sort of wondering, like, you know, what sort of security assumptions are being made here?
I guess it depends on the asset. For instance,
if you are talking about USDC, right now if you are doing a cross-chain deposit from some chain
to LiDAR, in the background it uses CCTP. In the case where there is native CCTP on LiDAR VM,
you will be relying on the same infrastructure essentially but
if you are depositing something directly from ethereum that then uses the native native
messaging between flight search and ethereum but again like in the case of usdc cctp is
also operated by the same party right so like you you wouldn't actually
have an extra uh trust assumption in that case but uh yeah like for layer zero if you are using
layer zero then uh layer zero is the third party there so um yeah like you would have you would
have an additional uh trust assumption but thank you for the case of usCC, it is different.
Cool. I guess maybe time for two more questions.
Slyther, did you want to ask one here?
Yeah, sure. Happy to. Thanks for having me on, Vlad. And for those, just a quick intro,
I lead DeFi over at Layer Zero. We have talked about a number of different use cases that make
use of the performance on LiDAR core with the composability of LiDAR EVM. And was wondering
between, you know, vaults and staking and position management from the EVM side,
if there is a certain product idea or vertical within that realm that excites you most.
Cool. I guess Yi, do you want to start there?
Yeah, I think to me one of the most exciting is interfacing with real-world assets from the EVM side.
I think in a number of ways, one could be tokenizing the basis trade.
Another could be creating a synthetic spot RWA.
spot RWA. For example, one asymmetry between perps on RWAs and perps on crypto assets is that
obviously tokenizing RWAs on blockchains thus far has been quite challenging. And so to me,
having a perps bat synthetic on RWAs is quite interesting. Turin might also have some perspectives on this as well.
Yeah, I mean, I think the thing I'd say is, like, the composability aspects allow you to have a little bit more of a tighter margin of error for doing Athena-like, you know, instruments where, you know, you're getting kind of like stablecoin plus yield basis exposure but you're able to do it with rwas and i think one of the things that's been interesting is
no one has cracked the like commodity basis trade stable coin type of product yet like there hasn't
been you know i know a lot of people are trying on like gold stable coins or silver stable coins
but they're all still kind of reliant on a lot of off-chain
liquidity, a lot of RFQ kind of asynchronous stuff.
But I actually think a virtual machine environment where you could do that fully synchronously
across the basket of these assets and, you know, to Yi's point, like with something that
accounts for the fact...
be kind of like a product that makes a lot of sense and would be uniquely specified,
you know, I think very uniquely implemented in this environment.
Cool. Yeah, I absolutely agree. And I think just from a user's perspective, like if you imagine what it would take to bridge spot assets from ETH mainnet and design something like that myself, you know, you're using multiple forms of interop, you're bridging, you're having to deposit both into the spot and the features side, and you're having to actively manage a position that requires a pretty high degree of expertise to manage, whereas bridging something like USDC and
depositing into a vault that can directly access those primitives, I think is incredibly powerful.
I'm excited to use it. Cool. I guess maybe last question.
Jez, do you want to take that one? Hey guys, happy to. Yeah, I wanted to drill a bit more into the native messaging between the EVM, the lighter EVM and Ethereum itself.
So you guys actually just went over the use case that I was thinking about, which is sort of you spin up a vault on the L2 side.
on the L2 side, that vault holds a per basis trade against some spot collateral.
And then you could then mint stablecoins on Ethereum L1 using those vault receipts on the L2.
Is that sort of assumption correct?
Yeah, I think, Murad, you can weigh in here on the details of it.
Yeah, I guess to it. Yeah, yeah.
I guess to the initial question, yes.
And yeah, the native messaging essentially is like where the ZK proofs come in, right?
Like native messaging between Ethereum and Lighter core and EVM is basically what we
prove, right?
Like deposits are essentially messages from Ethereum to Lighter saying that this user
locked this much assets on Ethereum, give them this much on Lighter and backwards with troubles
are essentially sending messages from the Lighter to Ethereum.
But I guess what's the exact question?
Like do you have an exact question on...
Yeah, well, building off of that, I guess one exact question is what state of either
LiDAR or the L2 is available to the Ethereum EVM itself?
For example, do you essentially end up with Oracle call on EVM every, say, 15 seconds
to get the LiDAR order book state?
to get the lighter order book state?
So essentially on Ethereum, for lighter core,
we have these entry points where you can create an order
on Ethereum directly to core.
Essentially the EVM side is going to expose the same interface
where you can call any lighter EVM transaction on Ethereum to lighter EVM,
which can be again like a combination of primitive calls in the EVM for these vaults examples.
So this essentially this native messaging between Ethereum and lighter allows you to have these vaults directly on Ethereum through the native.
Got it.
And it can be a content to crosschain as well using, like, Lighter can be the programmable
proxy for other chains as well using external crosschain messaging protocols.
So building off that one more time, if I was trying to build an application on Ethereum
that I wanted to use Oracle calls on to get, say, state of LIDR order book or a micro price
at a given time, I could either call the native messaging itself to get that state or say
I could build a smart contract on LIDR L2 that could return that state if I pinged it
from Ethereum?
Yeah, maybe you want to add some stuff there, but essentially, yeah, like EVM is the proxy
between Ethereum and LIDR core, so you should be able to do whatever you are doing on EVM's
side on Ethereum as well through this method.
But maybe if you want to... Yeah, to elaborate a little bit,
LIDAR EVM does support
arbitrary message passing
to and from Ethereum L1.
And so if you wanted to read
the state of the LIDAR order book
from Ethereum L1,
we would recommend you go through
the LIDAR EVM path.
Now, the one caveat there is that for that to be message passed to Ethereum L1,
you would need to wait for LiDAR to actually settle in Ethereum L1.
And this is basically the latency point that Marat was mentioning earlier in the AMA,
where the latency of that settlement is definitely going to be significantly longer
than the latency of the communication between LiIDR and LIDR EVM.
Okay, I mean, that makes sense.
But even with some latency, it's essentially a way to pass.
There is a method to pass any precompile hit
that I would want to hit on the LIDR EVM
and pass that information in a totally decentralized manner
to Ethereum state without having to
manage my own messaging.
Yeah, that's right.
And the message passing between Lighter EVM and Ethereum L1 works very similarly to how
you might use any role of message passing.
Very cool.
Okay.
Yeah.
And in terms of latency, just to add to essentially the, like sending a message from
Ethereum to Lighter EVM, that's basically the deposit latency
and receiving the message back
is essentially the withdrawal latency.
So to actually get the state to Ethereum,
all of that state transition up until that point
needs to be proven by the Prover Services.
Got it. Very cool. Very cool.
That answers my question. Thank you.
Awesome. Well, thanks That answers my question. Thank you. Awesome.
Well, thanks so much to everyone.
I think we had some great questions from folks around the table.
And thanks so much to Guy for moderating the discussion.
And, of course, thanks to Yi for joining here and to this whole team for partnering
with us and we look forward to talking more about later EVM in the week to come and again
we'll look forward to hearing from developers and you know there's a lot of great things we
can build together so thanks everyone and I hope everyone has a great weekend.
