Is Blended Execution the Missing Link for dApps? | Dino & Stephy

Everyone, Santi and I have been talking about Solana a lot recently and we're excited to have a Solana sponsor of Empire, Marinade. Marinade is a staking protocol on Solana and the only stake pool that delivers auto-rebalancing, MEV rewards, and automatic downside protection with their new protected staking rewards. Optimize your SOL stake with Marinade by hitting the link in the show notes. Big thanks to Marinade. We'll talk more about them later in the show. This episode is brought to you by Avalanche. Avalanche is a leading network of blockchains giving some of the world's largest financial institutions new use cases and business models while leveraging completely customizable infrastructure. Check them out. It's core.app/discover. You can explore Avalanche's subnet ecosystem at core.app/discover. I was playing around earlier today. Really cool. This episode is brought to you by Mantle. Mantle is an L2 backed by over a $4 billion treasury, obviously one of the largest in the industry. They recently launched their airdrop program called the Rewards Station to distribute both presale token allocations or listed tokens to MNT holders who stake their MNT. Mantle has nailed their rewards program recently. Would highly encourage folks to check out the Mantle Rewards Program at mantle.xyz/rewards-station.

Hi everyone, welcome back to Empire. We have two very special guests, uh, You know, we have Steffi and Dino from Fluent. Dino is the co-founder, CEO. Steffi is the COO. And I think this would be a great episode. We're going to talk about, they just rolled out something really interesting called Blended Execution Environment. But when I first thought about bringing these guys on the pod, first of all, I'm an investor, so full disclosure, obviously biased. But I think, you know, there's been a lot of chatter. Over the last couple years around these different execution environments, different VMs. We've had multiple people on the pod talking about different trade-offs. And when I think of someone who's at a very interesting vantage point that can talk about all the different trade-offs and is, is really Dino. And when I first had a conversation with him last year, I found him to be extremely knowledgeable about just historically what has happened in crypto, someone that has paid a lot of attention you know, at the, you know, first in Ethereum and then start to pay attention in other ecosystems as well. And so I think this episode would be really great to talk about the different execution environments and then ultimately, you know, what Fluent is building and this blended execution environment, which I think is coming at a really interesting time. So welcome both. Excited to have you on.

Thank you. Thank you. Good to be here.

Yeah.

Yeah. So, yeah. So maybe, Dino, Stevie, why don't you get started with intros and then we'll go from there.

Sure.

Yep.

As Santi said, Dino, one of the co-founders of Fluent, and we are building the first blended execution network. And Steph is CEO of— COO of Fluent. Yeah, we'll start with the status quo. I mean, the way we've seen things historically is, you know, these execution environments have been built. And again, this could be like an L1, L2, L3. Any execution environment. The way we've seen them built so far has been in what we'd call the single execution paradigm. And so the way we define single execution networks is a network that has support for apps from one VM target. So very simple, like one VM. This could be the EVM, this could be the SVM, this could be the Move VM. It doesn't really matter, but think of an execution layer that supports one of them. And historically, this has really just been the EVM, right? I mean, over the past few years, there's just been a ton of EVM L2s that have popped up all over the place, but they largely kind of look similar. And what we found is, I mean, this is clearly limiting, right? The EVM has certain technical limitations that people love to point out, and we We certainly have seen those as well. And even on the language side, you can only deploy Solidity smart contracts, Vyper smart contracts, and those two things can natively interoperate, but you can't really benefit from any other libraries in other languages. You can't have smart contracts in any other languages. People are working on changing the EVM to support things like parallelization, but just by default, that has just not been the case. So what have you seen? Over the past year, there'd be especially a lot of excitement around, you can call them alt VMs, you can call them next-gen VMs, but things like the SVM, things like the Move VM have gained a lot of steam and for good reason too, right? People know the SVM for parallelization that obviously supports Rust as a language. And there are also, I mean, that's gotten popular. So there are also not only technical attributes that are interesting, but also I'll say ecosystem or go-to-market attributes that are interesting, just a slew of other tools and things like that. And then the, you know, Move obviously has like formal verification, which is interesting for like security purposes. And so you see more and more of these like VMs popping up. But the problem is that like in a single execution environment, you have to make this trade-off. Like I, as a developer, if I'm a dApp developer, like I'm innovating on some new type of DEX or some new like social fi app or whatever, I have to make the choice. Do I deploy on one of the EVM L2s and get all of the network effects? So it's like, okay, this is great. If I have a problem, I can type it in a ChatGPT, I can copy paste some of the primitives of smart contracts and build upon those, the quicker iteration loop, huge user base, wallet integrations, but I cannot use any of the new functionality of the next-gen VMs that are popping up. So what do I do? Obviously, if I care enough about that functionality, I'm placing a pretty big bet because I have to build something new. And I have to take a bet on this ecosystem and I don't get any of the network effects. I hope they succeed and I hope they get escape velocity. This has clearly been a problem over the past year. What we've seen is the alt VMs become more and more desirable by developers. What do people naturally do? They say, okay, it's not a totally novel idea to be able to say, let me just try to get the best of both worlds. But it's the way that people have approached it so far that we've found suboptimal, or people, in our view, fundamentally are just taking these two different VM or more different VM environments and trying to make them as interoperable as possible. But if you don't architect that from the ground up in a way that actually makes the experience good, it gets clunky and then people don't use it. So I mean, there's been a few different approaches that actually, Steph, maybe you want to talk to, but fundamentally we do see these as like two different environments, two different single execution environments, either being like stacked on top of each other or like put next to each other. There are different approaches, but maybe Steph, you can talk a little bit more to that.

Yeah, sure. So basically these EVM+ networks or any network that tries to combine multiple VM, most of the solutions involve actually having two different like states. So what does that actually mean in practice? It often means that like, let's say it's, it's an SVM network and you want to also support EVM on top of that. So in addition to contracts in Solana Rust, you want to also support contracts in Solidity. What ends up happening is that like you have your SVM down here and you have contracts like Solana contracts here. And then you have like a proxy network, which is the EVM network up here. And so generally what happens is you'll have to have, as a user, you'll somewhat bridge into that network. You'll have a separate wallet, a separate native token. And in effect, although, you know, everything eventually does, you know, make it into the same blocks, like of the overarching network, like the user experience is completely fragmented into two separate state environments. So the network does support multiple VMs, but not in a seamlessly interoperable way. So at Fluent, you know, our, our journey was, okay, we want to support zkWasm. We also want to support the EVM and able to have that, you know, those network effects, bring in like Solana or sorry, Solidity developers and things like this. But we found it to be an unacceptable trade-off that it would effectively be two separate networks. So we thought to look deeper, how can we get both of these networks and put them on a shared state environment such that as a user, I get to use, you know, one native token, one wallet of my choice. And as a developer, I don't have to like think about the additional complexities and, you know, have these two separate environments effectively acting as one. In doing so, we also noticed that in our design, it's actually extensible. So we first started with WASM and EVM, but then we're like, oh, hey, look, we can also add SVM. We can also add MoveVM and effectively have them all live in this one shared state environment. I'll pause there before going too technical, but I think that was what you're getting at.

