Atlas: Combining TradFi Performance With DeFi Transparency | Eugene & Frankie

Transcript

Uh, that's like the value creation piece, right? Uh, it's not about, you know, misdirecting the user or like tricking them to come to your chain or whatever. It's about providing them, you know, giving them opportunities, giving them better experiences they would have than they would have had, um, elsewhere. Hey everyone, this episode is brought to you by Namada, the shielded asset hub rewarding you to protect the multi-chain. So, not only can you protect your own data across any asset and any chain, but you also get shielding rewards for strengthening data privacy protections for everyone. So, you can check them out at namada.net and follow their mainnet launch. Stick around, you're going to be hearing all about them later in the program.

All right, everyone. Welcome back to another episode of Bell Curve. Before we jump in, quick disclaimer, the views expressed by my co-host today are their personal views and they do not represent the views of any organization with which the co-hosts are associated with. Uh, nothing in the episode is construed or relied upon as financial, technical, tax, legal, or other advice. You know the deal. Now, let's jump into the episode. What's up, everyone? Welcome back to another episode of Bell Curve. Today is a really special episode, actually. I'm going to be talking to repeat guest and friend of the pod, Eugene of Elipses Labs, and Frankie, uh, uh, Frankie is Lost on Twitter, is at Paradigm. This is his first podcast he's doing, and we're going to be talking about Atlas today,

which is a very exciting announcement that Eugene has been cooking up a little bit in stealth mode, um, in his role at Elipses Labs. So, those of you guys who haven't listened to previous episodes of Bell Curve or don't know Eugene, you know, they're the developer of Phoenix, which is a DEX over on Solana, and they're launching uh, their own SVM L2 that settles down to ETH today. So, we got into it. We talked a lot about the architecture. We talked a lot about overlying trends, just about, you know, this whole ETH roadmap and uh, being parasitic, and why, you know, with Eugene's background at Solana, why would he want to settle down to Ethereum? And we got into it. It was a really interesting conversation. Uh, I had a ton of fun. Uh, I will disclose as well that I am a a small, proud equity holder

in, uh, Elipses Labs. So, just including that as a disclosure at the top of the episode here. Um but this one was a ton of fun, guys. I hope you all enjoyed it as much as I did. All right, everyone, welcome back to another episode of Bell Curve. Today we are joined by friend of the pod Eugene of Ellipsis Labs, and we're also talking today with Frankie of Paradigm. And I believe Frankie, this is your first ever appearance on a podcast, so very excited to have the two of you on here. Thanks for having us. Thanks for having us. Yeah, this is awesome, guys, and this is a special day, special pod because we are actually going to talk about the launch of Atlas today, which is a new product, a new product that Eugene has been cooking up in stealth mode over at

Ellipsis. So congratulations, Eugene on on getting that finally launched. I'm sure it feels very good. Um why don't we just get right into it? I What I What I want to do is is spend this this time talking to the two of you just about some of the the high-level stuff of of why build and what What is Atlas first of all? It's a It's a special type of layer two, and I want to get into the weeds on the architecture and some of the the reasons that you made the decisions that you did there. Yeah, why don't we actually just start with that, Eugene? Enough of me talking, man. Tell us about Atlas. Yeah absolutely.

And thanks again for for having me on. So today we just announced what we've been working on for the last year or so, Atlas, which is the blockchain for verifiable finance, and our idea here is to combine the performance of traditional finance with the transparency of DeFi. So for us as a as a company at Ellipsis Labs, we basically spent the last two years building these financial primitives, where the goal is for these on-chain financial primitives to compete on efficiency and performance with what exists in traditional finance. And as application developers ourselves, you know, previously building Phoenix, which probably by the time this this airs, we'll have hit $50 billion in

all-time um cumulative spot volume. Um you know, we've learned a lot about what the needs are on the on the infra side, really getting into the weeds on the application development side, uh talking to market makers, understanding all of their pain points. And so, Atlas is kind of our response as the next-gen infra layer for verifiable finance uh for these financial applications that uh are totally on-chain, totally transparent, and verifiable. And hopefully also competitive with Coinbase and Binance and the New York Stock Exchange.

Very cool, very exciting. And yeah, I should have actually started here by just uh I'm assuming cuz you've been on the show several times at this point uh that folks would be familiar with the LPs as but yeah, you guys have done just a phenomenal job shipping uh Phoenix, which is one of the largest, most successful DEXes over in the Solana sphere. And I guess just to get into this um you know, before we get into some of the the technical architecture that makes Atlas very interesting, um you know, what walk us through what was the behind the decision to launch an SVM L2? It it it it's really um a decision that comes from first principles. So, first of all, understanding our advantages as a team where we've been application developers on Solana. We understand the SVM extremely well. Uh we've dealt with all of the ins and outs. And then, when

it comes to like building the right infra for verifiable finance, first of all, you need to be verifiable, so it needs to be on-chain and in some fashion. And then, there are a couple of key components, namely execution and settlement that are big decisions to make. Uh and it's always possible to to roll your roll your own. Um but again, in our case, we're very familiar with the the SVM. We're very confident that it is uh performant enough. And uh the the the developer toolkit and the set of developers is more than more than strong enough. It's it's very battle-tested in production.

Um so if the question is SVM versus EVM, it really comes down to performance. Where the SVM is, you know, doing thousands of transactions per second in production adversarial environment today, we're not really seeing anything close to that with EVM yet. I'm sure um the EVM scaling efforts will eventually get there. Um but SVM is is is scaling as well. The other thing we get from the SVM is because there is this notion of uh native state access list, it's very easy to implement a uh local fee market. So you can actually have different state hotspots that

require different amounts of fees that need to get paid. This also lets you get parallel execution. Um pretty much out of the box. And then Ethereum as a settlement layer is kind of a no-brainer at this point where I mean Ethereum is just really focused on becoming the best settlement layer for for quite some time. Um and so it really shows in the the focus on availability and censorship resistance over things like really optimizing the hell out of execution layer, which is what Solana's been more focused on.

Yeah, I'd say just to double click on on the point about the developer community. I think over time we've seen a somewhat divergent evolution in the application design space between Solana and Ethereum. I think the SVM has sort of acted as a forcing function in that you can't just copy-paste some EVM code and redeploy on Solana. So if you're going to have to build from scratch, you might as well build something new that really takes advantage of of the substrate that you're building on. I think this is an opportunity to now bring some of those lessons from Solana application design to Ethereum users so that they can use the applications with Ethereum assets.

