Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Mel Project: Is Web3 Truly Decentralised? - Eric Tung

Episode Date: July 26, 2024

Web3’s decentralisation is currently limited to smart contracts as they can be verified on-chain. However, until scalability and UX become on par with that of Web2, the only realistic way for crypto to reach mass adoption is threw off-chain dApps. This creates the premise for a security bottleneck in the form of centralised APIs used for on-chain querying. Mel Project aims to expand on-chain security and decentralisation (consensus) to off-chain apps, basically achieving off-chain composability through trustless light clients. Earendil, the backbone of their ecosystem, designed to resist ISP-level censorship, is a decentralized anonymous communication and payment network that enables autonomous applications and true P2P protocols.Topics covered in this episode:Eric’s background and founding Mel ProjectWhy Ethereum came shortIs Infura a security bottleneck?Liberating markets (and the Internet)Light clients and how Mel Project tackles themUse casesSmart contracts on Mel ProjectScaling the ‘world computer’Mel Project’s consensus: StreamletWhy Mel Project chose an UTXO modelEarendil & ISP-level censorship resistanceRoadmapThe Geph VPNMel Project’s low volatility (stable) coin$SYM: PoS tokenMisc.Episode links:Eric Tung on TwitterMel Project on TwitterGeph VPN on TwitterMoxie Marlinspike's 'My first impressions on web3' articleStreamlet BFT consensus modelSponsors:Gnosis: Gnosis builds decentralized infrastructure for the Ethereum ecosystem, since 2015. This year marks the launch of Gnosis Pay— the world's first Decentralized Payment Network. Get started today at - gnosis.ioChorus One: Chorus One is one of the largest node operators worldwide, supporting more than 100,000 delegators, across 45 networks. The recently launched OPUS allows staking up to 8,000 ETH in a single transaction. Enjoy the highest yields and institutional grade security at - chorus.oneThis episode is hosted by Brian Fabian Crain.

If we truly had a free market, I don't think we would necessarily need all this decentralized technology. The market would take care of it. What we really needed is a new kind of blockchain, where what happens on the blockchain can be trustlessly observed by systems outside the blockchain. Bitcoin isn't really made for supporting these off-chain use cases. So I tried Ethereum, too. That didn't turn out that well either. Mel started as like this research project to build a blockchain. back and actually support a whole internet that's user sovereign that has like decentralization

and security and resilience in all the protocols, you know, not just the blockchain. But if you actually start building these massive networks that depend on correct knowledge of what happens on the blockchain, then if somebody hacks Infer for a day, that's like worse than hacking Ethereum. This episode is proudly brought to you by NOSIS, a visioning collective committed to fostering and expanding applications for a decentralized future. Nosis is at the forefront of innovation with NOSIS pay, circles, and metri, revolutionizing open banking and creating a superior form of money.

With Hashi and NOSIS VPN, they are building a more resilient and privacy-focused open internet. Are you seeking a robust L1 to launch your project? Well, look no further than the Nosis chain. Enjoy the same development environment as Ethereum, but with significantly lower transaction fees. And with a robust network of over 200,000 validators, nosis chain stands as a credibly neutral and resilient foundation for your application. Governance of NOSIS is driven by NOSISDAO, where everyone has a voice in shaping the project's

future. Join the NOSIS community today by participating in the NOSISDAO governance form. You can deploy your project on the EVM-compatible and highly decentralized NOSIS chain or help secure the network by running a validator with just a single GNO and low-cost hardware. Embark on your journey towards decentralization today at NOSIS.io. Korse 1 is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos, Celestia, and DYDX. More than 100,000 delegators stake with KORS1, including institutions like BitGo and Ledger. Staking with Kors 1 not only gets you the highest years, but also the most robust security

practices and infrastructure that are usually exclusive for institutions. You can stake directly to Quarice 1's public note from your wallet, set up a white table node or use the recently launched product, Opus, to stake up to 8,000 eth in a single transaction. You can even offer high-year staking to your own customers using their API. Your assets always remain in your custody, so you can have complete peace of mind. Startsaking today at Corus.1. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution.

I'm Brian Crane, and today I'm speaking with Eric Tong, who's the founder and CEO of Mell Project. And so really excited to get into that with him. There's a lot to unpack. Thanks so much for joining us today. I'm really excited to have you on. Yeah, I'm really excited, too. So, you know, we spoke a bit before and I've looked a bit, you know, sort of been looking a bit into mail or the thing you're working on.

There's a lot there, right? There's a lot of different components for it. It's a very ambitious. It's a very ambitious project. But I thought, I don't know where it makes sense to start. I wonder if it makes sense to start with your VPN. And, or like, tell us sort of, like, your journey of, like, how you, um, how he became interested in decentralization and the topics around it.

Yeah, absolutely. So, you know, I grew up both in China and Canada. So back when I was small, my family moved between the two countries a lot. So I kind of got to experience both like a relatively well-functioning Western country, but also a country where, you know, you had a lot of censorship, a lot of surveillance and all of like technological control over people. So like that actually played a big role in how I got into computers as a whole. Because when I was small, I was like 11 or so.

I was just learning how to code. And it happened to be the same year that China turned on its great firewall, you know, and put it into production. So, you know, one day I just woke up and then all of my favorite websites were gone. I couldn't go on YouTube. I couldn't go on like, you know, Facebook. and that was a really big shock to me as a like, I needed to fix this. I needed to go to those websites.

And that really got me into things like VPNs, anonymous communication technology, and really just like there's this whole world that's dedicated to, how do you hide from your ISP? How do you transmit data on the internet in a way that your ISP doesn't know what's going on? And so I really kind of dove into that. made my, back then with my like very limited coding skills, I made like a very janky like browser actually that had a VPN in it, had like anti-fishing and things like that into it,

really got me into kind of like cybersecurity and privacy and all of that. So later on, you know, I really felt like my mission in life is really to use, cryptography, use these tools to build things that let people freely coordinate and freely access information. I didn't know. I didn't know that much about crypto or blockchains. I just went to, um, went to like university at Waterloo. Later when I was 17, I got into their PhD program. I was like very much into like cypherpunk things, right? Like I was like very much into tour, you know, a free net, all of that. How I really got into kind of like decentralization per se is really that I really saw two things. So first of all, one thing I really felt like after I started actually researching these

things is that you need to build like trustless systems. And this is especially, you know, after like the whole Snowden thing that leak happened, I realized you couldn't just host your server in the US and expect that to be good enough. You can't, you can't just expect, okay, China's bad. You know, Iran's internet's bad. But as long as you encrypt your traffic outside of these countries, you're fine. Well, that full paradigm got shattered. You can't trust anybody's infrastructure. And the other thing is that then I discovered Bitcoin, which showed that it's actually possible to build things that