Yeah.

Well, there's a lot to unpack there, and I want to just double-click on a lot of those features, but just for the general user, I wanna make sure that things are pretty clear here. Like when you just, let's define an execution environment, let's define a virtual machine and then I think I wanna revisit what you just said, Steffi.

Yes, yeah, no, that's a great point. I feel like over time, 'cause the idea of a VM, right, is actually not unique to blockchain. Like it's kind of like this, it's like this virtual environment Thinking of like VMware. Exactly right. When was VMware started? Like 2000 or something like that, right? So it's been around for a while. But I think what's gotten confusing for a lot of people in blockchain is the term VM has kind of been bastardized a little bit. And I think you can probably blame the EVM for this. It's funny because I actually don't hate on the EVM that much because I do see a lot of value in the go-to-market attributes that we were talking about before, right? Just like as a startup person. But that did bastardize the term. So what people do is they kind of conflate two different things together right now. In the space. One is a virtual machine and the other is an execution environment. So really what a virtual machine is, is just kind of like a sandbox to run certain types of binaries, right? It's literally just like— it's like the smaller sandbox and the execution environment is the bigger sandbox. So if you look at most of the— from our view, the interesting areas of innovation are actually in kind of the broader execution environment. When you see People try to, things with account abstraction, if you're trying to add IBC into some type of environment, that doesn't really have to do with the small sandbox where you're putting your Solidity code or whatever code. That's actually in the broader execution environment. So what we're trying to say is, and by the way, another way to think about it is the execution environment is the whole state transition function. That state transition function can actually include other state transition functions such as like different like VMs. And then it also does some types of like protocol checks. Um, and then, you know, in our case, like it gets like kind of ZK proven. So I guess maybe you can think of it as just like a little sandbox inside of a bigger sandbox or something like that. But we do think most of like the interesting area of design is in like the broader execution environment. That's why we don't really look at it as like a blended VM per se. We call— we say blended execution network because it's really about the bigger thing. So hopefully that's helpful, but I can go further.

Yeah, that's really— because I think like the key point, I think, is, and I think you're going to keep hearing it over and over in this episode, is a state transition. Because ultimately, like blockchains are that. Like whenever you're swapping tokens, whenever you're sending stuff, whenever you're doing whatever function that requires, it requires this thing called the state transition. And then that's ultimately recorded in a particular block. And then you need to make sure that that block's actually included, verified, you know, the proper you know, gas and all the other, all of that happens at the execution environment, right? So that's how I think of it.

And I think— Exactly. And the thing is like with what people have, I think, done so far is just kind of called both of those things like the VM. So sometimes when people are talking about a VM, they literally mean just like, you know, the smaller sandbox and sometimes they mean the bigger one, which makes it a little bit confusing. So. Yeah.

Steffi, I want to go back to something you said and also Dino, you alluded to like, There's been a lot of different, I guess, experimentation on execution environments. And I'm curious, like, when you think about the journey of Fluent, like, what inspired— what was the problem that you saw? And just, I want to understand like that journey and then transition into like blended execution environment and what that ultimately solves.

Yeah, I can take this one. So the beginnings of the project were focused on WASM. So the notion of how do we bring traditional programming languages to Ethereum? And that's a major unlock because traditionally there are other execution environments that, or sorry, other networks that do support WASM, but we hadn't seen it yet in the Ethereum ecosystem. And how, why bring this to Ethereum? It's the network effects of Ethereum. As a rollup. And so you get basically the best of both worlds. So that was the initial thought. But as noted, we realized that when you get onto the L2, especially in the state that we're at in the market, people are most familiar with Solidity, with EVM standards, things like this. And so jumping straight to WASM on Ethereum, it could potentially limit us from being able to support all of the people who are already in Web3. We want to also talk to Web3 developers and Web2 developers. So then that became the journey of how do we make this WASM environment also EVM compatible? And so I kind of mentioned it before, there's been a number of attempts in the past and other networks are also doing this, like an LVM plus an EVM, but we just didn't want to sacrifice on user experience in any way. So that became the question of how do we enable WASM contracts in Rust and TypeScript and whatnot, contracts in Solidity, but have those natively talk to each other and have them atomically be able to compose, which there's two benefits to this. Well, actually there's a number of benefits to this, but one, you enable this broader pool of developers being from Web2 and from Web3, but also you're able to make some really interesting applications that you know, not only use just Rust or just TypeScript, but also can like add some crypto-related logic, you know, in Solidity. So you can imagine like trying to make a more performant DEX in Rust or something like that. Um, if it were just, you know, a WASM-based environment and you didn't have any tokens that people are familiar with, like ERC-20s, then, you know, where, where's the financialization in that? But with something like blended execution and everything being in one state shared state machine, you're able to have that DEX, which is performant in Rust, and it can interact with ERC-20 contracts. Seamlessly in a way that doesn't affect the user or developer experience. So that was the first part of the journey was like, how do we mix this Web2, the performance of Web2 things, and then also the financialization of Web3 and crypto and Solidity and bring some of these two worlds together. But then we realized that we didn't want to limit it to just the EVM because our design was extensible and because it was a different way of doing it than other networks had done it before. And hence kind of expanding to this notion of blended execution of different virtual machines or supporting apps from different virtual machines. But I think I'm kind of going a little bit too far here, but blended execution in, in the Fluent context is going to involve WASM, EVM, SVM. But the idea of a blended execution network and using the Fluent-based framework means that a developer could build a rollup that has any kind of mixture of execution or of VM support that they want, right? So it could be, I like things from the MuVM, I like things from SVM, like that's the mix that I want to do. And so we want to encourage experimentation of this idea of bringing different VM targets together, um, whether— whatever combination a developer finds most interesting. So I'm going to pause there, but it really can go beyond what Fluent supports, just being what developers find interesting for their mix of blended execution.

Yeah. Do you know anything to add there?