Yeah, Frank, that's such a good point, man. I honestly, the way that I would describe this as well as steel sharpens steel, right? So, as we've unbundled a lot of the different functions that blockchains have historically done, Solana has focused quite a bit on execution where as Eugene to your point, Ethereum has been pretty laser focused on being the best settlement layer and it's been pretty cool, I think, to watch actually the success of Solana and that focus on execution actually push innovation on the roll-up layer on Ethereum, right? So, you see that from folks like the Monads of the world, but also a lot of the L2s are starting to experiment with that as well, which is just I think just a super cool, very positive development for the entire space.

And so, maybe just to to summarize here, you know, some of what we're saying, you know, I think there's there's the decision to be, you know, an SVM based L2 on Ethereum. I've got some questions for Eugene about why, like what that really means with Ethereum being a great settlement layer and why that was more attractive maybe than building like an L2 that settles down to Solana. I think just for, you know, some of the the other folks who are maybe a little bit less technical or forgot some of the differences in between the SVM and the EVM. I actually want you to walk us through like what are some of the tradeoffs there, you know, those state access lists and enabling a sort of local fee markets and parallelization, I think, are are really interesting. I just want to learn a little bit more

about that. But what I really want to to to drive towards here is the design of Atlas. You know, we talked about this a little bit in before we recorded this. You were very, very, I would say, opinionated in terms of the decisions that you made for constructing this L2 and are really building this is like a really an ideal home for DeFi applications, which I think is very cool. It's almost somewhere in between, at least in my mind, you correct me if I'm wrong, in between this kind of very gen purpose L2 that we've seen from the Optimisms and the Arbitrums of the world, which is just come one, come all, right? I just want everyone to build here versus a full stack Cosmos app chain, which is just you know, kind of the Osmosis, you know, Binance on chain type thing. Whereas, I

feel like this is somewhere in the middle, which is a a a somewhat general purpose L2, but really optimized for defi applications in the way that you've chosen to differentiate is by making some very specific decisions, which I want to get into. Um but before we get there, can we just start you just give us a refresher like for us who don't spend all day, you know, in either the EVM or the SVM, like what are high level the sort of differences in between um those two virtual environments? Yeah, and I'm sure Frankie will have a little bit more to say on the on the EVM here. So, the Solana virtual machine, actually my co-founder Jerry's about to give a talk at Solana Breakpoint on what actually is the SVM.

Um we can get really nitty into the details of uh you know, what the VM is or isn't. I'm much more interested in what the VM enables out of the box. You can sort of do whatever you want in any VM. They're both pretty much Turing complete. Um and so it comes down to one, like how much performance, like raw performance can you get in a single-threaded manner? And then two, how much parallelism can you squeeze out? And now there's a bunch of other things too, like how is state represented, um how do you merklize state or compress the state in two way that um where you can publish a uh use full state commitment to the layer one.

Um and so those are some of like the custom things that we've had to build uh for Atlas, where they're not really important for Solana's layer one, but they're super important for Atlas's layer two. But going back to what is really enabled by the SVM or like the existing SVM toolkit. So, something like the state access list, um this is actually proposed as like an EIP, an optional um thing to include with transactions that are sent um on Ethereum. I'm not sure if that EIP ever went through, but it's not like a VM level thing. It's more of like an implementation detail how the execution environment, which is not just the VM, it's the VM plus a bunch of other things, uh how that's implemented, but all of the like existing Solana

tools take this into account, which means pretty much every application developer on Solana knows how to use it. Um And and that means we get the benefits of having the state access list, which again are uh much easier to implement parallel execution and much easier to implement local fee markets, uh state-based fee markets, um which again goes back to uh being able to parallelize load. I'd get it out if you have um some more to say about this especially from more of the EVM side of things as well.

Yeah, I mean I think, you know, there's scaling efforts throughout the whole ecosystem. So, I think like uh today um yeah, EVM especially on the base layer uh it execution is behind, but I think there there's a lot of efforts to to introduce like EVM performance, um you know, Reth is one such effort. Um you can get some level of parallelization, although it's quite harder without without the access lists, and then you can make all sorts of perfect improvements like uh just-in-time or ahead-of-time in the compilation, uh you can parallelize your state root computation, etc. These are techniques that are applicable sort of across the board. Um so, I think yeah, we'll see

performance improve improve everywhere, um but I think the SVM really gives you a strong baseline to to make a lot of those uh performance improvements, and it was designed with a lot of this in mind. So, it requires sometimes less work than it does trying to scale a scale EVM. And just the state access list as well as for folks who might not be as sort of in the weeds or familiar, that's just where the what what are the the differences in between the SVM and the EVM is when is Devs need to specify up front which part of the state the this transaction is going to touch, right? So that later in the process when transactions are being ordered, you know, there's some understanding of which which transactions can be

parallelized versus not, right? So that's what we're talking about. And and I guess I the through line for me as well is that we're we're still, you know, in the throes and in the thicket of of scaling these systems and there was an enormous amount of work on the Ethereum aside the Ethereum side of things with 4844 and just blob pricing, but I feel like what we've sort of figured out since then is that there's still a bottleneck and it actually still exists on the at the execution layer. So the SVM is a is a pretty big leg up in terms of the throughput that you can move through an L2.

Do you do you guys get Is that is that roughly correct? What do you say? I don't know if you do. I think it's a fair assessment given the systems that are currently in production. I think probably the EVM layer two some of them could crank it up a little bit more, but I don't know if they could crank it up by like a factor of 10 or 100. Yeah. Let's talk about some of those other, you know, sort of more opinionated decisions that you've made around you know, like I thought enshrining an oracle was actually extremely interesting Eugene and maybe you know, even before you know, maybe even before we get into some of the specific decisions that you made with the architecture of Atlas. You just walk us through how you think about the philosophy of being opinionated versus unopinionated in your designs.

Like I think that so far if you know, you hear a lot of Ethereum protocol designers talk. there's been an overarching philosophy of pushing complexity to the edges and being this very neutral unopinionated layer. And I think that some of the layers on top of Ethereum, both L2s and application, borrowed some of that philosophy, but it might not actually apply, right? Like that that isn't something that should be carbon copied, I think, necessarily up one layer. The whole point of being neutral and unopinionated at the base layer is so that applications and um you know, different environments that are building on top of Ethereum can complement that with with an opinion, right? So to speak. Uh so just just just talk to us a little bit about how you guys, both of you, think

about like this opinionated versus unopinionated design philosophy. Yeah, Mike, I think that's exactly right. And, you know, Ethereum as this very credibly neutral um piece of infrastructure actually makes it super useful for us um because as a settlement layer, uh Ethereum's, you know, neutrality as well as its uh censorship resistance makes it um really an ideal place to settle uh another piece of infrastructure, too. For us, you know, we we're not infra developers at heart. We're really application developers. If we had our way, we would be spending all of our resources um you know, building out more applications and, you know, uh talking to talking to