where you don't trust any particular person through the power of economics. You can actually build systems where you're not assuming that somebody's trusted. Or even assuming that a majority is trusted. You're just assuming that a majority of people out there want to make money, which is a much easier assumption to make. and then you can build secure systems. So I was super excited about Bitcoin, about blockchains. I kind of like pivoted my whole research into how can I build these tools on top of Bitcoin.

I even built like, you know, public key infrastructures and things like that on Bitcoin. And all this time on the side I was developing my VPN that I started when I was small. I rewrote it several times. And just to, I like before you were saying, so you started your PhD program at 17? Yeah. That's pretty crazy. Yeah, I was like home school before bachelors, before I went to university. So like I wasn't necessarily limited to a particular schedule.

So I went to my bachelor's when I was 14 and I got into my PhD one of seven. Both in the University of Waterloo. So it was easy. I just like stayed at that one school and went to whatever prof liked me the most, I guess. So. And then in the PhD you focused on, you were working a lot on your VPN. Or also other... Not really.

Like, so I was really focusing on peer-to-peer networks in Tor and anonymity and that kind of thing. And that really led me down to discovering Bitcoin and discovering that you can actually build secure consensus in a decentralized setting. And so, so yeah, like I kind of pivoted more towards how can we build things like these cool peer-to-peer networks, these naming systems on Bitcoin. but later on I really discovered you kind of can't right like Bitcoin isn't really made for supporting these off-chain use cases. So I tried Ethereum too. That didn't turn out that well either. I published a paper where so like here and there, but I just felt like that was not going to be power the next generation of the internet. So I really sat and I thought about it and I realized what we really needed is a new kind of blockchain. where what happens on the blockchain,

it can be trustlessly observed by systems outside the blockchain. And that kind of started, Mel started as like this research project to build a blockchain that can actually support a whole internet that's user sovereign, that's, you know, that has like decentralization and security and resilience in all the protocols, you know, not just the blockchain. But you need a blockchain to support that. So you said you were kind of like trying out Ethereum and then you felt like Ethereum wasn't the answer.

What were the things that you felt were the shortcomings of Ethereum? There's only just one, honestly. It's not just Ethereum. It's every other layer one, which is that we don't have really good light clients. So here's an example. So let's say I'm building a BitTorrent replacement, except the nodes are incentivized. So, you know, if I download a file from you, I got to pay you, something like that.

Let's see you want to build this at Ethereum. Well, there's many ways you can do this. You can just use on-chain transfers. You could use some cool state channel thing, cool layer two. It doesn't matter. There's lots of ways you can do this. But if you actually get down to implementing this, so you have a BitTorrent client running on your computer,

and it's downloading a file from a peer, and it needs to pay that peer. and it also needs to verify incoming payments. So all of these things goes through an RPC provider, like Infura. Now, this has two problems. First of all, they see everything you do. They can censor it. But that's not even the worst problem.

The worst problem is that they can lie to you, right? Like when you ask Infura, did I get my payment? They can say yes when the actual answer is no. And there's no way for your client to know. So really, the whole security, the whole economics of the system completely depends. on inferior telling you truthfully what's happening on an Ethereum blockchain. And then your system is no longer decentralized.

I thought BitTorrent was supposed to be decentralized. Now you add a blockchain in and now it's centralized. That's the opposite of what you're trying to do. So I was trying to build these systems in with every single blockchain and trust. Like this became a huge problem. And I suspect that the reason why we currently don't feel like this is a huge problem is not because we're not building this kind of system. That actually is off-chain, but uses on-chain for security.

Because if you're building systems that are on-chain, then this is fine. If you're transferring entities on-chain, if you're allies to you, they don't steal any money. If they don't do any damage, you go switch to a different RPC provider. If somebody hacks in through a day, it'll be a great inconvenience. It wouldn't lead to massive hacks of huge worldwide systems. But if you actually start building these massive networks that depend on correct knowledge of what happens on the botching, then if somebody hacks Infer for a day, that's like worse than hacking Ethereum. Of course, I think a lot of people are sort of like aware of this problem. I mean, I remember a great article by, we should probably put the link on that in the show notes.

I think we mentioned it before. But there's this great article by like Moxie Mullins, Marlins. Yeah, exactly. Yeah. Right. But he kind of points exactly to this issue. But yeah, you're right that like people don't tend to think of this as a problem because I guess why would, I mean, if you're lying to you, it would ruin their whole business. They don't have an incentive to do that, right?

But I guess I wonder if, would the issue be more something like, okay, let's say if, you know, I built a Bittern network that has Ethereum incentives. And you're depending on a centralized RBC provider. I mean, I imagine where the challenge might come is that they're going to be like, oh, but, you know, we don't want to, you know, from a regulatory perspective, we don't want to like support this kind of thing. So we're going to have to like throw all this or shut it down. Yeah, I mean, honestly, this is the whole point of crypto, right? I mean, if you think about it, it's not in the bank's incentive to close your account.

it's not in the New York Stock Exchange its incentive to stop you from selling Doge coins on it. The whole idea is like if we truly had a free market, I don't think we would necessarily need all this decentralized technology. The market would take care of it. The problem

is that we don't, right? We have monopolies and oligoplies that are controlled, that, you know, have a symbiotic relationship with regulators. And that's the whole problem we're solving with crypto. So, you know, so basically here's the thing. Like if you're building a app that depends on an inferior, you know, if you, if that's fine for your use case, then it's also fine not to use Ethereum. It's also fine to have inferior run the whole app infrastructure. Right. Like, now this is different. So I think that there's the biggest reason why people don't feel like this is a problem is because we're not trying to build this kind of app where the security bottleneck actually is inferior. So for example, if we're actually doing, you know,

defy trading, where like the current Web3 ecosystem, Inferra isn't really the security bottleneck. Because as I alluded to, if inferior lies to you about how many pudgy penguins you have, how many if you have, what's the status of the pools on GUNA swap. The damage they can do is very limited. Like, why would they do so and ruin their own reputation? The worst thing that could happen maybe is that they censor your transaction. They're not because of regulatory reasons. they're not going to lie to you because it's not in their interest and not in the interest of anybody who hacks Inferra. Like there's no reason why I would hack in Vera to troll people to say everybody has a Pudgy Penguin. Like maybe I would want to do that for fun.

It's not going to make me a ton of money. Yeah. And I guess the other thing I could also imagine happening here in the example of like, okay, Bitcoin Black Network is that, of course, some people are not going to like that, right? Like let's say the whole copyright type stuff, right? So I could imagine then them basically being like, hey, we're going to try to force Infura to give the IP addresses, right, of the people so that they can basically go and pursue them. Yeah, and I think like that's definitely a big problem. But I actually think that that's not the worst problem here, because that's still like a censorship problem of Infura stopping the network. I think the bigger problem is lying.

So I think maybe BitTorrent payment verification is not. necessarily the best example. So there are other use cases, like, for example, into an encryption. So I need to look up Brian Crane, like what Moksi Marlin's bike talks about, right? I look up your public key on a blockchain, and I use that to do into an encryption. Now, if you realize to me,