Yeah, I was just going to add, just kind of like zooming out to more of just like the startup context and kind of why we took the approach that we did. I mean, I think generally it's important to innovate, but at the same time, like meet the market where it is. And so like you see this all across the board, right? Like even dating back to like a Netflix and how they started with just like DVD by mail, but also had an eye towards streaming and kind of built their systems along the way to like introduce it, whether it's on the tech side or on the marketing side towards streaming. And then of course, course, like, they, like, they had an eye towards that. Or I think in the Web3 context, like, I think Forecaster's done a really, really good job with that, where they did start with— they meet— met the market where it is in terms of kind of messaging the product itself around kind of crypto natives. But as you can see, like, now they've architected the system in a way where, like, it is super scalable towards the masses. And, like, we kind of, like, have that same philosophy, and that's why we, we do really want to— and that's, like, where it's more art than science. It's like, how do you meet the market where it is enough, but also design the system to where it's kind of future-proof enough. And so that was always like our design goal. And then obviously blended execution is the way we've executed on it so far. And just to add a little bit more to kind of what Steph said on the why it kind of like matters side, Actually, would it be helpful if we dove into blended execution first, almost defined it or kind of like—

Yeah, why don't we just define it?

Okay. So I would probably say a blended execution network is— it could be a blockchain, so it could be an L1, L2, L3, doesn't matter— that supports native composability between apps from different VM targets. Now, obviously throwing in some technical words there because I wanted to point out that it It's really just to reemphasize that it's not kind of taking a number of VMs and kind of running them in the same place. It's actually like an environment that uses some pretty low-level primitives to support this native composability. So in our case, right, so we're building the first bonded execution network. Hopefully there are many more to come, but what we're focused on is EVM apps, WASM apps, and SVM apps. And the beauty from a developer and user experience is that From a developer perspective, these smart contracts, so the WASM Rust smart contracts can actually call, they could directly talk to the SVM Rust smart contracts, which can directly talk to the Solidity EVM smart contracts. And this creates— and actually, Steph, maybe this is where you can pick up the thread from before and talk a little bit more to the benefits. But I mean, it really does actually unify these different ecosystems and create this diversity of this much more versatile design space for people.

And I guess like, just to make it abundantly clear, like blended VM is different from the notion of multi-VM. Although there is like support for apps from multiple different virtual machines, it's at the end of the day, it's actually just one virtual machine, which is the R-Wall virtual machine, which is used to simulate these different VM targets, right? So I just want to make that very clear, because in other solutions, you're actually like running two, like two, three different state transition functions. But in our solution, it's just one. you know, all under the hood, but that complexity is abstracted away from the developer, as well as the user. So in the end state, what should happen is that a developer will be able to effectively copy and paste some Solidity code. So let's say like any existing app that already exists, you should be able to port it over. And you port, you, in order to call contracts, like, so if it's just like a Solidity-Solidity conversation, you don't have to think about it. But if you are, you know, calling a WASM contract or calling an SVM-based contract, You just have to route through these things that we call the compatibility contracts, which are core system contracts, which enable that communication. But there shouldn't be too much additional overhead for you as a developer. We want to make that as easy as possible. So it's effectively as seamless as possible as deploying an app on a native EVM or a native SVM network. So what are the benefits to that? Effectively, it's twofold. So one was the example that I mentioned before, which was this notion of being able to make really interesting applications that make use of smart contracts that pertain to different VMs generally and be able to mix and match in that way. We're effectively creating like an additional execution point where apps from other ecosystems can come and, you know, just redeploy quite easily. So, you know, why would you want to do that? Well, Fluent is effectively an additional market for you. Like you can have, let's say, Radium on Solana and you can have Radium on Fluent. It's just a copy and paste situation. There's not much overhead. You're able to access, you know, a different pool of users than you might otherwise wouldn't have had, you know, on Solana. And what's great about it is that, like, like Dino mentioned before, right, like you have to convince people to come to your AltVM network. You have to show them why it's valuable. You have to hope that people are going to want to come over, use this new virtual machine and like build network effects from there. But what we're saying is, how about this? We can create an environment in which everybody can come join. And so you benefit from each other's network effects. And so Solana apps, talking to EVM apps, talking to Wasm apps and adding that additional Web2 functionality. And then, you know, the pie can grow from there.

Yeah. In many ways, I want to get into the type of applications that you foresee that would be like huge unlocks, but just putting it more concretely for people to visualize. So like you're saying, you know, if there's a DEX in Solana and a DEX in Ethereum, it's going to be extremely easy to just copy paste into the Fluent environment, like the user would much rather go directly to Fluent than trying to, you know, bridge and interact with all these different other, you know, just hop across networks.

So yes, I think you can look at it from like the developer benefits and then the user benefits, and obviously they like intertwine in places. So like a developer benefit is kind of, as Steph was saying, like kind of a greater access to more types of apps and liquidity that wouldn't exist elsewhere. Because if you put yourself in the shoes of a developer, right? If you're going to deploy in some purely AltVM context, well, that ecosystem is being built from scratch. But also if you were going to deploy, even if it was a Solidity contract, right? And you were going to deploy it in one of the hundreds of EVM-only L2s, well, you're never going to get that emergent effect of your app being composed with these, the 10 best SVM apps and the 10 best WASM apps and stuff like that. And so there's somewhat of, I think people can intuit that that's useful because it's like, okay, there's new experiences that can compose with each other. And then there's just more of an emergent effect that I think it compounds over time. And then from a user's perspective, you could also think of a base case as I am an EVM wallet user and I want to just use— I don't want to change wallets. I just want to use all the good apps and not really have to think much about it. There are plenty of Solana apps that I would love to use, but I don't want to change a bunch of things. I just want to use them. So that's kind of like the way I look at developer and user experiences. Hopefully that's Helpful.

Yeah, definitely. So you announced this, uh, I think it was a couple weeks ago, right? What kind of reception have you been getting from developers in particular? Uh, what kind of apps have been most interested? Or is it existing apps? Is it just people that have said, oh wow, like, you know, you're really abstracting all the complexity. I really have thought about this particular app but haven't been able to really build it because of, you know, this fragmentation that currently exists. I'm curious, like, what kind of reception you're getting.