those those types of users rather than building out the the infra. Um but Alice is really just the infra that we wish existed, that we wish we could build on top of, and we will build on top of it as well. Um and it yeah, it just it just turns out like from the application developers' point of view, or from our point of view as application developers, um there's a lot more a blockchain, especially a layer two blockchain, can offer that uh you know, a layer one might not be able to. So, for example, with um uh you know, enshrining an oracle, uh really all we're doing there is enforcing this rule in sequencing, which is essentially that hey, any transaction

that comes from the oracle gets in maybe even for free, but certainly gets in as quickly as it wants to get in. Such that you know, even in times of high volatility, even if fees are spiking or it's like somewhat congested on the layer two, we just you know, guarantee that via the the sequencer that the oracle is going to land. And it turns out, you know, is this the most neutral thing to do? No, it's like clearly prioritizing these oracle transactions. There might be other types of transactions you want to prioritize or deprioritize as well. And at the end of the day, that has to serve the applications, which have to serve the users. So, everything is coming from the perspective of how do we build the best infra for a specific type

of application. For us it's these verifiable financial applications. I'm sure like you know, it might make sense for there to be like a very gaming focused layer two with its own sequencing rules. You know, sequencing that is not just based on priority. It turns out for a lot of financial applications, it helps to have a first of all obviously very high throughput and very low fees, but also um you know, things like sequencing that looks much closer to first come first serve rather than priority ordering. And I think the sequencer design is is this area that's kind of been under explored at the layer two level. We see a lot of reliance on priority ordering today. And especially in a regime where

the sequencer is centralized for I believe every layer two in production today, there should be a lot more room for creativity there. And so that's all just going to be this back and forth with application developers. You also want to be mindful of you you as an developer, uh, if the infra underneath you is constantly changing, it's very difficult to build an application on top. And uh, that also means you can't be changing up the sequencing rules all the time. Um, but this also happens in other ways, right? Like uh, I think there were a lot of a lot of the early applications on Ethereum layer one were built without much of an understanding of how MEV was going to play out. I don't think anyone really understood how the MEV game was

going to play out. Um, and then certainly with like layer twos today, um, we have a lot of applications that were built for the layer one that have been kind of mindlessly ported over to the layer two, and maybe some of that doesn't make too much sense, either. Yeah, I mean, here's so I've got a lot more specific questions about that, but here's what I'll just say I really like about this and it's a very refreshing new take. I feel like in crypto, one of the superpowers of of our industry in just building things on chain is you can incentivize people with tokens, right?

It's very easy to spin up markets. It's essentially very easy to uh, incentivize people to bootstrap uh, demand. And that's very cool. That's a really powerful lever when used very strategically, um, but I think also you all some protocols have run the risk of run the risk of using that as a crutch where, you know, it's just like, "Hey, I want uh, gaming or this other, you know, this other, you know, application sector come on here, so I'm just going to spin up this massive reward system for it instead of very intentionally designing the environment to attract those specific types of applications. And I feel like you've almost gone on the opposite spectrum and said, "Hey, I, you know, see this very broad swath of uh, very attractive applications, which is DeFi. I know

that, uh, you know, here's what I think some common problem sets are for, you know, payments or, you know, um, on-chain order books or whatever it is. That's what they all have and I'm going to design features that make it so that you'd be crazy to build anywhere other than Atlas." Is that like a ba- basically a fair assessment of your strategy? Yeah, that's exactly right. And on the ecosystem development point, you touched on this a little bit earlier but you know, we really view ourselves or we really view Alice not as general purpose blockchain, even though yeah, the compute environment will be general purpose and certainly not as a single application chain, but more as an ecosystem chain.

And honestly, probably went into this on some old podcast as well, but really the reason you want a bunch of different applications on the same chain is if they need to share state or if they need to compose with each other. And I think there's a very easy story to tell that different financial applications might want to talk to each other or users may want, you know, to use collateral from one application and and go take it to another financial application but I think there's not quite as strong a story for things outside of crypto finance composing with other things in crypto finance. So, I think it's a very natural boundary to draw.

Yeah, you know what? I would be curious and frankly, I'd love to get your take on this as well, but I this is something I've started to notice a little bit and I don't want to derail us too much here, but something I started to notice just looking at some of these L2s as a business model, it feels like and I guess Eugene, this is a question for you down the line as well, like if you ever have plans to develop this kind of stack, right? Like the OP stack or elastic chains or orbit chains on Arbitrum or whatever, but it feels like the way that a lot of L2s have chosen to monetize is by charging for interoperability, right? they said, "Hey, we think that applications are going to want to own their own chain and we think also that the killer feature to

essentially include them in this bundle of OP stack super being in the super chain is interoperability and we're going to charge them for that. But then you look Look some of these chains and you know to your point Eugene they're not D5 where there actually maybe is a real premium on interoperability right or access to shared state and it's kind of like some gaming chains you know like the you know world chain like decentralized AI and it's like well do you really need interoperability between these chains like what actually is the benefit this this doesn't actually feel like a bundle that was constructed very you know intuitively or very purposefully. So so what do you guys think about that in general like for the

business model for L2s like am I am I wrong here that it feels like the the implicit assumption is that L2s are going to be able to charge for inner up you know do you see a flaw in in a business model and Frankie I would just like to get your whole take on you know Eugene's strategy here of you know specifying more for D5 applications. Yeah I mean I think it's a nuanced point I think there's different kinds of inner up that have different value I think like at the base level like the simplest form of inner up is like I want to transfer my assets from one place to another and I think like that's always valuable no matter what chain you're building because like access to liquidity is is quite important

then if you're trying to build some sort of atomic inner up then then I think it matters at the applications sort of play well together so atomic inner up between a gaming chain and a D5 chain sort of doesn't make sense or it'd be hard to imagine that has a lot of premium so I think it's important to keep in mind what what the type of inner up is. And then yeah on on the question of opinionated and opinionated design I think you had a good point that it sort of there's a spectrum where on one side you have current EVM layer 2s which are mostly opinionated they run pretty vanilla EVM execution Um, they don't they don't try to make a

lot of changes because they want to attract as big application base as possible, and then they try to differentiate on other factors. So, um, either trying to push performance, uh, leaning on branding, um, or like something more idiosyncratic like access to a centralized exchange as an off-ramp on-ramp, for example. And then on the other side of the spectrum, you have, uh, as you mentioned before, Cosmos app chains. Um, and this is the idea is like you can really program your full stack, so you can bring your own VM, you can modify execution however you want, and then you can also program a lot of stuff underneath execution. So, the P2P layer, the mempool, block validity, um, and