they can steal every single message I sent to you. Right? Like, maybe I'm doing some, like, big business deal here with, and transferring a bunch of money. Like, you can literally steal money this way by lying to the users. And so, and it really boils down to when we're using these decentralized systems, we expect that we're trusting the blockchain's economics. We're not expecting that. We're simply running, we're simply using a system run by insurer. So like, and, you know, because of this, if you're trying to build this whole internet, where the security really comes to the blockchain

and you're building these off-chain systems like, you know, payment networks or, you know, BitTorrent-like networks and into and encrypted messengers, then knowing what happens on-chain really matters. And the whole thesis of metal is that these use cases are way bigger than the current Web3 ecosystem. The current Web3 ecosystem is like, let's stuff things on-chain do the composability on-chain, because that's the safe place, right? That's where all the security and consensus happens. Once you're outside of it, you're kind of like out of luck. But if you can't actually transfer the security out of it,

then this changes the whole paradigm. It makes building out Web 3 and mass adoption everything way easier because you just need to look at the blockchain from outside when you need to. So I really like what you said before. Like, you know, if you had a truly free market, we wouldn't need all this decentralization. and I think that's a very true point. And I think on some level, right, if you kind of zoom out,

like what is all this crypto blockchain decentralization about? To me, it is also about creating an economic system that is actually a free market. Exactly. And I think that like Mel is really about that as well. I think what crypto has currently done is it has greatly liberated finance, right? anyone can create financial instruments, create tokens, sell basically stock in projects, right? But I think that the rest of the internet means a similar change.

You want a whole internet that's permissionless, that's borderless, that people can transact and communicate on freely. And what Mel does is that it takes all the cool security and decentralization we've invented for blockchains and uses like clients to let people build other protocols, like communication protocols, like publishing protocols, to have the same kind of properties and really get the Web 3 revolution happening across the Internet. And this is like making a truly free market, right?

Because you can't just only have a free way of sending money. You also need free communication, you know, free publishing, all of that so that people can coordinate and come to consensus on this. I would love it. Actually, if you can go a bit more into data, on, you know, the kind of like use cases that you feel like, you know, because you're saying, okay, this is the kind of thing that, you know, could really get us to like mass adoption

and too much broader use cases than the current sort of, you know, defy type thing. Like, what are the use cases that you feel, you know, those are really the things that are most powerful that could be enabled by such a technology and that would really, you know, be things that a lot of people would start using that, you know, today not using blockchain or maybe not using blockchain for these particular types of problems. Yeah, definitely. So I think that it would be helpful to start with the actual use kits, right? So imagine you had a Discord like app that's completely censorship resistant and permissionless. So, you know, it's the, imagine the UX is the same. It's just Discord, except, you know, you don't have to trust the Discord company while using it.

You can say whatever you want on it, start your own communities on it. And, you know, like, you know, and basically just like create this whole, create all these communities on this system that are sovereign and our user-focused. So let's just imagine an app like that. So the societal impact of this would be really big because if we think about, currently, how can you get people to work together? There are basically two ways. One is kind of like a in a private, informal volunteer basis way. So I'm a person living in the U.S., you're living in China, he's living in Russia,

let's go on GitHub and try to write some code together, try to build something. And this is one model. The other model is that this fully regulated, very bureaucratic, multinational corporation, where, you know, I have to like, you know, make this whole legal strutely. hire people, do some big thing together, and it's all very complex, and it's really easily damaged or shut down by random political or societal differences. So that's the current world. But if you have a truly permissionless communication and community building tool, what you can

actually build as an example would be a multinational borderless, permissionless collective of people working on things. That's properly governed and properly incentivized. So imagine you can do votes on this. I mean, Discord can do votes. You can do votes on this. You can use this to control the treasury, talk about things completely permissionlessly. And you can access this app anywhere in the world. You know, China can't block it. Iran can't block it. Nobody can stop your money from flowing. Nobody can see what you're doing on it. So this will do to community building and Dow creation and coordination what, you know, Bitcoin did to money transfer. So you could imagine people working on things like, let's archive all the books or let's, you know, share whistleblower information or do journalism in these communities.

And it'll be both public, but also permissionless and organic. while currently we have a dichotomy between if you want secure and permissionless and kind of like outside the cannot be shut down it has to be low profile and private. If you want public, then that's like very bureaucratic and regulated. If you have a, it's just this one application

will let you build a world where people can make public but also permissionless collectives that work kind of fixed together. Yeah, so the problem with something like Discord today is like, okay, if you, I mean, I guess I, so I guess one problem would be how you link the Discord to something now, you know, on chain, like, you know, we control a bunch of funds together, things like that, right? So that never, it's not the biggest problem.

I think the biggest problem is that Discord is a centralized platform, right? Like, Discord sees everything you do. They can shut down a community they don't like. And, you know, also, like, if your ISP doesn't like you accessing Discord, then you don't catch an access Discord. Like, in China, it's quite difficult to access Discord. So, like, I think, like, it's not really about the on-chain. It's really about the software itself.

You know, what can you do if in Web 2 versus a truly permissionless application? And so if you think about this permissionless discord, just like the actual Discord parts, let's forget about crypto or blockchains. I think that'll really create this very vibrant marketplace of ideas, of coordination, that currently doesn't exist on the internet. We can really let people from all around the world join and participate and do things that we currently just can't do.

And I think that what, and the thing about Mel is that to realize this kind of vision, you need two things. First of all, you need a way of actually, combining decentralization, but also like a centralized user experience, right? Like the problem with decentralized messengers now is that you got to manually set up your servers and things like that, and you need to manually connect to them, and you're still trusting that particular server. But with like clients in a blockchain like Mel,

you can actually have a whole free market of different providers you can pick from, move your group between these things. And I wrote a whole blog post on this called, like, like confederate protocols or explore this concept, where it is that we start with a model that we know how to build, which is federated message passing, which was used in like email, used in Matrix, used in XMPP, and we simply had a very simple blockchain layer to that, and we get like fully user sovereign, very decentralized, and better user experience, because the whole thing becomes one namespace. It's like Discord. You can search for servers,

join them, you have one username, you have like one identity, your identity's not bound to whatever server you pick. And so you end up having the same user experience as a centralized app, except as permissionless. All the incentives actually go to your community, not to Discord. So imagine when you boost your server, you're actually contributing to public goods for your community. And it's censorship resistant. And like it's going to have better quality of service, because there's going to be a pure free market and the service providers that provide hosting for these communities.

So because switching is basically zero cost. And so that's the kind of thing that Mel lets you build, like this kind of like much for your market, for resources, for protocol, infrastructure that let you build much better internet apps than with Web 2 or I guess with current Web 3 tech jobs. So maybe you can go, a bit into

a little bit into the light client aspect here because I mean light clients is something that of course in crypto is always you know everyone's always you know people understand like kind of the importance of like clients