So, well, I, I think we've been pleasantly surprised so far with, um, the, the reception to the value prop that I just mentioned from developers. Like, it's really— I, I think, like, the base case is, is kind of that straightforward of, like, okay, well, look, we, we have a multi-chain strategy. I mean, usually it's— so far it's been a lot of people we've talked to who are already kind of, like, deploying on different rollups, and it's like, okay, well, Fluent gives me access to, like, a market of things. And there are some existing things, like people— and keep in mind, like, we're still in private devnet, so like, it's not like, you know, we're still kind of like building, building the ecosystem. But as far as kind of like the reception that we've gotten so far, it's, oh wow, like, so there's going to be SVM apps and WASM VM apps that, um, that deploy there. So like, yes, it— like Steph said, it's an extra execution point, and usually that's kind of enough for somebody who already has like a multi-chain strategy. They kind of get it. And then I think for some brand new, and that's for the most part been kind of like DeFi so far. And then I think if you look around to some of the conversations we're having with new app experiences, I think that there's certainly a lot of social and gaming use cases that lend pretty well towards WebAssembly. And I think, so it depends how far you want to go with that because if if you step even further and say, okay, well, there's the Solidity apps and the value prop for them. There's kind of like the WASM or kind of more like social consumery apps and the value prop for them. Now you can actually go a step further and say, all right, there's this notion of blended apps, right? So where the app itself is actually composed of smart contracts from these different VM environments. And that's where I think that things could get pretty interesting. And we're actually just experimenting with that ourselves. And we actually— our dev roles just spun up a couple of games that we'll hopefully demonstrate in the next week. Kind of like a chess game is the first one where you could actually see the different parts of— as somebody's using this game, what's actually happening under the covers is a Rust smart contract is talking directly to a Solidity smart contract. And I think we're in the early innings again, but getting the juices flowing as to what can be built in that environment. I mean, so far, And this was kind of evident in just the WASM-only world that we were in before. But I think that there's some cool stuff that fits into, I'll say, the autonomous world type way of thinking where, all right, I'm a developer and I can just focus on— let's just say I only know Solidity. And so I could just focus on building a primitive towards a game or a world or whatever experience in Solidity, deploying it on Fluent. And then maybe I don't build anything else, but I know that now the market, the audience of people who can built on top of my low-level primitive. And let's just say in this case, the games that can be built in parallel using that primitive now goes from Solidity developers to any developers who care for any of these different ecosystems can all compose on my primitive. It's just a very exciting notion.

Yeah. I want to at some point get into these compatibility contracts you mentioned because composability is something that is talked about a lot, but I think is not properly understood or doesn't have the right nuance to it. Because composability started to like, oh, you remember the time of like DevCon in Osaka? Was it Osaka? Everyone's like, oh, things are going to break. We're going to go on L2 and composability. But I'm like, my Thought then and still is, is like the internet had this problem too. And so ultimately you had to just build better like middleware, so to speak, like better like connective tissue between these different ecosystems and standards. And oftentimes like when I talk to teams, like whether it's a new L2 or, you know, a new, you know, network, like a movement-based language like Chain or, you know, Near or something like that, it's like, the tooling is not there and it makes it very hard for developers. And I think like in Ethereum, like this was like the appeal to like, you know, for WASM, right? It's just like bringing just a whole wider range of developers. But I, I'm curious, like if we can go into these compatibility contracts, which I think are like pretty fascinating, which are powering all this, like, you know, connectivity, right? So to speak.

Yeah. I can take that one. Effectively, like the compatibility contracts are what enable you to speak to different contracts pertaining to different VM targets. So the alternative approach to that, like, what is composability or interoperability? But like, generally speaking, if you were going to be like an EVM app or Solidity app, or you're a user of one and you want to then, you know, move over and do something on Solana world, like you have to use a bridge, you have to move over and like that adds an additional trust assumption. You, you know, you can't, it's, it's not atomic, you're going to have to wait a couple blocks, like there's a little bit of like a delay. And that's just kind of the status quo for compatibility between different networks at this point. Um, but the compatibility contracts—

on that point, like, there's a lot of interoperability today with chains. You are taking some trust and lag and delay assumptions, right? Because you have to, your point. So there's a lot of interoperability, but not like composability is like a top— like, well, when I think of composability, it's like, yeah, it's atomic or near atomic or whatever trade-off. If it's DeFi or gaming, well, maybe it's composable, but you know, In one, you're willing to accept a certain degree of latency, cuz otherwise there's a lot of MEV out. But there's like two really important points that I just heard, like interoperability and composability, two different things. Right.

Good point. I guess like, you know what, that's a fair point. Like I guess I, in my mental model, I never saw composability as 100% pertaining to atomic composability. Like I feel sometimes those words kind of get like traded around. And so when I say composability, I guess I mean it in like the broadest possible sense that you're able to talk from one contract or one network to another. But I will then dial in more that like these compatibility contracts enable atomic and real-time composability just for sake of doubt. Just because I wasn't—

Just you, because in my mind, no one's been able to do that. Correct me if I'm wrong, but that's the key novelty here because there's people might be comparing it to bridges and again, interoperability, but not atomic composability at the smart contract layer like that. This, in my mind, that's, that's the key hallmark. Like that's the key innovation here that I, I think is so, so awesome.

Totally. And so, yeah, like how in, in the world we're in right now, right? Where you have like, you know, various disparate rollups, you're thinking about how do we maintain interoperability? How do we try to achieve atomic composability? And there's like a number of different ways that's being done, like via shared sequencers. Or, you know, via, you know, ZKC transition-proof bridges, I think is the closest you can get. But at the end of the day, like you are trying to kind of fit things together that are from different environments. Right. And so the difference with, with what we're doing at Fluent is we are the same environment. So it's just, I want to reiterate and make very clear that it's not two different VMs talking to each other. We're not enabling composability between two different VMs, but it's like the one larger Fluent VM, which is able to simulate these VM targets on top of it. And hence the atomic composability happens all like on that same state at the RWASM level. So the compatibility contracts are effectively a way to route transactions between the different types of contracts on the network, but everything is then compiled down to RWASM where the composability actually takes place. So you're not, you're effectively not doing interop between different networks, different state machines. It's all one state machine and hence it's atomic and synchronously. Composable.

There's one thing I want to actually just build on from what Steph was talking about, which is just generally how we see kind of these execution environments shaping up, right? We're talking about composability, we're talking about interoperability. And I just want to make one thing pretty clear. Our thesis is not that there should just be kind of a consolidation back to one big fat L2, right? We're not trying to eat everybody's lunch. Realistically, we're not even trying to support all the VM targets on our L2. It's hard to do, right? There's a lot of different coordination things under the hood. And so right now we are really just focused on those 3 app and VM environments. But regardless, how we see the future of these execution environments is really more that blended execution is just a better way to create them. And so if you're somebody who envisions a million different execution environments, a million different L2s, L3s, whatever. I mean, we would just definitely prefer those to be kind of like bundled execution networks instead of single execution networks. And you can hyper-customize them for whatever you want, right? Because there's still a million reasons why you might want to build your own separate state machine from the other state machines, right? Like privacy. There's kind of like enterprise use cases. There's even just like monetary, like incentive use cases, maybe like value capture and stuff like that. That's all real and that's still going to require like really tightened interop solutions between even blended execution networks. So it all does kind of, um, like I think it fits very well personally into like the modular thesis. So I just wanted to like, um, clarify that really quick.