yeah, this gives you a lot of power, but it is also very difficult to onboard developers because the barrier the barrier to entry is much higher. I think something like Atlas is in a happy middle ground where, um, you get mostly sort of vanilla SVM execution, so developers are familiar with how it works. It's it's easy to deploy applications on it, but you're also making these decisions at the margin of like how do you design your sequencer, um, what types of applications do you prioritize, et cetera, um, that really enable, uh, better DeFi applications specifically. So, yeah, I think you you get both a best of both worlds in that it's easy to come build an Atlas, but also you're

building on a substrate that has been specifically designed for your application to be successful. Yeah, I think it's just a very cool very cool as a as a design philosophy. Actually, we did a, um, not to give a a self-call here, but we did a we did a whole season on app chains, uh, like it was the third season of Elcore or something like that. I did it with, uh, Miles O'Neal. And we actually ended up aligning And one of the questions that we were asking is like what is the trade-off spectrum between like you know an OP super you know one of the a chain in the super chain on optimism versus like a full stack app chain. And we actually said that maybe there should be something like more instead of app specific or general block space like something like sector specific block space which is it

seems like you know what you've landed on here a little bit Eugene and I I want to I want to get an understanding for you of the different types of DeFi apps that you're now I actually kind of want to get into some of the specific design choices that you made and what are what are the specific apps that you're trying to attract and what were some of the properties that you were gunning for and I'll share my screen here and I'm just pulling up the this is one of the tweets in in your tweet thread today but and it will like will link this all in the show notes for folks that want to go a little bit deeper. I'm not sure if you can see here if I'm zooming in but basically you know it said what you were the design choices that you leaned into were

speed of light pre-confirmations and an inter-twined oracle and some of the use cases that you walked through were on-chain order books margin systems and high frequency trading. So can you and you sort of compared and contrasted what a general purpose blockchain might offer versus Atlas. So Eugene can you just kind of walk us through you know how do you align on speed of light pre-comps and inter-twined oracle as design decisions and you know walk it like help us translate into some of the different applications that you're trying to attract and the benefits for them. Yeah I would say both of these really came from us thinking through how Phoenix could be better and in particular how the infra layer could better serve applications like Phoenix.

Phoenix I would consider like a relatively beefy application one where um some entities here for us it's market makers could be other types of entities for other applications really really require the high throughput and um low fees and they're you know placing and canceling tons and tons of orders. When we say speed of light pre-confirmations what we really mean here is, you know, we don't wait for Atlas isn't going to wait for 250 milliseconds to then go build a discrete block. Atlas is pretty much processing transactions continuously or as continuously as it can.

Uh you can think of it as much closer to first come, first serve rather than priority ordering, rather than so continuous first come, first serve rather than discrete priority ordering. And so when a transaction comes in, if the system's not bottlenecked, it's going to the sequencer is going to process and execute your transaction and then send back the uh confirmation and state diff uh to the to the transaction sender right away rather than waiting for an entire block to be um to be produced. And actually like the notion of a block even doesn't make too much sense on a on a layer two um because the actual unit of consensus is something like uh how often does the sequencer post a new state root back to layer one or how often are transactions

posted to the the DA layer how often does the DA layer come to finality. And then the oracle really comes from uh again seeing some some of the pain points that are um you know, Phoenix doesn't use any oracles, but some of our fellow developers on on Solana have run into especially during times of uh heavy heavy congestion um on Solana. And it turns out that the time your application needs the oracle the most is when there's high volatility and when there's high volatility is there's more likely to be congestion on the chain, too.

Um so it's sort of like when you need it the most it's least likely to be there. And so by enshrining it, you effectively are like carving out some small set of the block space, like reserving some of the block space for just the oracle. And maybe it's not going to use all of it. Uh maybe it's actually very predictable how much it's going to use. Um but you just always make sure there's this like fast lane available for the oracle to land whenever it wants to. And that means the application developer can build their application with the understanding of like, okay, your all is going to have an oracle price within the last, call it 1 second, but realistically speaking, uh you know, like double digit or yeah, call it double digit milliseconds.

And that means you have a lot more freedom in designing your application versus one where hey, you know, usually the oracle is there every second, it's there every slot, but sometimes and actually your time of need, it might not update for 10 minutes. You need to be robust to that case as well. Um so, we're really defining the um sort of characteristics of the chain that application developers should be able to expect. Um and and particularly, yeah, like not throwing up our hands and saying, well, that's someone else's problem. Um at the end of the day, the infra exists to serve the applications. Infra doesn't exist just for the like the sake of existing. Um uh in the same way that Phoenix has a

very core set of users, which is the market makers. And um um you know, those like four or five market makers, we we have to give really good white glove customer service to. Is your It seems like Eugene, obviously these these properties were designed to be very valuable for DeFi specific applications. And a lot of them, especially around the inch dried oracle, it seems like that was optimized to deal with um congestion. And the way that the way that this noisy neighbor problem has been There There have been a couple of different solutions to this noisy neighbor problem, I suppose, which you can now add this to to sort of the

bucket, which is one is just uh having separate chains, right? It's like, hey, don't worry, this isn't going to be all in one layer, we're just going to put it on a separate chain. The other is um local fee markets, which are still I don't know what the current status is. I know they they were a little bit of a meme in Solana for a while. You would know better than me how how effective they really are in production today. And now, like one of the new buckets that I feel like you had is even deeper tooling in these separate swim lanes for Oracle updates and you know, presumably other alterations that you'll make in the future. Um I have a question for you. I mean, did is there a plan right? Don't reveal any state secrets, right? I'm just but I'm just curious like what what do you think

about the these like stack chain models where there's maybe like a a main chain like Atlas one or or whatever and then a bunch of different chains around it or is the goal to keep all the different applications like the DeFi applications that you're trying to attract all on one layer? Um yeah, for the time being we are looking to keep everything on the same layer. I think it really like I think it's really hard to tell what the ecosystem is going to look like at this point. And so it's tough to commit to you know, something a year or two from now or or a few years from now.

I think to Frankie's point, the like types of composition that are valuable, even that is like not super clear. Um and that is also going to be this like emergent thing that comes from this emergent property of like what applications end up being super useful. Uh maybe it is just going to be trading with like on chain order books and super efficient like cross margin systems. Maybe maybe the permissionless innovation layer will deliver like these totally new types of financial primitives that either require or don't require composition that maybe require like a totally different set of um um uh opinionated sequencing rules. So like we picked the ones that we think are are

really important and that's really informed by uh our experiences. But uh yeah, it's not like 100% clear that these are the the correct ones either. Yeah, I'd also say there's sort of a key trade-off here where if you shard state, it allows you to scale, but it it does fundamentally limits the the interrupt that you can get. Um there's a bunch of solutions for interrupting L2s, but basically it's very hard to beat applications co-located on the same L2.