at least more or less I think what is why is it so hard to have for existing blockchains to have good light clients and like what's the challenge around light clients and how do you do light clients and how come they're so much more efficient and maybe also kind of a connected question.

I mean, to me it seems like this is something where actually there's a lot of innovation of work at the moment that goes into this kind of thing of like, hey, have really efficient proofs of what happens on chain, off chain, which is I guess like ZK. proofs. Do you feel like ZK proofs are kind of enable this properties for like any blockchain or is this, yeah. So maybe like talk a little bit about like the kind of the role of light clients and how the technical challenges around efficient light clients. Yeah. So I think that like the thing about like clients is that it is true that let's say if you're wanting to build a like client for Ethereum, there's a ton of technical challenges you have to overcome because

Because Ethereum is a complex protocol, you know, you need to somehow prove that somebody correctly executed all of that and show it to your like client. That is actually very difficult. So how Mel, so the thing about Mel is that it's not really dealing with the same problems as light clients for existing L1s are dealing with. The thing about Mel is that because we're making a new layer one, we can design everything in a way that it's easy to prove to like clients. So, you know, there's a ton of things that goes into it, like putting everything in Merkel trees,

using a very simple UTXO model. The upshot is that it actually turns out to be very easy to prove to a lie client that we came to consensus on this, this part of the state says this, without using ZK proofs. Now, of course, ZK proofs can compress this, but even without that is very efficient. And I think that, so this is one part, like how you, easy it is to actually prove the state. The other part is actually, like, I think that there's a lot of awareness in this space that like clients are good, but I think that what Mel really sees is why, like, what can you do with like clients? And I think that currently in this blockchain

space, we tend to think of like clients as a scaling technique for, you know, like doing things like cross-chain things. It's really about how do you make the blockchain better. But Mel's insight is, if you have really, really good light kinds, it's not just enough to have light clients. You need the light clients to, for example, be very, very light, and allow them to, for example, go offline for a long periods of time without legal security. You combine a lot of these features.

You have this, like, super-powered light clients. Then you can build categorically different and much bigger and better applications than what the blockchain ecosystem is focused on right now. So if you think about kind of like this sort of decentralized Discord, let's just think about the architecture of this. It's actually very simple. You simply start with a system like Matrix and you put a mapping between your username

and which server you're on onto the blockchain. So you know, for example, currently maybe Brian Crane is at matrix.org tomorrow it might be at Brian Crane.com. You know, this mapping on chain. And in your actual, like, chat client, you look up this mapping to see which server to contact to talk to this guy. So it's literally just this very simple little thing on the blockchain. And you have to be able to look at that securely with like lines.

But after that, it's a completely conventional, traditional internet system. It's just a federated chat system just like Matrix or email. And so Mel's insight is that if you have good light clients, you can start building things like this. And you could easily build full-stack, decentralized user-sovereign software by putting a little bit of things on the blockchain and having every single user look at it. And I think that's something that's hard, even if you have, let's say, Ethereum like clients. Because Ethereum-like clients, for example, they have to be online all the time. They're not that light. you know, other blockchains have similar caveats.

So if you're like client, even when they do have like clients, they tend to not be optimized for this kind of use case because that's not what they're thinking about when they're designing the line. So that means you can't build a system like this practically on these other blockchains, but you cannot know. And I think this is the key in section. So in this example of the Discord-like thing,

So the thing that you would put on chain, so you said a mapping of username, so let's say, you know, Crain BF or some sort of thing like that, you said the mapping of usernames and servers you put on. Can you explain that a little bit more? Yeah, definitely. So let's just use email as an example. Right. So currently you might have CrayfBF at example.com. And that's your identity. So you're, identities owned by example.com. And this means that you don't have a free market in providers. If you switch to a different provider, then you don't keep your identity. So this is the first problem. So the first problem is that you don't own your identity, somebody else owns your identity. The other problem is that end-to-end encryption is hard.

You might use PGP to encrypt your emails, but how are people going to know your public key? So what ends up happening is that you don't have good encryption, and you don't control your identity. And basically the situations that the provider has sovereign team over them. They see everything. They own you. You don't own yourself. Like example.com owns you.

Now let's just add to this email system, a very basic layer, which is a mapping between cranebf, like a global username, not cranebf at example.com. So cranebf with an ENS-like system, map that to example.com, comma your public key. So you put that on chain. So here's what will happen then. Now, when I want to talk to Queen BF, I just need to send a message to CraneBF. And my chat client immediately knows

which server to contact and what public key to encrypt my message. So I meant send a message to Crane BF and you get it. And, you know, I don't have to know your server or your public key, And I don't have to trust anybody else to tell it. It's trustlessly stored on the blockchain, and I looked at it with my like client, so I verified that information myself. Now tomorrow, let's say example.com becomes this draconian censorship machine. They don't like you any.

So you switch. Great. I'm going to go to like fubar.xyz. So all I need to do is register an account at Fubarb at fubr.x, point my thing to Fubart at xyz and continue using the software. I don't have to, like my identity is not owned by example.com. I'm just, like, they have to serve me. I'm just their customer. I can go switch to anybody else.

So what this really means is that there's going to be like free market and providers. You can switch with no cost. And the providers can't decrypt your messages. All they're doing is offering storage and relaying services. And if you don't like the server, you can switch to somebody else. And so you have, so architecturally, this is still email. It's literally just email, but with this little unching bit that the clients look at. And but because of this, then this whole system is user sovereign, N2N encrypted,

and honestly decentralized entrustness. It's Web 3. It's no longer Web 2. By the addition of this little piece of piece on the blockchain. So I think this is really what Mel is about. You can start building these systems where you can. can sprinkle this like Web3 pixie dust on a traditional Web 1 protocol and you get something that's radically more secure, more user sovereign, more decentralized. And this only works if the kind of like off-chain parts can compose with the on-chain parts

securely using Whitelands. So we talked a bit about this thing of like basically the communication and the sort of community aspect, what are the other use cases that you're most excited about this technology enabling? Well, I think that the thing is that it's going to compose like layer by layer, right? Like, if you think about how do humans interact, there's really two big things. One is transactions. I need to be able to send you money. The other is communication. I need to talk to you. Now, if we can talk to each other and set each other money, we can do business and create value and create things.

So what Mel is really about is building the infrastructure to allow this kind of value creation that unlock these opportunities of people interacting and building things that previously don't exist. So you know, you could imagine some Dow on this Discord-like thing comes up with some really cool idea of some public good funding system, let's say, and they're operating that. Well, that's a use case that's only enabled by Mel, but it's not directly. It's more like we have, we build an infrastructure to let people interact. And that's just like how the internet works, right?

The internet doesn't, it's not really like Riverside FM is a IPV4 use case. Well, technically it is, but it's not like IPV4 was designed so that, okay, one use case would be Riverside.fm. It's more like it's such a general purpose, liberating tool that allows people to innovate systems like Riverside. out of after. And, you know, of course, you can think of specific things you can build on Mel, other than the Discord thing. For example, I've also written blog post sketching out how you can build decentralized, incentivized, MMO games on, in this paradigm, how you can, you can also build things like, you know, much better file storage networks that are truly free market. And not based on tokenomics, unlike, you know, file queen, et cetera, but truly based on you just