No, that's such a good point. Um, so when you think about like the, I guess on the modularity point, like we are seeing an explosion of, as you pointed out, multiple you know, L2s, L3s. We're seeing some like movement, you know, Move-based L2. You have the multiple SVM implementations. You have like Aurora. I'm curious, like, how you think about, like, now that you've introduced this blended execution environment, how do you see them existing with, like, in a blended execution environment? Like, what is their place in the world now that we have blended execution? How do you envision this kind of your place in the ecosystem and also what it actually means for the rest of the kind of the different execution environments?

Yeah, I think kind of touching on it before and what Dino said, like, we're not here to steal anybody's lunch. And there is obviously benefits to having a state machine that is customized to exactly what you want. So, there could be, there's certainly a world in which you just want an EBML2, because that's the flavor of products that you want to offer to the world. So in our mind, we're just kind of working on really innovating at the execution layer. So if developers want to, if you want to come into the Fluent L2, you'll benefit from all of the different VMs that the network supports, but also you can innovate even farther. Like Dino said, you can support, we can enable support for different VMs. Maybe you want to have Fuel VM plus EVM, and that could be some kind of interesting combination for you. Maybe it's Wasm and Fuel, or just being able to mix and match in multiple different ways. But we fundamentally don't see it as taking value away from these single execution networks that can also still live in harmony and offer their unique value props to their users as well. At the end of the day, we fundamentally don't believe that there's going to be one state machine to rule them all. There's no way we're going to get the entire world's traffic on just one giant L2 or one giant L1. So we're just offering a different way to innovate at the execution layer, but certainly not at the expense of all the great things that these other networks offer.

And by the way, just to add on that, like, even though we've talked a lot about the technical innovations and differentiation, like, I, I, even as somebody building like this fund execution thing, like, I, I see that as only part of the, the puzzle. Like, you can innovate in other ways, right? That you can innovate in so many— even if you are a single execution network, right? Like, you can do perfectly fine innovating on, um, you know, different, different mechanics, like maybe governance, maybe like incentivization. You can kind of bundle things and unbundle things. Something can go with kind of like some apps baked into the precompiles or some type of precompiles that make ML easier on their thing. It really doesn't. So maybe I'm just a hyper bull on how many of these separate state machines people will actually need. But this is just, I think, a really innovative way to kind of architect it on the on the technical side of it, but there's just like way more to the puzzle.

Everyone, Santi and I have been talking about Solana a lot recently and we're excited to have a Solana sponsor of Empire. Marinade is a staking protocol in Solana. I remember when they launched, I think it was back at a Solana hackathon and they were funded with this $80K grant. It's super cool to see how far they've come. They're the only stake pool today that delivers auto rebalancing, MEV rewards, and automatic downside protection with their new protected staking rewards. You can stake natively or liquid stake with Marinade and get the same high-performance delegation strategy that thousands are using already to stake your SOL to over 100 of the best Solana validators. Marinade has been live for over 2 years and they have audits completed by 4 of the top security firms in crypto. The delegation strategy is a first of its kind, so So if you're staking your Solana, if you want to start staking your Solana, if you want to get some yield from your SOL, start staking today with Marinade. Go hit the link in the show notes. Big thanks to Marinade for everything that they've done in Solana staking land. Go check them out. Go stake your Solana with Marinade today. This episode is brought to you by Avalanche. Avalanche is a leading network of blockchains giving some of the world's largest financial institutions the design space to explore new use cases and business models while leveraging completely customizable infrastructure. Everything that Avalanche has been building the last few years has culminated in this moment where today you have institutions and developers able to essentially have limitless possibilities with the chain. They've enabled developers to build cross-chain swaps or create gaming environments where one subnet can unlock features in another or can use USDC as a native gas token. Onyx, for example, by JPMorgan or Citi or DTCC's Digital Asset Assets, or, uh, the Australian New Zealand Banking Group. They're all building on Avalanche Evergreen subnets. Really cool stuff. Big thanks to Avalanche for sponsoring this episode of Empire. Go explore Avalanche subnet ecosystem at core.app/discover. That's core, C-O-R-E,.app/discover. Thanks again, Avalanche. This episode is brought to you by Mantle. Mantle is an L2 backed by one of the industry's largest treasuries. At the time of recording, it's valued at $4.4 billion. The Mantle ecosystem engages in a lot of early-stage exciting projects such as Athena and EigenLayer, and they give out actually the rewards to the Mantle community. There are two airdrops I want to tell you about. The first one, it was with Athena. They offered 2.5 billion Athena shards to holders of their native token MNT. So the reward station program distributes these presale token allocations to MNT holders. Who stake the tokens. The second one they have going on is with MISO, M-I-S-O. That gives out over 90,000 MISO tokens worth about $50,000 today. That starts on April 25th, runs through May 2nd. If you want to check that out, you got to stake your MNT and you can check out the reward station at mantle.xyz/rewardstation. Big thanks to Mantle for sponsoring Empire.

I'm curious, like, What would a skeptic say to blended execution environment? Like what have been the criticisms that you've heard or what are some of the things internally that you just don't know if they're going to shape? Like a big hypothesis is just this convenience factor, but maybe there's a type of developer that says, listen, I hear you, but I'm building for long-term and I just have this idea that the SVM is the winning strategy or Move is where DeFi is going to live. I don't want, I don't care, like fine, blended is cool and whatnot, but I'm just going to double down, just go direct. Like I could see someone saying that, but I'm curious, like if you've heard it and what would be the counter argument or the, you know, response to that?

Yeah, I, I guess to answer that is in effect that like, because the experience is going to be so, so let's say like you're, you're Solana bull and like, you, you know, you just wanna do SVM, like you're not, you don't wanna think about anything else. Right. So like you've deployed your app on Solana and like, that's it. But we're, we're not suggesting that you undeploy or like stop focusing on your app on Solana. Like we're just suggesting like, hey, like. Look over here, look at all the EVM networks there are. If I'm a DEX on Ethereum, I can just as easily copy and paste my code and become a DEX on Arbitrum, on Optimism, on Fantom, et cetera. There's a lot of different markets that you can attain, and a lot of these different VMs, specifically the SVM, haven't really had that opportunity yet. Right. So we're not looking at it as a way— we're not taking away from your business in the Solana ecosystem. We're just providing an additional market. So that's how we would answer not detracting to your commitment to the Solana ecosystem. But in terms of some of the challenges, like you noted, some of the more complexities, something that we are working on in the background is how do you really handle multiple different token standards on a network, right? Because you're going to have ERC-20, you're going to have SPL. How do those interoperate properly? You want to enable support that a user doesn't they want to have the choice, like, do I want to use MetaMask or do I want to use Fantom? How do you enable Fantom to be able to support or interact with ERC-20 tokens? So that's something that we're working on in the background. It's going to be abstracted, but there is a number of different methods of which we're exploring to do so. But that is certainly one of the biggest complications is how do you support all of these different token standards and things not get too messy?