So, you don't want to do the state sharding too prematurely. You want to see um how how far how far you can scale the L2 that you're working on, see what applications emerge, and then, you know, give yourself the optionality down the line if you need to. But, uh yeah, I agree with you, Gene, that you don't want to do that too early. Hey everyone, this episode is brought to you by Namada, the shielded asset hub protecting the future of the multi-chain. Namada is a chain that's near and dear to my heart because in previous seasons of Bellcurve, we've talked about how the cardinal original sin of most blockchain systems is not thinking about privacy from the beginning, but also because if we want to onboard a whole bunch of applications, it doesn't work in a default transparency setting. So, Namada

not only brings about a better future that we all want, but is going to help onboard a ton of new applications. So, Namada introduces a novel shielding reward system. The way that it works is if you hold your assets in the shielded set, you help strengthen Namada's data protection guarantees and collect Nam rewards in return. Namada will initially support IBC and Ethereum-based assets, but eventually the idea is for this to expand into a comprehensive hub for all assets. Really, really excited about what the folks over at Namada are doing. I highly recommend that you go and check them out at namada.net. You can follow their mainnet launch, which is soon TM, very exciting. Tell them that I sent you. Click the link bottom of the show notes.

Sounds like Frankie, that might potentially be a commentary on another L1 that might have decided decided to shard so their execution a little bit early. Maybe you know, I don't want to spend too much time on this, but I do want to I do want to get your take because, you know, this is this is the the launch of this L2 is kind of smack in the middle of this this is kind of the big debate that's going on in crypto right now, which is the ethereum roll up centric road map and you know, did we either move a little bit too even if this was eventually the destiny of ethereum and there there going to be a bunch of L2s.

You know, do we move a little bit too fast? Did we stop scaling the L1 before we ultimately ended up needed needing to our L2s like parasitic is this word keeps getting thrown a lot around thrown a lot thrown around quite a bit and you know, I frankly I would love to you know, maybe from your seat is at at Paradigm or as someone who's helped design Atlas a little bit like what are your thoughts on this entire debate in general? Yeah, I think you know, Twitter debate often lacks nuance. So Twitter? Really?

That lacks nuance? Yeah, so I think that's that that's part of the issue here. I would say yeah, on on the point of whether L2s are parasitic um you have to think about yeah, what drives the valuation of L1s? I think broadly you can you can break that up into fees and then monetary premium. Fees on the L1 come from a variety of sources. So base fee reflects just general congestion, priority fees come mostly from MEV and then you also have block fees from from L2s posting data to the L1.

And then I think the question is like as as activity moves from the L1 to the L2, what happens to to these drivers which are yeah, fees and monetary premium? I think it's pretty clear that you'll see fees going down. So base fees will go down because just general usage and congestion goes down. Priority fees will go down because MEV moves to the L2s. Um block fees will go up, but right now they're they're so small that the net change is basically fees go down.

Right. And then you have to look at what happens to monetary premium. So, uh if Ethereum is is widely adopted as the native asset of L2s, then um it's more likely to to function as money, right? You see being used as a unit of account and as a medium of exchange in in most of these L2s. So, um yeah, there there's sort of counteracting forces. It's hard to tell exactly where we end up. So, I think like calling it parasitic um is sort of an unfair characterization at this moment. So, basically, and I just actually did a podcast on this um last week, but the the trade-off would be, okay, it seems like all of those fees, you know, if you were to run like a DCF on Ethereum, the

fees that were that when it was all one layer, Ethereum was printing back in 2021 and 2022, it's going to take a long time if ever that we get back to that those level of fees. At some point in the future, I'm you know, I'm sure we probably will, but the amount of fees that are being generated by Ethereum right now are um likely likely down down only, um and will continue to stay a little bit muted. And so, if you're valuing Ethereum based on that, it's it I can see how it would look a little bit um not super positive. But on the other hand, there's this monetary premium aspect to Ethereum, which is do people want to hold this as a money and a store of value? And when you have a really diverse L2 ecosystem where you can do things like build applications that you

can never built on the L1, Atlas being an excellent example of that on the DeFi side of things, you're actually just growing the pie, and the hope is that people are going to want to use, you know, ETH as a money on those chains. And so, the liquidity network effects that you get with these, you know, a multitude of L2s and apps, you know, order of like hopefully orders of magnitude larger apps and users on those L2 using ETH as money, that's going to outweigh the fees that you that you lose. Is that like roughly the size of it? That's right. Yeah, I think it's a fair summary. Okay.

Cool. I think like at the end of the day, if you're really focused on fee capture, like the way you grow the fee capture is first by growing the like the the total size of the pie, growing the total value created. And if you look at like Ethereum or you look at let's say all blockchains today, there's what maybe 100,000, a couple hundred thousand like actual users. Yeah. Um even that that's even like very small compared to like all like crypto users, right? Most crypto users are just centralized exchange users. I believe Coinbase is like 10 million monthly users.

Um Binance probably has more. And so I think the focus really ought to be first on like creating applications and experiences that users actually prefer to their centralized counterparts. Um uh that's like the value creation piece, right? Uh it's not about um you know, misdirecting the user or like tricking them to come to your chain or whatever. It's about providing them, you know, giving them opportunities, giving them better experiences they would have than they would have had um elsewhere. And then the value capture I think comes far later and it's like very unclear at this point, you know, does the value go to the infra, does it go to the applications? Um uh maybe it goes to like the I don't know, the the stacker aggregation layer.

Um who knows? I think it's like way too soon to tell and again, a lot of this is is very path-dependent. Uh maybe it'll go to some very vertically integrated team. Um but I think the discussion around like are the L2s parasitic is a little bit premature and is mostly driven by this angst around the the token price. Like I think if ETH is at 4K or 5K right now, uh it's like no one would care whatsoever, even if the the fees were still down. Yeah, I am fully in the camp that price drives narrative and not the other way around and the the cure for this is definitely a a healthy bit of number go up.

Well, Eugene, I actually would love to get your your take in general cuz you used this phrase right at the beginning that Ethereum has optimized for being this settlement layer. And could you walk us through in a little bit more detail, you know, why you decided to I mean you you guys built Phoenix on Solana, you know, you decided to use the SVM. I feel like a lot of your DNA is sort of in the Solana community and I I'd just be curious why you made the decision to have the settle down to Ethereum and and and even if we could get in your definition, like try to pick apart some of the technical decisions that Ethereum has made to optimize as a settlement layer versus the $300 of crypto native capital that exists in the form of ETH asset versus the 80 billion on Solana and how you like how both of

those um, you know, factored into your decision. Yeah, so settlement gives you a bunch of different things. Um, first of all, there's like some requirements you have from a settlement layer or uh, like let's let's call it a set of different things that you settle to. Uh, so there's this data availability component which uh, Ethereum has been building towards uh, for for quite some time. Uh, previously it used to be um, you know, roll up transactions getting posted to call data. Now they get posted to um, the the blob storage. And then there's also this notion of how do you build the the the native bridge to the layer two.