pay your provider. These are all things you can easily build with, this whole paradigm. And I think that we already know how to innovate like this because it's just the internet. It's the whole internet paradigm. The only difference is that now with like clients, you can get decentralized consensus on security critical things whenever you need it. But once you have that, you don't need to reinvent the wheel. We know how to build federated protocols. We know how to build peer-to-peer file transfer protocols. We know how to build web hosting protocols. We know how to host HTTP servers. We just need to compose those with pieces that let us incentivize and decentralize all. You know, one of the main things that people do on blockchains is, you know,

smart contracts and, you know, during complete smart contracts and then build all kinds of stuff on that. Is that something that the mail chain is also able to do? Or like, what's your view on, like smart contracts? Well, I think there are excellent abstraction for what they're used for right now, which is defy and making financial instruments. I mean, Mel technically has to rein complete smart contracts, even though it has a UTXO model, so you could do it on layer one. But I would imagine in the ML ecosystem,

most people would not be doing this on layer one. It would be, let's say, on a ZK roll-up on Mel that is EVM compatible, so that kind of thing. would work much better. So that's how I think about it. I think it's a great tool as its job. I don't think it should be the world computer. And it shouldn't be what defines Web 3. It's simple one kind of decentralized app

that makes sense in the ecosystem. Yeah, and it shouldn't be the world computer because of like, one, is it like scalability issues if you try to put all the smart contracts on the chain or it's also because you feel like just by having like clients you can do a lot more things

that are off-chain where today you do it on-chain. Like the whole reason why we feel like scalability is a problem is because we have to do everything on-chain so all we got to do we've got to somehow fit it in, right? Mal's whole thing, and that's hard, right? Even if you have a very, very, very fast blockchain,

you still need to convince the whole world to this new paradigm, right? don't run servers, don't run peer-to-peer nodes, stuff all your logic on chain and trust that the nodes on whatever blockchain will run it for you. I mean, that's like how ICP was trying to do it, for example. That's difficult.

I don't think that's... Even if it could work, it's very difficult. It requires rewriting the whole internet. Mel's approach is actually that, you know, given that we have good like lines, why do we need to do that? We can build our internet protocols the way people have done for decades.

We know how to do that in a scalable and sustainable way, except that now we can make those things decentralized and secure whenever we need to, by reaching for the blockchain to compose with on-chain logic whenever we need to, but not by using the blockchain as a world computer that the whole ecosystem lives on. Now, that's a paradigm that I don't think generally works and has worked in the past. One analogy I like to use is the internet, versus telecom before the internet. So telecom before the internet

is basically this one-world phone network approach. The whole world was one integrated telecom system from application to the infrastructure. All the innovation happened on the base layer. You want better quality phone calls, base layer. You want pagers so that a device can buzz when you get a phone call. That's the job for the base layer.

Everything requires infrastructure-level, layer improvements. Now what the internet really realized is that actually we can make the base layer composable, simple, and neutral. It's just a packet routing layer. You know, it doesn't need to have any features. It just needs to sit there and move stuff and, you know, compose with other networks. So it's actually decentralized in a way, the internet. And then we can leave as long as we can allow anything to use it across the telecoms stack whenever they need to. and then we're done, right? Like market innovation takes care of the rest.

AT&T did not need to invent every single website. And I think we need to, we're going to see something very similar in Web3, which is that the early paradigm of doing everything in the base layer, that's easy to build out at first, but it really is inherently limiting because it means that all sorts of key innovations require improving the base layer,

like adding ZK stuff, improving throughput, improving storage capacity. And it's actually worse with botchains because every time you change the base layer, it's governance. And you run into the issue of if you change a base layer all the time, is it even decentralized or is it actually controlled by the deaf team? But even ignoring that, right, this is just architecturally, like, very slow and very, like, limiting.

If we can have, like, a stable base layer that just sits there so that you could put things on it that need global consensus and you innovate and innovate and, build protocols elsewhere. I think that's copying the success story of the internet that really took telecom to like an unimaginable new level by decoupling the base layer from the apps. So I think like that's how I'm thinking about where Mel is going. And then so it's a you know the thing Mel that you're building here it's a proof of stake uh layer one. So let's talk about the about this a little bit. So it's UTXO, proof of sake, base layer at one. So for example, for consensus, how does the consensus work? Well, we use like a Byzantine fault-tolerant

consensus protocol called Streamlet. So as far as I'm aware, we might be the only blockchain to actually use that in a production system. So Streamlet is a BFT algorithm invented in 2020. That's actually designed for pedagogy, like, you know, teaching people how BFT works. So it's a BFT protocol designed to be as simple and easy to explain as possible. And we chose that because we want our base layer to be as simple and easy to explain and easy to implement as possible. So we picked this kind of BFT algorithm. I really suggest everyone read the paper like of Streamlet. It's surprising how simple you can make a BFT algorithm.

Like it's basically as simple as Bitcoin's consensus, except it's proof of stake and it achieves financial. So we need finality for good buy clients. So we pitch the stream. And then issue, I mean, a lot of people will be familiar with tendament, you know, which is, I think, sort of like the generally also considered like, you know, a very simple BFT proof of sake system. So, but streamlet is even simpler or like in what ways is it simpler than something like tendament? Well, I think it's kind of hard to explain. It is just literally way simply. Like the paper is much shorter. It's much more obvious after you read it, how to implement it, and why it's correct. So it's actually built on top of a lot of previous work, including tendermint.

It's really the product of a lot of work done by the office of that paper to really build the easiest to explain and implement BFT algorithm. So, yeah, like with Tendermint, for example, there's these several. rounds of voting and all of that. You know, it's kind of tricky to understand why that's that you need to do that and how to implement it correctly. With streamlet, it's much easier. So it's also in lineage, I would say it's closer to like hot stuff and Casper BFT. It's more like kind of like a chain based BF2 rather than a voting based BFT.

So like, but that's like more of a technical detail. but I think that it's by far the simplest BFT algorithm I've seen. And after I implemented it, I realized its performance characteristics were good enough for our use case, so we decided to use them. Okay.

So yeah, so we have this simple proof of stake, BFT system. We also, maybe we can talk about the UTXO thing briefly. I mean, UTXO, of course, you know, everyone knows like Bitcoin uses UTXO, there are other chains that have tried to do UTXO things for smart contracts, but like what are the pros and cons between the sort of account-based model that Ethereum has and UTXO-based model? Well, how I'm thinking about it is that if you're trying to do smart contracts,