I'm just going to add a little bit onto that. I mean, there's always trade-offs, right? There's always going to be some trade-offs. And if, for example, We are optimizing a lot of this to be around— actually, sorry, what we've talked about is apps from these different VM targets and the way they work together. But we're also optimizing kind of like more of the execution environment to fit with kind of like the EVM-compatible realm. Right. And as Steph kind of pointed to before, somebody might prefer something optimized around kind of like the Move ecosystem in terms of infrastructure and tooling and stuff like that. And that's perfectly fine. And I think we're going to naturally see kind of like just different communities and pockets, like, for these different ecosystems. Some people just might like the fact, you know, you, you'll have— I have to— you're gonna have people who love, um, you know, the fact that, like, even the fact that Solana is, like, monolithic, and, like, they want that, like, hyper, you know, low-latency environment, and that's perfectly fine. But there's going to be other people who just, like, want to innovate on, like, an SVM app that's really badass, and they just want to take kind of that as a core primitive and kind of build their own thing. And I think the fact that you have such an open industry that you can just kind of remix everything all around, I think as we develop, as we onboard, not the 20,000 developers that are here today, but just millions of developers, I think you're going to see an explosion of all these things. But at the same time, there are just to kind of zoom in on our environment. What would a skeptic say? Almost like technically there's the token standard stuff that Steph mentioned.

Gas? Like, how do you, like, think about interacting in two different environments that might have different gas requirements when you're at the UX level, when you're presenting to the user? Is that even a thing?

I think with gas, like, you know, obviously we're— our gas is in, in ETH. Like, we're paying— like, our L2 is, like, paying in ETH. But, like, the fact that we're, um, EVM compatible too, like, we can, we can do a bunch of account abstraction stuff and enable tokens and, like, you know, whatever type of token. So, like, we don't have that enabled yet, but I think that That becomes a very easily solvable problem over time. But also just to go with the more fundamental trade-offs, right? Because I want to acknowledge there are of course trade-offs. And so even at— and we haven't actually just done this yet or even decided what we want to do here, but there's kind of the base layer environment, which we mentioned before is called Reduced WebAssembly, that just kind of makes it all work under the hood. Now, if we parallelize that, then we get the parallelization benefits of the SVM apps. If we don't parallelize that, we don't get any of the parallelization benefits of the SVM app. So think about it. If we decided to do kind of one thing, I mean, maybe there you say, okay, why would you not parallelize it? And so maybe that's a silly example. But the point is the design space for this stuff is so big that there's always going to be trade-offs. And somebody else might focus more intensely on the parallelization part and they support Move apps and SVM apps and maybe people like that environment as well for different cases. Maybe that's where more of the high security needs stuff lives or whatever. I think you're going to see so many different combinations. And again, this all goes back to what you're saying about the execution environment versus the VM itself. The execution environment is just this very big design space. And I think we're going to— I mean, we're still at the end of the day just exploring a part of it.

Yeah. Do you foresee some hardening of particular standards or blended execution environments where, you know, right now you're kind of opening the doors and saying, come, you know, there's these 3 that you mentioned, presumably there could be more. Um, do you foresee kind of a hardening of like just people gravitating towards SVM and Move or, uh, something like that, like over time?

I think it's more so the notion of, like you mentioned, the composability or like the atomic real-time composability. Because I think that like the solutions up until this point that were, you know, as mentioned before, like, you know, the different state environments on the same network, like that was always kind of like an unspoken thing. Like you'd have to be like a researcher or like a, you know, a very like intent user of a network to understand that like this is actually what's going on because like when it's announced, it's just like, oh, support for multiple VMs and you don't understand the trade-off space there. And then when you get into it and you dig into it, you realize Oh, I need to use a totally different wallet and a totally different token to interact with this app from a different VM that's apparently on this multi-VM environment. Okay. Well, why don't I just go and like, you know, bridge to real Solana? You know what I'm saying? Like, it's just like that, I think is more so where we're going to see hardening in that people are like, oh, hey, like we don't want to, we don't like, we don't want to have that trade-off on our network anymore or on a network that we're trying to create. Like we want to create this really interesting new LVM that has properties X, Y, and Z. We also want to make it EVM compatible, but we don't want to like have this like composability trade-off. So that's where I think the hardening is going to take place where people are now aware of this issue and they realize there's a different way to try to architect it to like keep everything together. Yeah.

So I was just on the phone yesterday with an app that's had decent success, pretty good success actually in Blast. And they were like, hey, where should we go next? Because if we're not in another chain, someone else is going to copy us. Someone else is going to be there. And we have the opportunity to go elsewhere. And it was fairly easy to talk about other L2s that they would deploy, but then the issue of Solana came up and they're like, oh, we're going to have to hire. And it just, it's much harder for them. Presumably with this, it would be easier for them to explore that implementation much, much faster. What would that actually look like for a project that is in Ethereum and says, hey, listen, I want to deploy Solana, what would that look like in a blended execution, like for them?

Well, I guess if I understand your question correctly, I think that it wouldn't actually look much different than like, so like Blast, right? So it's like an EVM network. So it's like, you know, you have your Solidity smart contracts and in the same way that you could then go and deploy that on Phantom or on Arbitrum or on Optimism, you can go and deploy that contract on Fluent, just like same look and feel as any other EVM-compatible network. You're not getting access immediately to all of Solana's users per se, because that's an entirely different network. But if you were to do so on Fluent, you'd be gaining access to the Solana developers and their network effects and their users that decided to come over and also use Fluent or other people who came across that.

Through an STM, like Eclipse or—

So, so you wouldn't have to, um, like modify the, like, if you wanted, if you wanted to go to Solana, like Solana itself, you'd have to go and like modify, you know, your contracts, like build them in Solana Rust or do all that all over again.

That's still gonna be this, that's still gonna be the case, right? If you still wanna go direct to Solana, you're gonna have to, but in, if you wanna, as a hybrid step to test it, you know, a lot of these are startups, you know, have limited resources. This might be a great intermediate step to just kind of test the waters and just get a good feeling of, you know, through, you know, Fluent and ultimately an SVM environment.

Well, sort of, but at the end of the day, right? Like you, in your mind, like as a developer, like you're still only interacting with the EVM environment. It would be that the users of the SVM environment or, you know, of Fluent, which encompasses like SVM, EVM, WASM, are easily able to also interact with your app just as easily as they're able to interact with the SVM-based apps is what it is. So it's like, you're not, um, it like, in your view, like it's still an EVM app, if that makes sense.