And there's a couple properties you want from your from your layer one if you're building a layer two. One of them is censorship resistance because the way layer two inherits like availability from the layer one is uh, even if the layer two sequencer is censoring a user or some set of users, they're still able to exit via the escape hatch. They're still able to permissionlessly include transactions. And so it's actually very important for a layer two that the layer one is you know, as censorship resistant as possible.

And then you also touched on the the point about assets where you get access to the set of assets on the layer one in this in this trust minimized way. And yeah, there's a you know, hundreds of billions of dollars of assets on ETH mainnet. And a lot of those users hold those assets just like haven't just like haven't gotten exposure to, you know, the set of Solana applications. I often hear from Ethereum users or layer two users moving over to Solana feels like, you know, stepping a few years forward in time.

That's the type of experience we'd like every Ethereum user to have whether it's on Alice or somewhere else. And so, settling layer two to Ethereum I think is just kind of a kind of a slam dunk for us. So, I want to poke at poke at that a little bit. And so, here's a here's something that I've been thinking So, you mentioned the force inclusion and kind of like the escape hatch. And I want to ask you guys a question that I've had in the back of my head for like a couple of years and never really feel like I've gotten an answer to. And I'm sure you maybe you guys have thought about this before. And then, you know, the other thing is just what are the properties that an L1 affords their L2s?

And I think like settlement assurances is definitely one thing. But the other thing I've wondered that Solana has that might make something like base sequencing a little bit easier is it's just got much faster block times, right? So, there are all these, you know, you got to jump through a bunch of hoops on the Ethereum side of things on cuz you have 12 second block times to, you know, if if you wanted to have Ethereum sequence transactions, having having rollups wait 12 seconds would obviate basically all the benefits. So, you have to do this kind of fancy pre-comp system which feels a little bit tough. But on on something like Solana, maybe inner up would actually work much easier because you could just easily ping transactions down and then back up.

Um I actually think Rome is basically designing There's a protocol out there that is trying to get people to use Solana as just a shared sequencer anyway. Um but I want to start with this first question I had for you guys, which is, you know, Eugene, you you guys are trying to attract businesses to build on Atlas, right? You're trying to attract applications. And the the benefit for users, right, is that if there were ever some, you know, sort of catastrophic fault or the sequencer got compromised or whatever, the users could port their assets down. But you know, let's say I decided to build my application on Atlas. I'm not saying this would ever happen, but this this relevant for every L2, right? I decided to build my application on Atlas.

Um something ends up happening and all the users, you know, start to move their assets off the chain, I can't really port my business off the chain, right? Like I've built on your specific SVM, you know, uh customization, you know, most of the other rollups that exist on Ethereum today are um EVMs and like I couldn't really just take the business that I built here with all my customers and and activity and just move that over to, say, Arbitrum or Base or something like that. So, I get it from the user side, but but do you see is is there a challenge there from the business side of things where there's no there's no such thing as a as an escape hatch for apps that get built on rollups?

And do you see that as an issue? Um I might not be understanding the the the question all the way. I think kind of no matter what, if uh you know, you're an application, the infra has some catastrophic fault, uh first of all, the most important thing is users are able to exit. Right. Uh exit in like a safe and obviously like relatively cheap manner, even if maybe it takes longer than you would like. Um and then, you know, second, like once your users and applications are sorry, your users and assets or even like the underlying infra is is gone, like you kind of don't really have anything anyway.

Um Um So, I I I'm not sure if I really understand the question here. Okay. I guess that the uh the the idea just being, okay, so your users and your user assets are protected, but there's still maybe some degree of um platform risk for L2s that you're taking on as an app um choosing I think as an app picking any infrastructure, you are taking on platform risk in the same way that if, you know, we built a SaaS app and we put it on AWS, there's some AWS risk and in fact, like you do realize that risk every now and then. Or building on any layer two, you're depending on um you know, that layer two's um bridge to remain secure or any other uh you know like

I mean, it's true for any application and and any infra, or really anything you decide to depend on. Maybe that's a little bit too reductive a view, um but as, you know as as application developers, I can tell you that you know, I'm sure every application developer takes this uh decision very, very seriously. Like when you are betting on a particular piece of infra, especially something as uh fundamental as a blockchain, uh you're effectively betting your whole business on it. Um and that's that's not an easy bet to make.

Yeah, I I think a core point here is like a lot of the times, if you're an application developer um the mo- a lot of your moat is basically the state valuable state that you've built up on a certain chain. And the reason it's a moat is because there's no way to transfer that state, right? Like whether it's liquidity or uh user base, etc. So yeah, wherever you build, you're taking on that platform risk uh because that state is just locked into the substrate that you're building on. Got you. And then maybe Franky, that second question to you of just like, how would you think about, okay, so Ethereum has sort of optimized for being a settlement layer and that means, you know, prioritizing things like

censorship resistance, you know, through their network of home stakers, etc., etc. Are there any benefits to building an L2 on Solana like the one that I, you know, as sort of a layperson just having, you know, like shower thoughts about this basically is just that the the slower block times might make interop in between L2s a little bit easier, at least as like a first-run kind of janky solution. Um but, you know, are there any benefits that you guys see to building on uh on uh Solana or do you think that for the most part into perpetuity, you know, L2s are going to be built on ETH?

Yeah, I think Eugene covered this pretty well. If is if you if you're building an L2, there's a few things that you care about and I think Ethereum so far has really optimized those. Solana so far has optimized for execution and and that works really well, but yeah, if you're building an L2, you care about having, you know, a trust-minimized bridge to Ethereum is quite valuable because gives you access to a lot of liquidity and a user base um that that that is quite valuable. You also care um about yeah, there's some nuance about like what does it mean for an L2 to inherit security from the L1, especially when you get these constructions that use off-chain DA.

But but one property that you really care about is yeah, the censorship resistance of the L1 um because you need to use the the force inclusion mechanism. Um and Ethereum gives you um pretty good assurances in this case. Um so yeah, I think definitely Ethereum has been optimized for the L2 use case. Um guys, talk to me about uh how you're thinking about MEV um from an Atlas perspective. So, I I think a lot of the the the mental framework that people have around MEV is from the Ethereum-based perspective where there's a public mempool and transactions sort of float around for uh 12 seconds or something like that and searchers or integrated searcher builders will

package up a block and then distribute that to whoever has the block monopoly like whichever proposer is is in line to propose the block. In Solana it looks pretty different. There's there's no public mempool transactions just get auto forwarded on to leader and there's sort of continuous block building and it sounds like you know in the L2 space in general it's more along the lines of what the Solana MEV environment looks like in the sense that there's no public mempool and a lot of the challenge from the centralized sequencer you know L2 perspective is just mitigating spam essentially and we kind of saw this with Arbitrum which had a very opinionated design around MEV to begin with where they were just