if you're trying to make an Ethereum killer, don't use it U-TXOs. It's a bad idea. Like, that's, you know, like I don't think UTIS is the right model if we try to do basically an accounts-based smart contract model. It's trying to simulate that on your UTXO is possible, but don't try that. It's not a good idea. There are other blockchains that have tried that,

and I don't think it's a great idea. Now, why did Mell use UTXOs is precisely because it's trying to do something very different from blockchains like Imperial. The big advantage of the UTXO model that there's the reason why Mel uses it, is that it makes all the state and all the data on chain structured

rather than unstructured. So if you think about, let's say, on Ethereum, if you're building a system like ENS, even if you have like clients, how do you know what name, you know, creating the FS map to? You have to call a contract and run EVM code. And that EVM code access

something in the state dynamically and tells you the answer. That's just inherently very complicated. If you have a like client, that means many, many round trips to request the little pieces of data your contract needs to execute. It means implementing a whole EVM interpreter in your like client. And all of this is because the on-chain data in a smart contract-based model, like account-based model, is legible to the on-chain code. it's not legible to somebody just looking at the blockchain from the outside.

With a UTIFo model, that's very different, because the actual UTIXO graph is structured. You can traverse it objectively without running on-chain code. So you can design your contract to simply encode, let's say you're mapping in the structure of the UTXO graph. And then you can just look up that structure, traverse it with like-client, without running on-chain code, without diving into little pieces on chain.

So that's the number one reason why we use the QTXO model. I think it's the best model if your main use case is to expose data in a way legible to off-chain like hearts. Because you can basically, I guess, if I can say paraphrase it, if I get it correctly, I can in Ethereum basically because you don't, you know, you have different transactions and you don't know what they, like, you know, you sort of have to know the state of the chain to know how that transaction affects, like, other parts of the chain. Yeah, exactly. It's not explicitly spelled out.

Yeah. Yeah. Whereas here, you could just basically take the UTXOs that, you know, relate to a particular username, and then as long as you see those UTXOs, then, like, you can kind of know this thing. Yeah, and you can also trace their history back. you see where they came from, and you can use like on-chain contracts to encode a shape in it. Like for example, I actually once wrote a paper there a long time ago of encoding a naming system in the UTXO graph of Bitcoin.

So you literally can use the UTXO graph as like a binary search tree and like build a tree and then you can, you know, you can sew like 0101, that means Brian, whatever, and then that's where you're binding is. So you can do tricks like this because the UTI-Sograph is structured data, not unstructured data. I mean, I guess one thing that could be interesting to go into it, but I don't know if that's where we should go now. I know you also have this sort of low volatility asset, but I don't know if we should go there or if there's some other parts of the system that you think are more important to explain now. Well, I think that like, I mean, that might be interesting, but I feel like the most interesting

thing about Mel is not actually kind of its individual technical parts, right? Because the thing about Mel is that I think it's really easy to like misunderstand it a little bit as, okay, it has all these cool parts. There is a lot of cool parts. It has a different consensus, a different currency, etc. But I think what's really cool about Mel is what it lets you build, right? So that's why, for example, right now, we're actually focusing mostly on building Airendel, which is this off-tural. data and money transfer layer that is built on Mel. And that'll really be the, like protocols like Arendel are actually where the ecosystem is going to be built around, not like apps building on layer one or like people running notes on

layer one. So I think like that's an interesting thing about Mallory. It has a lot of cool parts, but I think like what explains the design decisions I make with all these parts is this overall idea about how do you make a blockchain that you can used to build systems like, you know, A.Rendl, like, you know, the Discord thing I mentioned through. So. Yeah, so let's talk about Airendel. What's Ayr Randall? Well, how else? So Airendel is, like, if you think about, okay, so I think Airendel

could be explained as like this way, which is like, it's a network that you can use to transfer money and data, both quickly and privately. So you can think of it as kind of like Torr plus lightning network. So you know, you can plug your app into it and send data across or send money across, and it's all off-chain and fast. But then there's two big differences between Air Rendell and Tor Plus Lightning Network. The first one is that the nodes are incentivized. And the nodes are incentivized not through like a deep and like token system. It's actually very simple, which is that whenever you use resources on a node, you pay them.

You pay them with this same payment channel system. So, for example, I send a packet of data through you, your node, and I have to pay a price to user nodes resources. And we actually negotiate this price with each other. So it's a free market. There's no protocol that coordinates all these prices. People find peers that they're willing to peer with at prices they are willing to accept. And the second pillar is that Air Rendell is the first peer-to-peer network.

designed to be censorship resistant against ISPs. And this is actually really unprecedented because we think about censorship resistance a lot in Web3, but we typically mean the other nodes on the network cannot censor it, like Monero nodes can't, they can choose who gets through. We don't mean the ISP can't stop you from using the protocol. He can't ban the whole protocol. And this kind of censorship resistance,

I call ban resistance, which is like it's resistant to ISP's banning the protocol. And it's very difficult to do that in a decentralized setting, but I think it's very important because, you know, we're trying to build permissionless systems here, right? We're not saying, okay, we just don't, we don't trust our bank, but we trust the ISP. That's not what we're trying to do. We're trying to build permissionless systems. And that means we need to be sensitive resistant against our ISP as well. And so Aarendel uses a lot of technology I've developed for GEF, you know, my VPN project, a lot of the research I've done in traffic complication,

in sensation persistence, to build the world's first decentralized ISP sensitive transportation network. So that's really what Airendel is at a high level. And that's only possible because we can build on top of smell. Like, you know, the micropayments go on payment channels. kind of like Lightning Network, but settling on Mel. And because Mel has much better like clients, we can do so without forcing people to run heavyweight infrastructure.

And with Lightning Networks, if you run the Lightning Node, it's basically a Bitcoin full node. It's very difficult to do so on your phone, for example. But with Mel, you can build a payment channel networks where the clients are very lightweight and can really fit in every single endpoint. So that's just like one example of how we use Mel, but basically the incentive system and the kind of like security systems, they're all built on top of Malai Clyde's. What's the state of the project now? Like what have you built and like where are you sort of in the roadmap to making this happen?

Well, like currently for A.R. Rendell, we're currently in an Alphanette kind of situation. We have like a few dozen nodes running. a lot of them run by community members. And overall, that's the current focus of our development. So we're quickly iterating upon it. Upon it, we plan to launch the AirRendal Network into production later this year. And then launching Air Rendul into production, that means, but that comes before because the MEL proof stake chain is not in production yet.

Well, the Mell Prudestate has a dev net, right? That has been public for several years. So the initial version of Air Rendell would run on the Mel DevNet. But eventually we're going to upgrade that DevNet into a mainnet. So the DevNet wouldn't be shut down. It would just be relabeled as the mainnet once it's readed. And what's the sort of difference between the DevNet and the point when it becomes a mainnet? Well, I think the biggest difference is that right now, we run all the validators.

Nobody else has any tokens. Like, um, so that's the main difference. Once we actually decentralize the token ownership and allow other people to lend validators and decentralize that, then it becomes the main. Yeah. Okay. Okay. And then what about like other parties building applications on mail?