Yeah. Yeah. Yeah. Yeah. I guess like we, we haven't touched on the user side of things a lot. We've talked a lot about from a developer standpoint, but like my theory is ultimately users will have no chain, like affiliation, like, or brand. Like we're currently in an environment where like we're, we're very attached to, oh, you know, I'm Ethereum aligned or like, I love Solana, but Mainstream doesn't look like that. I feel like mainstream looks like a user wants to swap a token because they heard it from a celebrity on Twitter or whatever, and they want to get access to that. They don't want to think about whether they need to go to the standard, the type of wallet, like they just want to— it's very action-oriented and it's not— there's no affiliation to a particular chain. So this abstraction is a, you know, multiple— as you alluded to, there's different ways to abstract the complexity of interacting with these in a Web3 context. You guys are doing it in a very seamless way for developers, but also I think that has very meaningful benefits for users. Do you foresee an environment where, I appreciate you're not like eating other people's lunch, but like where the primary landing spot for users just becomes Fluent because that's where a lot of like, ultimately that's like the most convenient way to get access to this world?

I see what you're saying. I think that, you know, as it stands right now, right, you want to go trade like a Solana shitcoin, like you're going to go straight to Solana. Like that's just like what it's going to be, right? Like that's where it is.

It's going to be the case.

Yeah, like that's what it is. I would say maybe not always the case, but like, you know, certainly right now. And I think I saw a tweet the other day, like talking about like escape velocity and network effects and things like this. And like noting how like in the traditional world, like I'm blanking on exactly the numbers, but that traditional apps don't gain kind of escape velocity until they hit a certain number of users in the upwards of hundreds of millions. And we don't have anywhere near those numbers of users in any of the ecosystems at all in crypto. So from my perspective, I think the state of things now is going to be very different than the state of things in 10 years. So it's like through various different forms of abstraction. So whether that be chain abstraction between rollups, whether that be blended execution networks, it would be really amazing if there was just a couple very easy-to-use UIs with different trade-offs. And in the same way that a user can choose a couple different apps for the same job, let's say their banking app or their— sorry, real-world apps, not crypto apps. I just think that we're so far out from knowing which networks are going to rule them all. And at this point in time, it's clearly Ethereum and like EVM stuff and like then additionally Solana, like those are the two winners. But I think that the end state will be much different and it'll be the networks that innovate and provide like the best experience to users that will ultimately prevail. And so with something like blended execution, right? Like you're just offering so much more than what is traditionally available in like a single state machine. And so I think it puts us in the running of like having blended execution networks, like be something special that has a lot more accessibility to users than just going to a single network. And so, yeah, you can, you know, trade in the, in the, the shitcoin casino over here.

And you're not pretending to compete against that. It's, it's more like that type of apps are going to be possible where you have this, like, you know, greater preference, both of a developer, mostly the developer side where you're like, you can pick and choose a different type of, you know, execution. And, and I guess the bet is developers would most— would rather just build using your standard in a blended execution environment. So more interesting apps ultimately get built there that attracts more users, and then that really kickstarts the flywheel. But it's, it's that bet around like— your point is a really good one, which is historically it's just been thinking about execution environments in a very kind of narrow way, and you're really expanding the possibilities. Of saying, no, no, wait a minute. We're just going to allow you to like pick and choose. You focus on building the best app and then whatever under the hood is required to power that gaming, DeFi, social fi, whatever it is. You'd rather be in a blended execution environment for most cases. Maybe there's some ones that, you know, that it unlocks a lot of this and catalyzes a lot of innovation.

Totally. And like 100%, I agree with that. And you know, I think that there's a lot of, we're yet to see a lot of these new interesting apps that like really do blend like contracts from different languages. So like, you know, performant, like I think I mentioned before, like really performant DEX, like written in Rust that like is still interacting with ERC-20 tokens and like things like that. Like there's also like, if you want to go like crazy on the WASM thing, there's this notion that once we enable TypeScript, you could have like verifiable front ends and verifiable back ends. In addition to verifiable backends just being a traditional dApp and things like this. And as a user, when I'm navigating through the world, I'm trading over here in the casino and then I want to go and I don't know, I want to just interact with another app that I'm trying to think of a good example, but I'm blanking here. But my SocialFi app or something like that, I can easily like, just like, you know, in one, in one movement, in one transaction, I can like pull out of the casino and I can go over there and then just start interacting over here. And I don't have to like think about different networks and think about like different ways of getting there. And it's just like all happens seamlessly under the hood for like a variety of different use cases.

Yeah.

Yeah. Like SocialFi is a good example. And Dina, we were just talking about like, I think ultimately the bet here is that most developers would favor a blended execution environment for its flexibility and convenience. And so that really catalyzes. A whole new set of applications that maybe we haven't seen before. And that ultimately translates over, like it starts with a developer and the developer favoring for most cases, maybe not enterprise, maybe not DeFi, whatever, but some certain very, but for the most part, like a Pareto here, like you would rather go in a blended execution environment, assuming that you have some Lindy on these like compatibility contracts, like nothing's breaking there. There's no like, But if that really works, then I'm not a developer, but like I talk to developers all the time. Like I would see them be very interested in deploying in, in using your standards and like ultimately maybe deploying in your L2 and that like having a, being a very, a big catalyst to like unlock this innovation that we just haven't seen before because, you know, there's, there's been like limitations and, and big trade-offs at the, you know, But like SocialFi, what I was trying to say is SocialFi is a good example because you have 3 different like SocialFi apps that are gaining some decent traction. They're all in 3 different chains and there's like issues around hopping around. And maybe if it were to happen in a blended execution environment, it might be just easier for the user to just think about interacting with those 3 different apps without having thinking about like just the UX limitations, complexity, so to speak.

I don't know.