FIFO and now they've added a sort of time like time boost kind of priority ordering mechanism there. Eugene how are you thinking about this from the Atlas perspective? Yeah I mean I think your description of the current state of the world is is pretty accurate. On layer twos today we mostly see things that look like priority ordering and yeah no public no public mempool. And so you end up with like basically this top of block LVR auction. I don't I don't know there's usually somewhere between like 250 milliseconds and probably like 2 seconds for for the block time and then you have this other stuff that happens at like the

bottom of the block where because you can't really observe the the the state at the time you send the transaction you send these like optimistic transactions which I believe were first seen on Polygon. They're very very prevalent on Solana as well where um basically what you do is you sort of try to reserve the block space and then do the searching totally on chain and then revert if you didn't find a profitable trade. So, um I think like priority, like all these priority mechanisms are kind of like bit for mechanism designers and paper writers, and in practice like do not lead to very good applications. At the very least we haven't seen that so far.

Um for applications that rely on active liquidity, like order books for example, um really you want to roll out the red carpet for the market makers because market makers provide liquidity and they in fact compete to provide the best liquidity, uh which is like tightest liquidity or the deepest liquidity, and if the takers have an advantage over them then or even if they're on like a level playing field, the um the makers are forced to provide wider, and you sort of have this like leakage from the system, which yeah, we can call MEV, um which is like just going to the takers, or in the

case of um a system like uh Solana going to some combination of the takers and the and the validators. And the application would like to internalize that as much as possible. So, for us I think like the the first come first serve model or some like close variant of this makes a little bit more sense where, you know, instead of having your maker orders just sitting around and uh effectively looking like a free option for anyone else to go pick them off. Um the maker's able to like cancel as quickly as they want, and maybe the the the takers um don't don't get the privilege um to to to take as fast as the makers.

That's just like one idea, definitely not something we're um we're we're committed to, but there's this notion of again like designing the applications, uh which is both like our own applications as well as um other teams that are building on on of that list, uh along with the infra itself to create the best overall experience for the users. And we'll figure out things like the value captured later. Uh the most important thing is like the value creation and uh you know, creating these um differentiated experiences and applications for the users. Yeah, Frank, I don't know if you have anything to add there other than, you know, I'd love to get a sense of how you guys think about uh I I I have a feeling I I know um where you guys maybe lean on this this question, but there is a a

question philosophically of who deserves the MEV or or where do you think it's going to end up uh sort of from a pragmatic standpoint. And this has always been a little bit of a challenge from my standpoint on well, I know uh you know, on the Multicoin guys look at MEV as kind of a primary way of value accruing, especially to L1s. Um and now recently there's been kind of a discussion of, "Hey, is it going to end up with um L2s maybe or even apps?" Uh and then I think there is a a pretty broad school of thought which which says actually, "Uh we we should try to minimize MEV where possible, but also to return it to to users, right? The users are the ultimate originators of MEV in the first place. And it feels a little

bit funny to be counting this as revenue when really what where that revenue is coming from is users getting screwed in a sense. And so, I I would even just love to get a sense from from the two of you philosophically, just you know, where do you see who who do you think would like deserve like where the where should the MEV be going? And then based on what's out there in the market today, where do you think it's going to wind up getting routed to? Yeah, I mean, I think if you look at at things from first principles and the thing that you're optimizing for is how do we create the most value and how do we um create the best experience for the user, then it's clear that you need a mechanism to rebate the MEV that users create back to them.

Um and yeah, I think there's like multiple different approaches to this today. Um there's a lot of like application level MEV MEV capture. So, um get the basic idea is like just design your applications in a way that don't look don't leak MEV so that you don't have to rely on on infrastructure level rebates which can sometimes be inefficient basically. It's sort of a a patch over bad application design. Um there's there's a lot of Yeah, on the other hand infrastructure level um mechanisms to try to rebate this MEV.

Obviously like we don't live in a world where every application is thoughtful about this design. So, it's still important that you have a way to to capture it at the infrastructure level. Um but yeah, I think overall you want to create good experiences for users. You can't have them leaking massive amounts of value to this sort of supply chain and that requires both thoughtful application and infrastructure design. And as Eugene was saying, if you're able to sort of co-design both the application and the infrastructure, then you can get with really strong you can achieve really strong levels of redistribution.

I don't have much to add there, Eugene. I saw you nodding or looking up thoughtfully and metaphorically stroking your chin. So, I'm assuming that you agree with you agree with that. agree with what Franky said. I think it was like the question of, you know, who deserves MEV is is is kind of a kind of a loaded question. I think maybe more interesting or easier to answer is like where is it going to go? Which again, I think it's still this very path dependent thing, but ultimately, I think it just ends up accruing to the layer of the stack where um where like you're like you have a defensible position. And so, I think a lot of times like at the infra layer, it's like just not super clear how long-term differentiated

it is. In in many other you know businesses, we talk about like commoditizing your complements and whatnot, and uh sort of you want like the layer above you to be a commodity, the layer below you to be a commodity, and so like all the value sort of goes goes to you. Um I'm not sure if it's going to play out exactly like that in in crypto, but we sort of see this, you know, uh again in sort of like other businesses, we see like bundling and unbundling. In um crypto, we're seeing like aggregation and disaggregation.

Um and I feel like these cycles are just, you know, going to continue. And then the way you actually end up with this very defensible position is if you have like far far far superior products, or if you have uh really really strong network effects. Um but I think like these network effects also look uh like impenetrable moats all the way up until the point where they get busted. So, um yeah, I think it's like very very difficult to predict, like most things about the future.

I agree. It's It's definitely tough, and and I wonder, you know, we saw an early version of a trend that might what might be the beginning of a trend start to play out with, I think, shared sequencers maybe you know, found out that there was a little bit of a challenge between getting originators of user flow or like uh order flow basically to opt into their into their network. I I mean, I could see the same argument actually being made for, you know, generalized order flow auctions as well. It's like, okay, why am I opting into this network if I could just internalize this and return it to my users, especially if it's not a 1 + 1 = 5 situation, and there's not a lot of like DEX to DEX, you know, arbitrage that I can do. You know, why

why would I be opting into this? So, I think that they're um yeah, I think it's We'll see if if up happening at the application layer or the or the uh the infra layer. The other The other thing that I would just add to this as well is um regulation will be a factor here. Um you know, the uh like kind of the early decision and I understand why it happened with MEV boost was, you know, a lot of that MEV was, you know, uh siphoned off and returned to proposers, but yeah, I don't think regulators would look at that system and particularly love it or think that it's uh or think that it's the best best device system in the world. So, I think eventually if the regulators will probably start peeking under the hood and maybe have their own perspective on where it should go and that will