Like what's the state of that? Are there people building things? And like is it sort of, is there a developer ecosystem? already. So we have a whole SDK for building things on Mel, but kind of in the overall roadmap of the project, right now isn't, we're not quite there yet with like getting people to build an ecosystem. And the reason for this is because, you know, if you think about a typical crypto layer one, launching the Devnet is like closer to the last step, right? It's ready to develop. With Mel, that's not the case, because the ecosystem is not going to be built

by people just running things on layer one. It's really about people composing with low-level protocols within the ecosystem like Aarendel. So I think how we're going to do it is that we're going to first launch Aarendel with a big use case for Aarendel, which is actually Geth. My VPN project will turn into a front-hand for Airendel.

So I actually move all of my users from Gathe into the Airendel ecosystem by just upgrading their software. Because the user experience is not going to change, they're just going to be using Aarendel. And that's like about half a million or more daily active users. They're going to be using this first big use case of Airendel. And then I think like developer communities and people building on the system,

they would naturally look to compose with this ecosystem. All the revenue generation happening on Airendel, building new applications on Airendel, building other protocols like Airendel using it as a example. So I think that's the phase in which it makes sense to start having applications build on this ecosystem, not when there's only the layer one. This is kind of like the internet, right? Like if you only have IPV4, it's not really ready to build things on. But once we had email, once we had TCPIP, yeah, that's when the developer ecosystem started for.

So, I mean, you mentioned the VPN, right? It's called GF. So Arundel basically would be able to perform all of the kind of functions that people currently use the VPN for. Yes, and actually a lot more than that because with VPNs, you can only access websites, right? With Airendel, you're also able to host websites anonymously and also browse other websites that people host on the Airetel network and also send money to each other. So it's like a general purpose communication and payment network. And yeah, it's like a superset of what VPNs are able to do. Okay, so you can host website anonymously, of course, you know, we were like aware of,

the example of that is like Tor today, right? Yes, yes. It's quite similar to the interface of Tor. Yeah. And then is it also like, you know, I think in your Tor website, you know, like you're like the hosting websites anonymously, they also wouldn't have, you know, normal. It's not going to be like www. like whatever,

but it's going to have its own domain names. Yes. So in Tor, for example, you have this long string of characters. That thing codes your public key. And now the cool thing is that because we have mail-like clients, we don't need to do that. We can just be a short human-readable name.haven,

which is what Air Rwandan uses, because, you know, we can store a naming system. Like, as I mentioned, that binds your name to your public key. So we can actually have really human readable domain names and website names in this ecosystem. I mean, I guess this is also a potential use case or interesting use case would be kind of, you know, replacing or competing with Tor. Yeah, absolutely. I think that, like, um, ambitious. I feel like Air Rendell's going to kill Torre, right?

And the reason is because, like, it's more decentralized, because there's no, like, central directory server. It's also way better incentivized because if you actually serve the network, you get the market rate of, like, what people are willing to pay you. The problem with tour is that it's all volunteer run, which means that the only people running it are basically people with way too much money, which are basically spy agencies, right? because why would anybody else actually do this for free?

It's a lot of bandwidth, a lot of risk. So I think it'll definitely have better performance than Torr because it's also not going to be always overloaded because of this incentive system. And also the application scope is much bigger than Tor. Because Tor is really just focused on one particular kind of anonymity. While Arendel is actually designed so that the user can select how much anonymity they want.

They can get Tori like anonymity. They can get much better. Like NIM, for example, they can use MixNet delays to death, much better anonymity. They can also get very low anonymity for high performance. They can just use this as a general purpose internet.

And only for ISP censorship resistance, not for anonymity. And you can build, like, very high performance systems on it as fast as, like, you know, any other system. So I think, like, it's really, what Air Rendell is, is that it's going to be this universal internet layer that has the same interface as the internet.

It's like a virtual network that you can run any application you want on. So, yeah, I think that's, I guess, what Aire Rendell is. It's really doing, it's kind of like combining what people already do with Tor, with NIM, with the regular internet, with other lip P2P, all of these protocols in this one general purpose, elegant abstraction.

Cool, cool. Well, let's maybe let's talk a little bit about your low volatility kind of stable coin. Why create something like that? Well, because I want cryptocurrency. That's the short answer. I mean, if you think about it, right, like, why did people invent Bitcoin? They wanted a non-fiat currency, like a unit of value, a, like, media. of exchange, a store like, and all of that, right? So the thing is that we tried with Bitcoin,

we tried with other crypto. It didn't work. Every single one of them turned into a speculation token. It's essentially a meme coin in disguise. Nobody uses Bitcoin as the way they use dollars. And the reason for that is because they all have fixed supply. And they, and, you know, people's demand is volatile, so the price has to be volatile. So what Mel is trying to build is I want to build an actual cryptocurrency. I want to build something that's trustless, that's decentralized, but also feels like a currency. Its price shouldn't be too crazy, go up and down. People should be mostly using it to pay for things, not speculate on, like, it's going to go to the moon. And that's the reason why it made Mel.

currency. And the objective here is that I don't want to, but I don't need to make a stable coin. I just need to make a coin that's stable enough that it has a relatively state, but you can do accounting in it. You can price things reasonably. So you want the price to look something like US dollar to euro rather than US dollar to Bitcoin. And you also can't use oracles because that'll make it not decentralized. And I realized there's nothing else in the ecosystem like this. So I sat down and made my own design. And what's that design like? Yeah, so the high level objective is that I want to peg one mel to this unit called the DOSC, the day of sequential computation. So a day of sequential

computation is the cost of renting the fastest processor core you can find and occupying it for a day. So that's what a DOSC is. So the interesting thing about this metric is that it's one of the only metrics that have these two properties. First of all, it's actually stable in purchasing power over time. So 20 years ago, renting the fastest computer back then for a day costs about the same amount of money as right now renting the fastest computer right now for a day. In short, the fastest processor out there is about the same price to rent at any given point in time. So it's stable. The second thing is that it's trustlessly measurable.

And that's the really cool part, which is that we do not need an Oracle to tell us how much money this is. And this is because what we can do is that we can design an auction on chain where we give away some tokens, and we say, give me proofs of sequential work. So you can actually compute, like essentially it's zero knowledge proof that you did a bunch of nested hashes, which has to be done sequentially.

And then you can prove, okay, I did this many hashes and this many hours. Give me the reward. So what this really gives you is two things. First of all, you get an exchange rate between that token and how many hashes people are willing to give up to get that token. This is market-based, right? You don't need an Oracle for this. Basically, you can get an exchange rate between token and hashes.

And then by how fast people are doing these proofs, you can get an exchange rate between hashes and time. So finally, if you combine this, you get an exchange rate between retoken and time. And then you can use this to drive a stable coin mechanism so that roughly one token equals 24 hours. Does that make sense? Yeah, but does that mean, does it mean it's basically kind of like a proof of work? asset still, because like to get it, you do the sequential computation and then you get a token.