Yeah, totally. I mean, I think whether, um, you can kind of also separate the notion of like Fluent L2, our implementation of this blended execution network, from even like the kind of app-specific blended execution networks that we, we do hope kind of like emerge, right? Like let's just say you want to hyper-customize an execution environment around social stuff and, you know, you, you start off by like deploying those 3 applications end up deploying and then that kind of becomes a very heavy kind of a social chain or something like this. Or maybe like I said before, there's new developers who want to take those as primitives and kind of remix them but all remix them in kind of one environment. So I think what we start to see as we veer away to your, as you kind of said before, veer away from these very kind of tribal, like in the weeds kind of like crypto natives, which we obviously are them and love them. But like when you reach mainstream adoption, you just get, you know, people just want to use like the best tools for the job, build the most efficient kind of apps for, for their use case. And I just think that like blend execution networks, like as a concept, are just like present like a much better playground for these developers to build. And honestly, if it follows, I think the bet, like one part of the bet is also that the paradigm for building things in Web3 starts to look more like the paradigm for building things in Web2. Because if you think of Web2, right, people do just reach for the best tools for each part of the thing. And so you could see, think about— here's two different examples. Think about in the AI space, right? What are AI models? They're kind of like Python wrappers around C++ libraries and stuff like that, right? So technically, there's different tools that are being used for these different pieces of that app effectively. And you're not going to do that on two different networks. You're going to do that on one shared state environment. It just otherwise wouldn't make sense. And even if you look at other examples, right? Think about, I like to use Figma and I've been using that since we were talking about Wasm specifically where Figma came along and said, hey, it wouldn't make practical sense for me to build this whole thing in JavaScript in the browser. So instead we're going to use Wasm as this base and build part of the app in JavaScript because JavaScript is good for more of the UI elements and you can manipulate things better on the screen. But then also use Rust or C for the more compute-intensive parts. And just that creates those things together, have these emergent benefits, I think, of creating a really amazing, highly optimized experience. So I think a bet is also, another part of the bet is that people generally just want to build that way. And if it's— and because that is, that does represent how kind of like the masses of developers do build.

Yeah, I think you're already seeing it now. I mean, I think the best builders, founders in the space really go where the users are and they're very practical. Like this idea of alignment and tribalism, look, is important, but ultimately you care about delivering the best user experience and going where the users are. And so And that's in flux very much so. Like 6 months ago, we don't be talking about Solana. And now Solana, there are days where it eclipses Ethereum and on liquidity and user side. And there might be Telegram might come along and just totally swoop and surpass. And so I think we're in a very interesting time of the crypto, the evolution of the industry where the last better part of a decade or plus has been just building infrastructure. But I would characterize it as like very primitive fundamental building blocks. You guys, I think, are coming at the right time with like really interesting middleware and like tooling. I would describe it to just facilitate like Joe Lubin, like again, like in his keynote speech at DEF CON in Osaka was like, let's bring a million developers. Well, if we're going to— most of the developers I talk to are like, well, the tooling is still not there. Or it's really hard to, you know, and so I think like you guys are really a step in that direction to have this huge unlock that ultimately just makes it extremely easy for developers to just focus on building the app and less so thinking about all the other components and having to learn a lot of things that they shouldn't, right? They should just focus on the app and not have to think about all the kind of limitations or trade-offs. There will always be some trade— like, it's, it's, it's like a utopia to be in a place where like there's no trade-offs. But still, you know, I think this is a huge improvement in that direction.

Yeah, no, that's, uh, certainly, certainly agree. And I think that like we, we do encourage like even more kind of blended execution networks to just push the boundaries as well and, and just like run those experiments and optimize for like different things. Basically just like use the versatility of the design to just like try to make the best possible user experience and developer experiences for, for different cases.

Yeah. Um, let's talk about the, like, the roadmap from here. You've announced it, um, you know, you've gained traction, attention. What does the path to like mainnet look like and what are kind of the things you need that you're going to be most focused on?

Uh, sure. Actually, Steph, you want to take this one?

Yeah. I was just going to say—

You don't have to give concrete timelines or dates because I know your engineers might kill you for it. So I'll save you that.

Yeah. I'll just let you know where we're at and where we're headed. Right now we're in a private DevNet stage and we'll soon be entering a public DevNet stage. And their most recent version of DevNet does enable composability between Rust and EVM-based And so that's quite new. Our previous devnet was only, you could deploy apps in Solidity and Vyper and deploy apps in Rust, but they weren't able to talk to each other quite yet. So that is a recent development that will be coming soon for people to play with. And as Dino mentioned, we have our sample chess game and we're gonna have a bunch of other sample apps and developer guides to be able to explain how those interactions work and what minor modifications you might need to do when talking to the compatibility contracts. And then we're targeting a public testnet within 2024 and mainnet sometime thereafter moving into 2025. That is our roadmap for the moment.

That's great. Well, I know we've covered a lot, guys. Anything else that we haven't touched on that you guys want to double-click on or just talk about?

I'm good. I think we did actually cover quite a lot. I appreciate it. Sorry if this steered on the technical side of the course. No, I actually like it.

I mean, it's quite early, but I could keep asking you questions around the type of applications that we're going to see, but this is part of the beauty of it, that it's hard to conceptualize. Like, you know, like when the smartphone came out, like no one really kind of understood that we were going to have Uber, you know, but you just had a feeling that it was going to be like a thing that was going to connect us and make it easier for us to— but you didn't have really good internet, yada yada. Anyways. It's really hard to predict, I think, these type of consumer applications. And Chris Dixon talks about like skeuomorphic concepts, which is like, you know, things that exist in Web2 and we're trying to copy in Web3. I'm more interested in kind of the new primitives, like flash loans and stuff like that. And I have a feeling this is going to allow like an unlock, like pretty interesting stuff. I just, I just can't put a pin on it. And, and I don't, that sounds like you guys are just like this, you know, it's hard though. But maybe we should have you guys on later this year or early next year to see, because I'd be really interested in the type of like what developers are like mashing and like mixing and the type of applications that are going to come out of this. Because I think that's going to be pretty exciting.

What they're blending. Yeah, what happens.

They're not cooking, they're blending.

They're blending. Exactly. So no, we'd love to. And we're, you know, I think you stated it pretty well. Like, I mean, it's early and like we also kind of have kind of good intuition around this and we're starting to see the excitement that I feel like is a good leading indicator. But we'd love to hop back on as we kind of, you know, transition towards like public testnet and we see things being built. Absolutely.

For developers and just people that are interested in learning more, like What is the best way? Is it your Discord, Twitter? Like, what would be the best way for a developer to get their hands on this?

Totally. So yeah, I mean, you could check it, you could follow us @fluentxyz on Twitter, hop in our Discord as well. That's accessible on our website fluentlabs.xyz. And honestly, just like you could ping me, Steph, ping anybody on the team. We're like super accessible if you just want to like chat, talk about your idea. Clearly, this is, as you've gotten from this episode, a new design. We're still, we are, we want to explore this design space. And clearly with anything new, we want to take a very hands-on approach to just help people in their crazy shit that they want to build. So reach out.

Amazing. Steffi, Dino, thanks so much for coming on. It was a real treat. And yeah, we'll link your Twitter, Discord on the show notes. People to go check it out. But thanks, thanks again for coming on. Really enjoyed the conversation.

Thank you. Likewise.

It's great chat.