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. 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 a theorem 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 a 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 inferior for a day, that's like worse than hacking Ethereum. This episode is proudly brought to you by Nosis, a visionary 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're 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, Gnosis Chain stands as a credibly neutral and resilient foundation for your application. Governance at Gnosis is driven by Gnosis Dow, where everyone has a voice in shaping the project's future. Join the Gnosis community today by participating in the Gnosis
Dow governance form. You can deploy your project on the EVM compatible and highly decentralized Gnosis 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 dot IO. Chorus One 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 Chorus One, including institutions like BIT, Go and Ledger. Sticking with Chorus One 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 Chorus One's public note from your wallet, set up a white label note, or use the recently launched product Opus to stake up to 8000 ETH in a single
transaction. You can even offer high yield staking to your own customers using their API. Your assets always remain in your custody, so you can have complete Peace of Mind. Start staking today at Chorus .1. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralisation and the blockchain revolution.
I'm Brian Crane and today I'm speaking with Eric Tong, who is the founder and CEO and CTO of Mel Project and so really excited to get into into that with him. There's a lot to unpack. Thanks so much for joining us today. It's I'm really excited that to have you on. Yeah, I'm really excited too. So yeah, we spoke a bit before and looked a bit, you know, sort of been looking a bit into Mel or the thing you're working on.
There is 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 we're like, tell us sort of like your journey of like how you how we became interested in, you know, decentralization and the topics around it.
Yeah, absolutely. So, you know, I grew up both in China and Canada. So, 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 sense 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, 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 wake, 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, and you know, that was a really big shock to me as a like, I need to fix that. So I need to go to those websites and I, 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 what's going
on? And so I really kind of dove into that made my I back then with my like very limited coding skills, I made like a very janky like browser actually that had AVPN in it had like anti phishing 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 that much about crypto or blockchains. I just went to went to like university at Waterloo later when I was 17, I got into their PhD program. I was like very much into like superpunk things, right? Like I was like very much into Tor, you know, Afrina, all of that. How I really got into kind of like decentralization per Southeast 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, you can't just expect, OK, China's bad, you
know, Iran's Internet's bad. But as long as you encrypt your traffic to outside of these countries, you're fine. Well, that whole paradigm got shattered. You, you can't trust anybody's infrastructure. And the other thing is that, and 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.
We're 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 block chains. 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 just. To I I like before you were saying. So you started your PhD program at 17? Yeah. That's pretty crazy. So you do. I was a bachelor's world before bachelor's but 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 when I 7th both in the University of Waterloo. So it was easy. I just like stayed at that one school and went to whatever like to me the most. I guess so. And then in the PhD you focus on, you were working a lot on
EVPN or also. Other not really like so I was really focusing on peer-to-peer networks and 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 core 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. And I published a paper or 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, I really sad 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 Mel started as like this research project to build a blockchain back and actually support a whole Internet that's user sovereign. That's, you know, that has like decentralization, insecurity and resilience in all the protocols. You know, not just the blockchain, but you need a blockchain to support them. Just so you said you were kind of like trying out Ethereum and then you felt like Ethereum
wasn't the answer. What was the what were the things that you felt were the shortcomings of Ethereum? There's only just one honestly, and 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 a page something like that. Let's say you want to build this on 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 called 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 go through an RPC provider like Infira.
Now this has 2 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 if you're a
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 it. If you're even blotching and then your system is no longer decentralized. I thought BitTorrent was supposed to be decentralized. Now you add a blocking in and now it's centralized.
This, that's the opposite of what you're trying to do, right? Like so, so like I was trying to build these systems in with every single launching it tried 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 that's 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, right?
If you're transferring entities on chain, if inferior lies 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 inferior for a day, it'll be of 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 blotching, then if somebody hacks inferior 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. 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, they don't have an
incentive to do that, right? But I guess I wonder if, if the would the issue be more something like, OK, let's say if, you know, I'll build this BitTorrent network that has Ethereum incentives and you 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 regular gym perspective, we don't want to like support this kind of thing.
So we're going to have to like through all the days to 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. It's incentive to stop you from selling Dogecoin. Like the whole idea is like if we 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 oligopolies that are controlled that that, you know, have a symbiotic relationship with regular 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 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 the 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 in fear of. So, for example, if we're actually doing, you know, dehydrating or like the current web 3 ecosystem, if you're isn't really the security bottleneck, because, as I alluded to, if if you're a lies to you about how many pudgy Penguins you have, how many ET you have, what's the
status of the pools on Guinea swap? The damage they can do is very limited, right? 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 inferior. Like there's no reason why I would hack inferior to troll people to say everybody has a pudging Penguin. Like maybe I would want to do that for fun. It's not going to make me a ton of money. Yeah. And and I guess the other thing I could also imagine happening here now in the example of like, OK, BitTorrent, like network is that of course some people not going to like that, right? Like let's say the whole copyright type stuff, right.
So I could imagine then then basically being like, hey, we're going to try to force inferior 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 inferior 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 in like Moxie Marlinspike talks about, right? I look up your public key on a blockchain and I use that to do into an encryption. Now if if you're a lies 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, so and, and it really boils down to when we're using these decentralized systems, we expect that we're trusting the block chains 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 where the security really comes in the blockchain and you're building these off chain systems like, you know, payment networks or you know, BitTorrent like networks and end to an 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 web for ecosystem.
The current web 3 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 kind of like out
of luck. But if you can't actually transfer the security out of it, then this changes the whole paradigm and makes building out web three and mass adoption everything way easier because you just need to look at the blockchain from outside when when you need to. So I, I really like what you said before, like, you know, if you had it truly free market, we wouldn't need all this decentralization. And I, I think that's a very
true point. And I, I think on some level, right, if you kind of zoom out right, like what is all this crypto blockchain decentral decentralization about? And to me, it's 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 the but I think that the rest of the Internet needs 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 get the web of revolution happening across the Internet and create. And this is like making a truly free market, right? Because you don't, you can't just only have a freeway 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, I would love it actually, if you can go a bit more into depth on, you know, the kind of like use cases that you feel like, you know, because you're saying, OK, this is the kind of thing that, you know, could really get us to like mass adoption and too much broader use cases and 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 case, 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 are user
focused. So let's just imagine an app like that. So the societal impact of this would be really big on because if we think about currently, how can you get people to work together, There are basically two ways. One is the kind of like a in a private, informal volunteer basis way. So I, I'm a person living in the US, 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, 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 structure, hire people, do something, some big thing together. And it's all very complex and it all very like it's really easily damaged or shut down by like random like political or like 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 permission list 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 like coordination what you know Bitcoin did to money transfer.
So you could imagine people working on things like let's say, let's archive all the books or let's, you know, share whistle blower information or or do journalism in these communities and it'll be both public, but also permission less and organic. While currently we have a dichotomy between if you want secure and permissionless and kind of like outside the, it cannot be shut down. It has to be low profile and private. If you want public, then that's like very like 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 and. Yeah, so the problem with something like Discord today is like, OK, if you, I, I mean, I guess so I guess one problem would be have 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, so that'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 get to 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 a in web 2 versus a truly permissionless application? And so, so if you think about this permissionless Discord, just like the actual Discord parts, let's forget about crypto or blockchain. 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 can't currently just can't do. And I think that what and and the thing about mail 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 like 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 a with like clients in a blockchain like mail, 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 on this called like confederal protocols, where I explore this concept where it is that we start with a model that we know how to build, which is, which is Federated message passing, which was used in like e-mail, used in Matrix, used in XMPP. And we simply had a very simple blocking layer to that. And we get like fully user software and 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 is not bound to whatever server you pick. And so you end up having the same user experience as a centralized app, except it's 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, it's going to have better quality of service because there's going to be a pure free market in the service providers that provide hosting for these two communities. So in because switching is basically 0 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 two or I guess with current Web 3
technology. 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, or is in crypto is always, you know, everyone's always, you know, people understand like kind of the, the importance of light clients, at least more or less. I think. What is, why is it so hard to have, for existing block chains to have good live clients And like, what's the, you know, what's the challenge around live clients?
And what do you, how do you do live clients and, and how come they're so much more efficient? And, 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 at work at the moment that 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 these properties for like any block chain or is this? Yeah, yeah. So maybe like talk a little bit about like the kind of the role of like clients and how the technical challenges around efficient like 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 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 like clients for existing L ones are dealing with the the the thing about metal is that because we're making a new layer one, we can design everything in a way that it's easy to prove to buy
clients. So, you know, there's a ton of things that goes into that, like putting everything in Merkel trees in a using a very simple UTXO model. The upshot is that it's 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 teacher proofs can compress this, but even without that, it's very
efficient. And I think that so, so this is one part like how 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 we're 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 that if you have really, really good like so you just, it's not just enough to have like clients. You need the like clients to, for example, be very, very light and you know, allow them to, for example, go offline for long periods of time without losing security. You combine a lot of these
features. You have this like super powered like lines, then you can build categorically different and much bigger and better applications than what the blocking 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 briancrane.com. You know, this mapping on chain and in your actual like chat client, you look up this mapping to see where, which server to contact to talk to this guy. So it's literally just this very simple little thing on the blockchain and you, 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 e-mail. And so Mel's insight is that if you have good like clients, you can start building things like this and you can 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 like, I think that's something that's hard even if you have, let's say, if you're like clients, because if you're like clients, for example, they have to be online all the time, they're not that light. You know, other block chains have similar caveats. So if you're like client, they, they tend, 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 light.
So that that means you can't build a system like this practically on these other watchings. But you cannot know and I think this is the key in section. So in this example of the the discord like thing, so the thing that you would put on chain, so you said a mapping of usernames. So let's say, you know, crane the air for some sort of thing like that. You'd you said the mapping of usernames and servers you put on. Can you explain that a little bit more?
Yeah, definitely. So, so let's just use e-mail as an example, right? So currently you might have crane bf@example.com and that's your identity. So your identity is 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 we 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 you? How are people going to know your public key, right? So, So what ends up happening is that you don't have good encryption and you don't control your identity and basically the the situations that the provider has sovereignty over. They see everything they own. You don't own your own yourself
like example.com owns you. Now let's just add to this e-mail system a very basic layer which is a mapping between crane BF, like a global username, not crane bf@example.com. So crane BF with an ENS like system map, map that to example.com comma your public. So you put that on chain. So, so, so here's here's what'll happen then.
Now when I want to talk to Crane BF, I just need to make send a message to Crane BF and my chat client immediately knows which server to contact and what public key to encrypt my message with. So I meant send the 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 anymore, so you switch. Great. I'm going to go to like foobar dot XYZ. So all I need to do is register an account at foobar crane DF at foobar dot XYZ, point my thing to foobar dot 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 in providers. You can switch with no cost and the providers don't 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, so you have so architecturally this is still e-mail.
It's literally just e-mail, but with this little on chain bit that the clients look at. And but because of this, then this whole system is user sovereign, end to end, encrypted and honestly decentralized. And trust us, it's Web 3. It's no longer Web 2 by the addition of this little piece of piece on the block. So I think this is really what
Mel is all about. You can start building these systems where you can sprinkle this like Web 3 Pixie dust on a on a traditional Web one protocol and you get something that's radically more secure, more user sovereign, more decentralized. And this only works if the the the kind of like off chain parts can compose with the on chain parts securely using white clouds. So we talked a bit about this thing of like basically the communication and to sort of community aspect.
What 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 send each other money, we can do business and create value and create things.
So what mail is really about is building the infrastructure to allow this kind of value creation that unlocks these opportunities of people interacting and building things that previously don't exist. So, you know, you could imagine some DAO on this discord like thing comes up with some really cool idea of some public good funding system, let's say, and they they're operating that. Well, that's a use case that's only enabled by mail, but it's not directly.
It's more like we have we build the infrastructure to let people interact. And that's just like the how the Internet works, right? The Internet doesn't, it's not really like Riverside FM is a IPV 4 use case. Well, technically it is, but it's not like IPV 4 is designed so that, OK, one use case would be Riverside dot FM. It's more like, it's such a general purpose liberating tool that allows people to innovate systems like Riverside dot FM.
And you know, of course you can think of specific things you can build on 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, etcetera, but truly based on you just pay your provider.
These are all things you can easily build within 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 secure 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 block chains is, you know, smart contracts and you know, Turing complete smart contracts and then build all kinds of stuff on that. Is that something that mail, 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 terrain complete smart contracts, even though it has a UTXO model. So you could do it on layer one. But I would imagine in the Mel ecosystem, most people would not be doing this in layer one. It would be let's say on AZK 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, you know, off chain where today you do it on train. 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 got to somehow fit it in, right? Mel's whole thing. And that's hard, right? Like 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 like that. I don't think that's like even if it could work, it's very difficult. It requires rewriting the whole Internet. Mell'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 Unchained logic whenever we need to, but not by using the blotching 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 know you'd want better quality phone calls. Base layer, you want, you know, pagers so that you're a device can buzz when you get a phone call. That's the job for the base layer.
Everything requires infrastructure level base 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, composed with other networks.
So it's actually decentralized in a way the Internet and then we can leave as long we can allow anything to use it across this telecom stock 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, we're going to see something very similar in Web 3, 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 you're adding CK stuff, improving throughput, you know, improving storage capacity.
And it's actually worse with box chains 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, you know, 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 can put things on it that need global consensus and you innovate and build protocols elsewhere, I think that's copying the success story of the Internet that really took telecom to like unimaginable new level by decoupling the base layer from the apps. So I think like that's how I'm thinking about where mail is going. And then so it's a, you know, the thing mail that you're building here, it's a proof of
stake layer one. So let's talk about this a little bit. So it's UTXO proof of sake base layer one. So for example, for consensus, how does the consensus work? Well, we use like a Byzantine fault tolerant consensus protocol called Streamlet. So I as far as I'm aware, we, 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 wanted 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 Streamline. It's surprise, it's shocking how simple you can make a BFT algorithm.
Like it's basically as simple as Bitcoins consensus, except it's proof of stake and it achieves finality. So we need finality for good like clients so we we pets stream. Yeah. And and then if you, I mean a lot of people will be familiar with tenement, you know which is I think sort of like the generally also considered like you know a very simple BFT proof stake system. So but stream that is even simpler? Or like in what ways is it simpler than something like tenement?
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 the 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 a kind of like a chain based BFT rather than a voting based BFT. So like, but but that's like
more of a technical detail. But I like I think that it's by far like the simplest BFT algorithm I've seen, and after I implemented I realized its performance characteristics were good enough for our use case, so we decided to use them. OK. 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, right 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 the Utxos. It's a bad idea.
Like that's, you know, like I don't think Utxos are the right model If we're trying to do a basically an accounts based on our contract model, we like 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 blushes that have tried that and I don't think it's a great idea. Now, why did Malik use Utxos is precisely because it's trying to do something very different from block chains like Imperium.
The the big advantage of the Utxel model that there's the reason why Mel uses it is that it makes all the state and all the data on chains 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 accesses 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 a 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 base 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 the UTXO model that's very different because the actual UTXO 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 your mapping in the structure of the UTXO graph. And then you can just look up that structure, traverse it with a 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 QTXL 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 clients. Because you can basically, I, I guess if I paraphrase it, if I get it correctly, I can in Ethereum, basically because you, you don't really, 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 effects like other parts of the chain.
Yeah, exactly. It's not explicitly spelled out. 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 yeah, and you can also trace your history back, you see, 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 sell like what 01010 is one that means Brian, whatever. And then that's where you're binding.
So you can do tricks like this because the UTML graph is structured data, not unstructured data. I mean, I guess one thing that it could be interesting to go into, but I don't know if if that's where we should go now. I know you also have this sort of low volatility assets, but I don't know if you should go there or if 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, that that might be interesting, but I feel like, I feel like the most interesting thing about mail is not actually kind of its individual technical parts, right? Because the thing about mail is that I think it's really easy to like misunderstand it a little bit as, OK, it has all these cool parts, there is a lot of cool parts, It has a different consensus, a different currency, etcetera.
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 a rental, which is this off chain data and money transfer layer that is built on Mel. And that'll really be the like protocols like a Rendell are actually where the ecosystem is going to be built around, not like apps building on layer one where like people running nodes 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 that how do you make a blocking that you can use to build systems like, you know, a Rendell, like you know the discord thing I mentioned so. Yeah, so let's talk about air Rendall.
What's Air Rendall? Well, how so Air Rendall is like, if you think about, OK, so the I think air Rendall can 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 Tor plus Lightning Network. So you know, you can plug your app back into it and send data across or send money across and it's all off chain and fast
there there. But then there's two big differences between Air Brendel and Tor plus Lightning Network. The first one is that the nodes are incentivized and the nodes are incentivized not through like a deep end 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 set of 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 like protocol that coordinates all these prices. People find peers that they're willing to peer with app prices they're willing to accept. And the second pillar is that Air Brindle is the first peer-to-peer network designed to be censorship resistant against ISPs. And this is actually really unprecedent because we think about censorship resistance a lot in Web 3.
But we typically mean the other nodes on the network cannot censor, right? Like Monero nodes can't pick and choose who gets through. We don't mean the ISP can't stop you from using the protocol. They can't ban the whole protocol. And this, this kind of censorship resistant, I call band resistance, which is like it's resistant to ISP 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, we're trying to build permissionless assistance here, right? We're not, we're not saying, OK, we just don't, we, we don't test our bank, but we trust our ISP. That's not what we're trying to do. We're trying to build permission lists that and that means we need to be censorship persistent
against our ISP as well. And so Arundel 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 obfuscation, in censorship persistence to build the world's first decentralized ISP, censorship persistent on transportation network. So that's really what air rental is, is at a high level.
And that's only possible because we can build on top of smell like, you know, the micro payments go on payment channels, kind of like Lightning network, but settling on Mel. And because Mel has much better light clients, we can do so without forcing people to run heavyweight infrastructure. You know, 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 mail, you can use build, build 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 mail, but basically the incentive system and the kind of like security systems, they're all built on top of mail likewise. What's the state of the project now? Like what, what have you built and like where are you sort of in in the road map to making
this happen? Well, like currently for AR rental, we're currently in an alphabet kind of situation. We have like a few dozen nodes running, a lot of them run by community members and overall like we're that's the current focus of our development. So we're quickly iterating upon of it upon it. We plan to launch the air rental network into production later this year. And then launching a rendall into production.
That means. But that's that comes before because the male proof of state chain is not in production yet. Well, the male proof of state has a def net right? That has been public for several years. So the initial version of a Rendall would run on the male def net, but eventually we're going to upgrade that dev net into a main net. So like a dev net, what wouldn't be shut down, it would just be relabeled as the main net once
it's ready? And what's the what's the sort of difference between the dev net and the point when it becomes a main net? Well, I think the biggest difference is that right now we run all the validators, we nobody else has any tokens like. So that's the main difference. Once we actually decentralize the token ownership and allow other people to learn validators and decentralize that, then it becomes the main. Yeah. OK, OK. 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 mail, but kind of in the overall road map of the project right now, is it we're not 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, what launching the dev net is like closer to the last step,
right? It's ready to develop. With mail, 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 AR rental. So I think like the how we're going to do it is that we're going to first launch AR rental with a big use case for AR rental, which is actually GEF by VPN project will turn into a
front end for AR rental. So I actually move all of my users from GET into the AR rental ecosystem by just upgrading their software because the user experience is not going to change. They're just going to be using a Rendall. And that's like about, you know, half a million or more daily active users. They're going to be using this first big use case of a Rendall.
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 a Rendall, building new applications on a Rendall, building other protocols like a Rendall, using it as a example. So I think by 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 IPV 4, it's not really ready to build things on. But once we had e-mail, once we had TCP IP, yeah, that's when the developer ecosystem started for. So I mean you mentioned the the VPN, right? It's called GIF, so Arundel basically would would be able to perform all of the 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 Arundel, you're also able to host websites anonymously and also browse other websites that people host on the Arundel network and also send money to each other. So it's like a general purpose communication and payment network and then yeah, it's like a super set of what VPNs are able to do. OK, so so you can host website anonymously of course you know we were like aware of the example of that is like Tor today, right where you can. 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 a URL like the hosting websites anonymously, they also wouldn't have, you know, normal, it's not going to be like WW dot, like whatever, but it's going to have its own domain names. Yes, so in Torah for example, you have this long string of characters dot and that encodes your public cheap. And now the cool thing is that because we have male like clients, we don't need to do that.
We can just be a short human readable name dot haven, which is what everyone uses because, you know, we can store a naming system then like as I, 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 is also a potential use case or interesting use case will be kind of, you know, replacing or competing with Tor. Yeah, absolutely.
I think that like ambitiously, I feel like air rental is going to kill Tor, 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 Tor 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. And like, because why would anybody else actually do this for free? It's a lot of bandwidth, a lot of risk. So like the, I think it'll, it'll definitely have better performance than Tor because it's also not going to be always overloaded because of this
incentive system. It also the the application scope is much bigger than Tor because Tor is really just focused on one particular kind of anonymity, while Arundel is actually designed so that the user can select how much anonymity they want. They can get Tor like anonymity, they can get much better. Like Nim for example. They can use mixed that delays to get 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 vendor 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. So yeah, I think like that's I guess what Arundel is, it's
really doing. It's kind of like combining what people already do with Tor with Nim with their regular Internet, with other peer 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 sable 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 medium 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 mean coin in disguise. Nobody uses Bitcoin as the way they use dollars.
And so like, 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. And 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. It's 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, right? And that's the reason why it laid melt the currency. And the objective here is that I, I don't want to I don't need to make a stable point. 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 tags it reasonably.
So you want the price to look something like U.S. dollar to euro rather than U.S. dollar to Bitcoin. And you also can't use oracles because that'll make it non decentralized. And I realized there's nothing else in the ecosystem like this. So I sat down and made 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 Dusk, 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 dusk 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 cost 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 A0 knowledge proof that you did a bunch of nested hashes, which has to be done sequentially. And then you can prove, OK, I did this many hashes in 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 the Oracle for this. You can 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 could get an exchange rate between your token and time and then you can use this to drive a stable clean mechanism so that roughly 1 token equals 24 hours. Does that make sense? Yeah. But does that mean is it, does it mean it's basically kind of like a proof of work as it's still because like to get it, you, you do the, 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, 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 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 in typical proof of work, the way it works is that you're printing these tokens and people kind of like divide up a thick supply by how much like proof of work they do. And you know, if the token goes up, then like people waste eat more and more power like competing over this same pole of tokens with metals approaches more like if you do this much computation, you're guaranteed
this much token. 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're still going to 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 cost them, you know, $1.00 to produce like one token, someone else. It cost them like, you know, 90 cents or eighty cents or something like that. So 80 cents guy's going to mint. The $1.00 guy's not going to mint. Right, right, right. And then the $0.80 guy is going to mint, mint, mint, mint, mint until there's so many tokens that the tokens worth $0.80 and then she's going to stop.
I mean, I guess you still have kind of the downside here that, you know, if now male gets a lot of adoption, a lot of usage, then it still means that a lot of basically it's similar amount. Or I mean, let's say now the male tone 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 1/2 or whatever to get those, to get all those tokens in supply.
But that's the case with any system because if, if, if your EMS market cap goes up by 5 billion, you got $5 billion of USD going to like Kraken or other exchanges and it's the same thing it. Was not quite the same thing, you know, because if your price goes up like then, you know, everyone's richer and like you didn't, you didn't have, if the Ethereum price goes up and now it's 5 billion higher, OK, there's looks a marginal buyer that will like bought at a
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 count. Yeah, that's true. That's true. But like I think the thing about Mel is that anyway, like if you actually read the paper where I describe it, it's not exactly that you have to mint out every single mill. It's more like this minting process establishes a price feed for how much does a market value mill.
And if we need to print more mills, the protocol actually prints more mills and you don't need like the amount of minting doesn't increase substantial in that situation. Like the minting people only indicate to the protocol that hey, mail currently is overpriced, print more mails where mail is currently underpriced, stop printing mails. 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 say token. Yeah, right. So basically in the case of how the mail supply increasing a lot, does it mean let's say now it goes from zero to 5 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 same token and exchanging it for mail?
Exactly, Yeah. So then it sort of also means that a lot of the value of the growth of the sable coin or you know the the mail market cap would be sort of absorbed by the same 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 read validators, you got fees that are all denominated in mail as people use mail. So the more people use mail like, the more value accrual accrues to SIM.
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 state token or 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 state token is different from what's good from the currents. Because for a proof of state token, you want it to be like Accrue Valley, you want it to be fixed supply.
You want it to be like, if I own 1/3 of the network, I always own 1/3 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? 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 to the validators, right? For, you know, running infrastructure. So if it's a fixed supply token, you don't do that here or like.
Yeah, I don't do that here because if you think about it, right, like inflation's not free money, inflation's you're really imposing a tax on everybody else who's holding the token, and you can just express that as a fee or 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 like this, 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 the 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 as with the actual social value of the Met Mel 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 block chains, but yeah. Cool. Maybe else you want to talk about? I don't know, there's, there's a lot of other things, right, Like, for example, how like air Brendal 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 gaff will turn into an air rental front end. But I think like the bigger thing there is that once you have a lot of users on air rental, then you have a ton of demand for anonymous traffic relay on the air rental network. That means that you had the listener. If you write 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 Arundel 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, 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, across the border, you're going to make a ton of money by serving the air rental network. So we're really, what air rental 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 air
rental. Cool. Well, thank you so much Eric for coming on and and thanks for walking us through it. I think that was really great and I think gave a really great overview. I do think this is one of the most yeah, just like regional projects, right. So they're really trying to think through things from from a sort of, you know, fundamental design perspective of like what we actually want to do with this. And then, yeah, so it'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 mailproject.org. You can find all the links to the right things there. So if you join at Discord, we have a lot of live, lively discussions about research in our protocol development. Just join the conversation. Cool. Well, thanks so much, Eric. It's really great to have you on.
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 guest 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.