So if I want to get a lot of tokens, I'm going to run a lot of these CPUs each for a day. It's a little, like, it's proof of work in that sense, right? Like you use proof of work to mint these tokens, but it's not where the consensus comes from. And I also don't expect there to be lots of people doing this. The reason is because in typical proof of work, the way it works is that you're, printing these tokens and people kind of like divide up a fixed supply by how much like proof of work they do. And if the token goes up, then like people waste more and more power like competing over this same pole of tokens. With Mel's approach is more like if you do this much computation,

you're guaranteed this much tokens. So what will happen is that this will increase the supply of the tokens until it's no longer profitable to mint and then people will stop. And so the minting is only used as an arbitrage mechanism to keep the peg in check. It's not going to be profitable most of the time. It's only profitable when the protocol needs you to mint so that you push down the price. But you still don't have the case that like, I don't know, so even if it's like roughly stable, right, like it's someone else. It maybe it costs them, you know, $1 to produce like one token.

Someone else costs them like, you know, 90 cents or 80 cents. or something like that. So the 80s guy's going to mince. The $1 guy's not going to mince, right? Right, right. And then the 80s guy is going to mince, mince, mince, minst, until there's so many tokens that the tokens worth 80 cents, and then he's going to stop.

I mean, I guess you still have kind of the downside here that, you know, if now mail gets a lot of adoption, a lot of usage, then it still means that a lot of, basically a similar amount. I mean, let's say now the male, total token supply needs to get to like you know 5 billion because of how

much usage there is of the thing then it still means that there's basically roughly $5 billion worth of money will be spent or you know 4 and a half or whatever to get those to get all those tokens in supply but that's

the case with any system because if Ethereum's market cap goes up by 5 billion you got 5 billion dollars of USD going to like Crockin or other exchanges and it's the same thing. It was not quite the same thing. You know, because the Ethereum price goes up like then, you know, everyone's richer. And like you didn't have, if the Ethereum price goes up and now it's $5 billion higher, okay, there's some marginal buyer that would like bother that higher price.

But you don't have to, you know, expend all of the money to kind of account for the increase in the market account. Yeah, that's true. That's true. But, like, I think the thing about mail is that, anyway, like, if you actually read the paper I describe it, it's not exactly that you have to mint out every single mail. It's more like this minting process establishes a price feed for how much does a market value mail.

And if we need to print more males, the protocol actually prints more mel. You don't need, like, the amount of minting doesn't increase substantial in that situation. Like, the mincing people only indicate the protocol that, hey, Mel currently is overpriced, print more Mel's. Or Mel is currently underpriced. Stop printing Mel. So that's really the only thing that it indicates. And then the protocol prints more mail and it sells the mail. Yes.

And it sells the mail in exchange for the other token or sake token. Yeah. Right. So basically, in the case of how the Mel's. fly increasing a lot. Does it mean, let's say now it goes from zero to five billion, then some of it will be, I guess, spent by people doing the sequential computation and getting the mail, but some of it will be people basically buying mail or like buying the SIM token and exchanging it for

Mel. Exactly, yeah. So then it sort of also means that a lot of the value of the growth of the stable coin or the Mel market cap would be sort of absorbed by the SIM token. Yeah, exactly. So the SIM token is overall designed as the value accrual token. So it also is where all the fees go to. When you stake SIM and red validators, you get fees that are all denominated in Mell as people use MEL. So the more people use MEL, like the more value accrues to so. Tell us a bit more about SIM. What are the sort of properties of the same token? Oh, that's a much less interesting token. It's just a standard fixed supply proof of stake token. Like, there's nothing cool going on there. And the reason why I separated from MAL is really just

because what's good for a proof of stake token is different from what's good from a current. because for a proof of state token, you wanted to be like a crew valley. You want it to be fixed apply. You wanted to be like, if I own a third of the network, I always own a third of the network. With money, you don't want them. So it's kind of like, you know, shares in the bank versus dollars, right? And that's kind of the idea. So, I mean, a lot of proof of state tokens are inflationary, right?

for basically you're paying block rewards to the validators, right, for, you know, running the infrastructure. So if it's a fixed supply token, you don't do that here? Yeah, I don't do that here because if you think about that, right, like inflation's not free money. Inflations, you're really imposing the tax on everybody else who's holding the token. And you can just express that as a fee. You don't need to, like, inflate the token. So of course, you need to design the fee economy differently,

but Mel's whole design ensures that the work that the, you know, validators put in can be fairly compensated purely by transaction fees. And I think that's a more transparent design. It's also, like, more clear where their money is coming from. And, you know, it's also like just like more free market, right? Because with inflation, that's a variable that, you know, you need to centrally tweak. It might be too high.

It might be too low. The market can't correct that because it's baked into the protocol. With fees, it's different, right? Like if the demand goes up, the fees goes up. If demand goes down, the fee goes down. And it all scales with the actual social value of the MEPMAL protocol. You just have to design the right mechanism so that the validators capture that. And I think I have successfully done so.

It's quite a different way we charge fees from other blockchains. But yeah. Cool. anything else you want to talk about? I don't know, there's a lot of other things, right? Like, for example, how, like, Air Rendell really ties into Mel's overall go-to-market and how that'll work, right? Because I guess I touched on to that, right?

Like, Gap will turn into an Air Rindle front-end, but I think, like, the bigger thing there is that once you have a lot of users on A.Rendl, then you have a ton of demand for anonymous traffic relay on the AERRendel network. work. That means that you, the listener, if you read a node, you can actually get a lot of those, a lot of that demand as revenue. And this is also really cool because what this means is that Airendel gives you a free market for satisfying people's demand for the free internet. And I also envision a world where this means that internet shutdowns and internet censorship becomes impossible because if let's say you're some country and you shut down the like international internet,

then the price for transferring air rental traffic in and out of the country would go up like crazy. And if you have like a Starlink or like a little cable across the border, you're going to make a ton of money by serving the Aero rental network. So what really what Airendo really does is that it uses the invisible hand of the market to solve internet censorship. And I think that's the thing I find the coolest about here, Randall. Cool. Well, thank you so much, Eric, for coming on.

And thanks for walking us through it. I think that was really great. And I think they gave a really great overview. I do think this is one of the most, yeah, just like regional projects, right? Sort of really trying to think through things from a sort of, you know, fundamental design perspective of like what we actually want to do with this. and then, yeah, so there's like so many original things you came up with here. So it's very exciting to see where this is going to go.

Yeah, definitely. Cool. If people want to get involved, what's the best way to do so? Well, join at Discord. Go to our website, melproject.org. You can find all the links to the right things there. So if you join our Discord, we have a lot of lively discussions about research and our protocol, development. Just join the conversation.

Cool. Well, thanks so much, Eric. It's really great to have your own. You too. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts.

And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv. Subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners,

you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.