influence things. All right, la- last set of questions for you here and then I know we got to start to wind down. Just look one I'd love to end on this subject of opinionation here and I I think one one of the really interesting things about Atlas and and you and your team, Eugene, is that you guys started as application developers and then built the infra that you wanted to see in the world and this has been a recurring challenge in crypto where there's a chicken and egg problem. Hey, we don't have any apps, so we're going to build infrastructure for the apps, but then the infrastructure is suppo- supposed to support the applications and so there's this chicken and egg problem and like you're one of these emerging entrepreneurs in crypto that actually started with an application, recognized that, you know, the app the infra didn't

exist and are kind of building both at the same time. So, you're definitely chewing glass at the moment. So, th- our props to you, but in addition to, you know, what you've built so far, I understand that there's there is a an intention to actually build more first-party apps. So, could you just walk us through that decision-making process and then, you know, what if anything can you share with us about other first-party apps that you might be interested in developing? Yeah, it's really quite simple. At the time Atlas mainnet launches, it has to ship with um you know, a full suite of financial applications.

And so, the ones where um you know, we we think they're well served by um others building on top of Atlas, then we don't need to build it. And then other ones, yeah, we'll probably just have to build. Um that suite like the bare minimum suite looks something like spot trading, a margin engine, uh and probably some sort of futures trading. Yeah. Um along with obviously a um strong set of assets and and market makers to to make the applications run. Um we have a lot of interesting ideas on the on the spot trading side. Um Also on the margin engine side, I guess.

And uh yeah, we've been chatting with with a bunch of teams uh both like inside the Solana ecosystem and um and from from elsewhere basically on um you know, should should should we do it or or um should we have another team build it? Um I think there like one thing for sure for us is we will be building at least one application on Atlas. Uh I think it's super important to dogfood your own products. I think there's a lot of infra out there um where the infra builders just don't have any empathy for the application developer that's using the infra. It's sort of like if you're building, I don't know, like a social media platform or like a SaaS app

and then, you know, no one on your on your team actually use the products, you're going to have uh very very poor view of what the um the user experience actually looks like. And so I think it's like really important just as a form of dogfooding our own product to build to build something and try to take something to to production along with Atlas. Mhm. And and how do you guys both think about, maybe Frank I'll kick this one to you first, the trade-off of building first-party apps versus third-party? And the trade-off is just a layperson looking at the situation is even if you look at Ethereum versus Solana as a point of comparison, in Ethereum because they have this very push complexity to the edges design philosophy. What it's

encouraged is it's actually sort of helped built like bootstrap community and VC investment because Ethereum does so little and is so non-prescriptive about you know, what should be built on top of it. It's encouraged, you know, this large community of infra builders essentially, right? Which has been kind of nice in a lot of senses. Um maybe the downside of that would be though that there are some critical parts of the infrastructure where uh you know, maybe you don't actually want this to be third party and that could be in Ethereum's case that could be liquid staking or something like that. And so I I would just love to kind of compare and contrast and and get both your guys' senses about, you know, how

you might think about pros and cons of the building first party versus third party apps sort of trade-off and and yeah, how you know, how you might walk through the decision about this should be first party, this should be third party. Yeah, I I would say one one point worth keeping in mind is like this decision is quite different um at the base layer than at the L2 layer because you want different things from from them. So it's important that the base layer uh be neutral and um it's like yeah, it wouldn't make sense for the EF to start building, you know, applications directly. I think for when you're building a layer two um you can be much more opinionated as as Eugene has said. Um so I think

um yeah, basically we're still very early in in I think the crypto story and and the main goal is to like grow the pie. So I don't think there's a lot of like tension between first party apps and third party apps and like the commitment that Atlas is making is like we'll build infrastructure that is specifically tailored for the set of applications and the best way we can do that is by building applications ourselves. There's a certain level of empathy that you just cannot get unless you're sort of in the trenches with the rest of the developers building and pushing the the boundaries of the system that you're on. So, I think yeah, it's it's really valuable to to

have to have the team building applications, and you get a lot of um a lot of benefits from this like co-design of the infrastructure and the application layer. Yeah, the only thing I would add is you still want to make sure that there is room for this ecosystem of third-party applications to breathe and to flourish. Um you know, I think we have plenty of good ideas here at Elusiv Labs, um and a lot of talent as well. Um but we're certainly not going to invent everything useful or frankly anywhere close to everything useful that that ends up on Atlas, and so um want to make sure there's still plenty of space for for others to innovate and um you know, utilize the infrastructure beyond ourselves as

application developers. Awesome. Well, maybe as a way of winding down here, you know, what uh let's let's say that there are some application developers out there on the DeFi side of things that is are listening to this saying, "Hey, this is sounding pretty good. I can try an Oracle. I don't have to worry about my Oracle updates not getting pushed, and uh this this all sounds really interesting." How can they find out more information uh or look to um you know, maybe build on build on Atlas? Yeah, for sure. Um so, our testnet is available today. It's a private developers-only testnet, uh and we're rolling access out relatively slowly just to make sure the system uh stays stable as we scale it up. Um but you can find us at atlas.xyz.

Uh there's an easy way to to contact us, tell us a little bit about yourselves, and sort of what you're looking to build on top of Atlas. Uh we have some uh I'll call it light documentation there as well. Um but yeah, certainly very very keen to speak with uh any developers who are interested in building on top of Atlas, whether or not um you know, they end up committing. We always learn a ton talking to uh other application developers. Awesome. And Frankie, for folks who want Now that you're podcast official, my man. Uh folks want to either follow you on Twitter or find out more about the work you do, what's the best way to do that?

Yeah, I'm Frankie is lost on Twitter. Um and then yeah, as Eugene said, we're very excited for work for folks to build on Atlas. So, if you're interested, reach out to Eugene, reach out to me. We're happy to spend some time uh jamming on on ideas. Awesome. All right, guys. This was a ton of fun. Um congrats again on the launch of uh Atlas. And yeah, guys, we'll have to do this again sometime soon. Thanks for having us, Mike. Thanks Mike. Cheers, guys. Everyone, hope you all enjoyed today's episode. Want to give a final shout-out to Namada. Again, a team that is near and dear to my heart. They are building the shielded asset hub, which is protecting the future multichain. Talked a little bit about how that works in the mid-roll, but for now, what I would highly recommend that

you do is go check them out. They're in their mainnet launch phase. You can follow along with everything at namada.net. You can start rewarding yourself by shielding your actions and strengthening data privacy for all across the multichain. So, thanks again, Namada, for all the great work you do.