Inside Solana: Near-Death Brushes and a Need for Speed (with Solana)

Transcript

[Music] Welcome to Web 3 with A16Z. Today's episode features Salana co-founder Anatoli Yakaveno in conversation with A16Z general partner Ali Yayya. Recorded live at our CSX crypto startup accelerator program earlier this year. Anatoli shares the origin story of Salana from a late night Eureka moment to thousands of investor meetings and several near-death startup experiences. He talks about what it took to get the network off the ground, how his engineering background at Qualcomm shaped its design, and why a need for speed gave Salana its edge. They also get into developer culture, engineering trade-offs, and what differentiates Salana's approach to building, including

its willingness to ship, iterate, and rethink everything, including most recently its consensus algorithm. As a reminder, none of the content should be taken as investment, business, legal, or tax advice. Please see a6z.com/disclosures for more important information, including a link to a list of our investments. [Applause] Hey everyone. Hey guys. Thanks for joining us. For sure. Thanks for great to have you. I don't know if you remember when we met. Um I think it was in Berkeley, one of the events. Yeah, exactly. It was uh 2017. And I had just joined A16Z. I was a very junior VC and

I think yeah I was Berkeley Dons had like a panel. I think I was on the panel. You were in the audience and then at the very end of the conversation we we had like a very short interaction and then after that and you came into the office. We had this meeting with Dan Bonet who's a professor at Stanford and kind of we went through all of your thinking for Salana at the time and then we passed which was like a huge mistake. And I actually pulled up the pass note that I sent to you at the time and I I had said this quote from the pass note. I said, "Our sense is that Solana's fully predictable leader schedule combined with its probabilistic finality and its lack of strong disincentives for double signing like slashing conditions will make Sana less robust to Byzantine

actors. The likelihood of denial of service and/or bribery attacks against elected leaders to either censor transactions or mount roll back attack seems unacceptably high, which is classic junior VC being overly caught up with like kind of the weeds and the implementation details and missing the big picture, missing the fact that you were a hardcore founder who was not going to give up at anything that would like kind of continue. Bad at sales is what he's telling me. I don't know about that. I think I take a lot of responsibility for missing the seed round of Solana at that time. But do you do you want to tell the story of of that time like the moment when you decided that you wanted to do this and then what

it was like to get started? For sure. So I spent most of my career at Qualcomm. I landed there straight out of college and in college at a startup working a voice IP which failed because we were in the middle of Illinois after the dotcom crash building like a Vonnage thing. Vonnage didn't exist yet, but I was super into performance optimizations. And they kind of hired me in the spot. And I was really into optimizing like low-level code for mobile and surfing and playing in a hockey and doing iron man triathlons. And like that was my life for like 14 years. And for some reason, my wife and I decided to move to SF. She wanted to switch into tech. and

I landed in SF and it hopped from Meosphere to Dropbox and um I always had like since I was 16 always some side project. So I was always building stuff. I think this is kind of the now that I spend like a third of my time investing the type of the founder that I look at are like people that are like busy. They just can't put stuff down. In 2017, me and Steve Akridge, who I spent a decade at Qualcomm with, we did Iron Man together. We played underwater hockey at like a US men's level. This was like my go-to person. We had a side project putting up GPUs in Hurricane Electric and mining crypto with them, but

building an API for deep learning. This is pretransformer paper. We're just like geeking out on neural networks. And because we were mining crypto with it to pay for the hardware, this is how I got into crypto like as an engineer. And I was kind of trying to figure out why are people paying me these astronomical amount of money for running the stupid software that does nothing. And I had two coffees and a beer cafe sole and had this Eureka moment that ended up my own rediscovery of verifiable delay functions things that like folks at Deon was working on you know but I couldn't Google for this like there's no way you can come up with the

term verifiable delay function on your own and there was not a lot of stuff not very googable yeah not very googable and thank god for that because then I thought that I had something really really really important that no one has discovered before that is interesting thing. So, because I couldn't Google for it and find smarter people than me working on this, I thought I had like a secret nut that could help me build something. And the intuition that I had because of my careers at Qualcomm that if you have a source of time in a network, you can build time division multiple access, which is if you remember is like the first cellular network layer built in the 80s. And this is very analogous to like if you think

of Bitcoin as Aloha. Do people know what Aloha is? The basic problem in in like physics and radios, you have two towers transmit at the same time or the same frequency, you have noise. If you have two block producers make a block at the same time, you have noise in the network because you have two heads of the network. So the first dumb protocol people came up with was called Aloha in Hawaii. you produce, you send out your signal with your towers and if you see you're getting interference, you retry in a random time. So it's very inefficient. It doesn't utilize the channel that you allocated for that network, the amount of frequency and bandwidth effectively. So with time, you give each tower a clock and they alternate by time. So they can only

transmit at their allotted slot. So because I thought I discovered this secret unbreakable source of time that is totally decentralized, doesn't rely on a central provider, I thought I had this like thing to recreate Bitcoin but much much faster because it can utilize the entire bandwidth allocated to it. There is no this random backup thing. Mhm. It was very hard to articulate this. So when I was trying to like explain this to Ali and stuff, I was using terms that are not crypto terms, not academic Byzantine fault tolerant terms because I'm coming to the space as like a optimization engineer and we did a lot of things wrong in our design.

Everything he actually said is true. There's a lot of problems with spam and Byzantine like attacks and leaders and stuff like this that we had to solve later on. But the unique thing that we did figure out was that these networks as academically designed at that time in 2017 had this problem where you had really poor channel utilization. You allocate everyone 1 GBTE or 10 GB networks. They cannot produce that much data in blocks because they have to constantly stop for consensus or they have to randomly back off. And the unique thing that we discovered was that it is enough to solve that problem to solve scalability in crypto. You don't

need to go build shards or anything else that was fancier. I think had I like expressed that understanding of the problem that way and said we can solve all the other challenges, they probably wouldn't have passed. But me as an engineer, I was so hyperfocused on the implementation. I didn't know how to sell what I had. This is something that I learned later on is like you have a solution that solves a problem for your users. If you sell them the implementation, you're not going to convince them that you've solved their problem. You have to actually understand the problem and solve that that you can fix that. That was like my first experience at selling was raising money, which is a really good founder experience. The reason I was at that

meeting in Berkeley was that I had a kid and my wife knows me really well. So, she gave me an ultimatum. You can't have a side project, a child and a job. You have to pick two. The child is mandatory. So, I had to pick either the job or the side project. So, I quit. I had six months to raise enough money to where we had income and stuff. I could pay myself a salary. And that was the motivator for me to actually go raise. And my strategy for raising was like to go to every crypto event, talk to everyone there, try to find anyone that's associated with capital or whatever. And this is how I like bumped him to Ali. I just

heard him. I didn't know he was going to be there, but I went to every event and I overheard him say something about A16D and I like sunk my claws into him. Here's my pitch. You got to hear it out. Yeah. Um, and it literally took me a thousand meetings, I think, to get a seed round check, like enough capital to form the team. Yeah. Is your wife also an engineer? Yeah. You framed that as a trilemma. Yeah, exactly. That's amazing. Well, what what did you think would be the biggest challenges at the time and then how does that compare to what the actual biggest challenges ended up being?

We thought that the most useful application for these things like I didn't want to compete with Bitcoin because I think it's kind of a very special snowflake. There's no way to engineer a better Bitcoin and the way that it creates value or creates price for Bitcoin. It just there's no rational way to do it. There's no discount future cash flow model you can apply to Bitcoin. And the thing that I did understand was at least the smart contract platform. But having spent my career working on operating systems in mobile, I kind of understand this as a environment to build applications, it's very constrained, similar to like early days mobile where you have 2 megabyte devices. So you're very memory constrained, you're very CPU constraint.

And I could solve that problem because I've done that before. So we hyperfocused on that. And the thing that we thought was interesting or at least I could backtrack this is how this network could make money was trading. Because if you have trading, you have an opportunity cost to being late and therefore you'll pay more money to be first. And at that time, I kind of called it arbitrage or triangulation. The more markets you have, the more trades you have, the block producer could make money off that by simply being the primary broker, whatever you want to call it, for that slot. So, we focused on trading, but we had no clue that meme coins were going to be a thing

or NFTs were going to be a thing because of my background. We tried every crazy idea. We pitched to Dish Network to sell bandwidth for 5G networks dynamically because you need like a lot of towers to actually saturate the US with 5G networks. We pitched every random fintech like all sorts of random stuff. The first SDK was like written in C if you can imagine that. We basically had no idea how to get users. This was like the biggest challenge. And outside of like building the network and get it booted and running, which I knew we were going to get done because I hired a bunch of engineers out of Qualcomm that I worked

on really really hard problems with for over a decade. So I kind of knew it was going to at least work. But getting users for that was really really hard and that was my job. So like I had to both code and figure out where do we get users. Did you start out thinking that you would build a better Ethereum? Were you thinking of it in those terms or was was it completely different in your mind? No. Like as soon as Vitalik and Joe Luben started talking about global settlement, I just thought that was really boring. like a part of one of my side projects, I was trading options and forex and stuff across like a bunch of random like interactive brokers in aw.

And the part that's interesting is the execution. It's the trading. This is where price discovery happens is where like I felt as a user of those systems that I built an algorithm that worked in back testing but then when I actually deployed it my trades would land a little later my data would arrive a little later just at that point where the algorithm should be making money. So I felt like I was at a disadvantage because I'm trading very very small amounts just for fun, right? But I didn't have the same access as I would to like the Linux kernel internals in an open source environment. Yeah. Cuz I didn't know how like it's all a black box that's controlled by somebody that's

giving their biggest customer preferential treatment which is as they should, right? They're running a business. Mhm. So my motivation was kind of like revenge or if you want to think of it, we can focus on trading. I know how this could make money. So if we're even moderately successful, we won't run out of runway and I didn't even think of Ethereum as a competitor. Got it. Do you feel like your vision for what Solana is has changed a ton or has it remained fairly constant since then with the same Northstar? It's remarkably been the same which is surprising to me that like with so little information and blind luck I would say that we turned out to be like

somewhat directionally right. Well and one of the inevitable things for all startups is the fact that you cannot build a successful startup without going through significant ups and downs and then you've certainly had your fair share. Uh do you want to tell a story of one of those moments and how you powered through? We had a bunch. I mean end of 2019 we had like about 10 months of runway left and the network could stay up for like about a week. What would happen after a week? Would it would uh would it halt or would Yeah, there would be some crash like some bug that would like many of the consensus bugs or whatever would get triggered. We did have a pretty good red team trying

to crash it too. Thank god we found all those bugs before we launched. So I had to make tough decisions. Then we basically shrunk the team. Kind of listen to a lot of the advice that you hear from startup books. If you're going to cut, you cut deep to the bone to where you have enough gain and runway that it gives you one or two more shots on goal. I also tried to raise I went to China January 2020 and like Asia and stuff was sick in the flight back as a dog.

to to raise like maybe $2 million out of our validators which plus the cuts gave us like 14 15 months of runway. Yeah. And then miraculously the network started staying up more and more as we kind of went through the the obvious bugs and around March 2020 we decided to launch. We announced our auction and 3 days later the entire world collapsed. This was like the S&P dropped a bunch, Bitcoin dropped to like 3,000 or something like that. And basically all our investors and stuff that we talked to, they didn't know if their funds were going to survive. So, we were kind of in

this decision moment. Do we delay? Because we did have enough runway to delay. But my theory there was that the worst time to launch is right before the crash. the right after the crash. I knew if you launch the token isn't going to do spectacularly well. So, you're not optimizing for that. The benefit of launching after the crash is that the global markets are going to recover. And they gave us an opportunity to be first to market. And two, I think crypto is unique in that if you have a token, a large part of what you should be optimizing for is the early supporters that get that token early on. And there's no better opportunity to do that than after like a big global crash

because people that go in and buy that token at that time are the dieards. They're like the crazy people that are like believe in the product. They for some reason ignore all the global negative market conditions and they still want to back you. So like that a lot of projects that you see launched that are optimized for low liquidity, high FTV end up missing this and kind of create this negative overhang that doesn't build like a strong community that's just really really hard to overcome. Yeah. One of the best community building tools is having a monotonically increasing price curve.

Yeah. And uh then every user whoever buys is in the money if if that's the case. And if you if people are buying in and coming to the ecosystem at an all-time high then so around our break point in was it 21? Yeah, 2022 I think we had our conference that was our biggest conference of the date like 3,000 people showed up. It was packed. We had a developer event with like 1,800 devs which is nuts. We had like showcase of 50 game development teams. Like it was great. And on the flight back, a whole FTX show happened. Token price started collapsing. FTX blew up.

It was like all the VCs in crypto, not you guys, but like a lot of kind of the mid-level VCs were like, "Solana's dead. There's no point to launch on it." They were telling teams that they invested in, they were building on Salana to switch to other chains. And my biggest fear was that a bunch of the teams that were building on Salon actually had their capital in FTX because if their runway was parked there, it's gone. Yeah. And that means if their runway is gone, there's no products being launched. That was like the dead in the water moment.

Because we always kept our team small and like I still had that mindset of we only have 10 12 months of runway and the tokens were only worth a dollar. Salana dropping to eight bucks just didn't matter. It was still infinite runway for me. But like it was really terrifying that the teams building in the network would be catastrophically hit. Luckily, they were pretty smart. Vast majority of them kept most of their funds and banks and stuff. Then the banks collapsing was like a whole other story. But that was just like the terrifying moment. And the reason we survived that is because the teams that we picked up in the early days were building on

Salana was like a buck and to them it dropping to eight sucked, right? They had to change their expectations. But like that growth year that we had when Salana was low priced allowed us to onboard a whole bunch of people, developers, builders, bug bounties that were given out. All that stuff happened at that very early stage of capital formation on the network and community formation. So that those early pains of us struggling like really really did make a difference in the later stages. What was it like leading the team in those moments? Having a co-founder is really really important that can complement you. So I like get into loops where I drink too much coffee and I

start pacing around and kind of like arguing with myself. Raj is very much like an ER doctor kind of personality. He lives for that moment where everything's on fire. So, he was able to actually structure my fears and thoughts and then go on get on calls with investors with people building in the ecosystem and make sure that folks are actually like still focused and on track. So, I would say doing it alone is hard. There's some people that can do it as founders, but during that like 2020 where everyone was remote, Raj and I were kind of on a Zoom as soon as we'd wake up till we go to sleep. Um, it's like 24/7 just staring at each other.

Like having that kind of co-founder relational support Yeah. is pretty important to get through the the hard days, I think. And how was it keeping the morale of everyone else high? We always had a very small team. I think that's kind of a big advantage. The rest of crypto was in a major downturn too. It wasn't just isolated to Solano, but we were hit a lot more. And for some reason, we didn't have any attrition. I think it's because the team was small and everyone felt like when you have a small team and you have a lot of work to do, that eliminates most of the politics and actually eliminates most of the unhappiness. Like I think people get unhappy when they don't feel like

they're making impact. It's actually that's basically the most key thing when you're looking at are your employees happy or not is like the work are they doing? Do they see it? Get to product and actually change user behaviors and like that kind of loop is what drives people. And because we were small, people felt like we got hit really hard, we didn't die, and they could fix it through their work. And that really keeps people happy together. Yeah. And being busy eliminates any air time for illumination and for kind of going down emotional spirals. Yeah. It's a CEO's job to eat all those emotional spirals for the company. Yeah.

I think one of the most epic memes or marketing campaigns in the history of crypto is that video you guys launched of uh Agent Smith unloading a cartridge into Neo. Neo being Solana at $8 and then his recitation and course that was all organic. I don't think it was Oh yeah, it wasn't. That was excellent. And if you guys haven't seen it, we maybe can send a link, but it's it's excellent. All right. Well, so what are all of the ways that Solana is better than Ethereum? Everyone at the products level, at the foundation, at the engineering level like Fire Dancer can make the chain better in the next release. This is like

something that we're hyperfocused in these like incremental steps and improvements which is I think very different mindset than let's research the perfect cathedral and then make the implementation in Northstar and get to it. We're more about there is a behavior change that we want which is like we want everything traded in one giant global state machine. the implementation details are less important and we can incrementally get there and like every release unblocks some thing for a developer makes the chain faster increases capacity or it's a blocker that kind of stuff. So we're very much like iteration based software development. The proof of history thing

that I came up with which I thought was a really brilliant thing. We're now blessed enough to hire really smart consensus researchers. And the first thing they told me is to get rid of it. And I was I felt like relief. I was I was happy. We don't have any ego about any specific way that things should be built. It's about solving a user problem. And they they clearly showed, hey, there's a better way to do what you guys are doing. We get the good things that you guys built and this is like a better version of this. So that kind of attitude is very different like I think we would never come up with like an L2 ccentric roadmap because that's an implementation detail to solve an unknown user problem. Well, we were

actually just talking about before we started you were telling me about how you're working on swapping wholesale consensus algorithm for Solana. Is that something you want to share about? Yeah. It's actually easier to do this than to change RPC APIs because this is deep low-level code that only touches a small number of engineers and when you have a lot of users and you break an RPC API for you know a lot of applications and users depend on that revenue that is actually harder to do but it is painful for you know five engineers are going to suffer for the for this year but that's different than all your customers suffering like downtime or outages or like an API breakage when you upgrade.

Yeah, I do feel like this is one of the key things that differentiates Solana is the fact that you guys are willing to continue to move fast and make extreme changes to the protocol whilst the kind of the plane is in the air. when they're swapping the core engine. And so maybe back to what you were saying about how like iterating quickly is one of the one of the key things that makes you different from other Yeah. This is uh probably again my experience as like a software engineer like software is never done like it dies when it's frozen. Mhm. Because as soon as it stops like hardware evolves at the very low levels, the timing and cost function for like AVX1 to AVX2 is completely different.

And that subtle change in Intel will change how you write your software because now you have to implement batching in a totally different way with a totally different memory model. All that stuff percolates up to the API layer. Like at the end of the day, the silicon and the physics limits that we have that people iterate on at DSMC, at Intel and stuff, that's the real thing. That's the magic. And the software part we need to change to express that magic up to the user. And if you freeze the software, it dies simply because the problems that they're solving on, they do their best to be backwards compatible, but like the new stuff is always going to be different. And you have to really kind of rethink how the plumbing drives all the way down to the

silicon. So this is something that I felt like we can never really freeze development as long as hardware keeps improving. Well, along these lines, if you were to redesign Solana from the ground up today, knowing what you know now and knowing everything you know about building Solana and then everything you know about other tech like ZK proofs and things like that, would there be any major differences to the design that that would be difficult to build into Salana today that you're not already kind of working on towards um I wish we used BLS signatures for consensus.

There's like minor details that are like now a huge pain in the ass to change. Have you told Dan Bonet that he'd be happy? Oh, yeah. I mean, the the next version of consensus uses BLS. It was just Oh, nice. At the time, BLS was barely getting standardized, so we picked something more stable. There's like details like that that I feel like have been painful to work around cuz that's your legacy tech that you kind of carry with you. But at the time when we made those mistakes, we knew we were making them and we made them to unblock a launch or a partner or whatever and that was important. So like this is something that I had to tell the team to suck it up and ship this over the weekend. And sometimes you have to kind

of just do it and like when having a small team and small runway gives you that mentality that if we solve these problems today and we get PMF, we can hire people and they'll be their problem. But to get to that stage, you need to unblock your users today. you need to get them to go ship products and do stuff. So, you got to kind of suck it up, kiss a lot of frogs to like get to product market fit. So, there are no major changes you would make. I mean, we were we were so wrong about like a bunch of stuff, but that was like path dependent. Had I tried to build everything correctly at once, we would have never shipped. This is like the

fear that I have with like going back in time like getting it right would have meant that we wouldn't have shipped because it just takes more work. Yeah, definitely. Well, this is a a thing that's pretty common is like the second system syndrome where like large companies build the first version of the system and realize all of the ways in which it's imperfect and then they decide that they're going to reimplement everything and build the version two which will fix all of the problems and be perfect. And then those those projects tend to fail because they try to be like the god thing and then they miss all of the knowledge that is actually encoded in the first version and then they throw all of that out and then they encounter different problems that make the second system harder. So the benefit that I had I think out of a

lot of my competitors was that at Qualcomm I've built four different systems. So this was like my fourth or fifth one. And uh by that time I was like just use whatever is the fastest to ship. Yeah, I didn't care cuz like I've built the crappy thing that launched first which was like Brew 1.0. This is binary runtime environment for wireless that Qualcomm built for mobile. This was one of the first mobile application things. We just shipped it as fast as we could. Then we fixed a bunch of bugs in two. Then we tried to build the perfect system for three that never shipped.

Yeah. And then I got thrown into Android and it was like just ship the fastest thing to unblock Samsung or whoever because Apple is killing us. So I went through that cycle. Yeah. And it's it's usually after you fail in the cathedral that you can be humble and tell people like if you don't ship this thing like I know it's not perfect. Yeah. And I know what the perfect thing is. You guys have to ship this or we're dead. Yeah. That's a that's a good lesson. All right, I want to open it up a little bit for questions from the group. Just two quick questions about community. One thing I've noticed with Salana, you guys are really good at like your events,

your hackathons. It seems like really well put together. You guys invest in that. I'm curious specifically with hackathons, do you guys see value in continuing to do those events? Like do you invest in those companies as like a maybe like a VC type situation? are you seeing those those hackathon participants build meaningful projects in your network and then two community around like cross protocol like standards or like getting into more enterprise how do you view Salana's future and actually trying to bring outside groups together to like crush a protocol like web a like something that Bitcoin or Ethereum could also use so for both I wanted to be really focused on some measurable KPI that ends up being useful effectively Like the only

way the network survives if it makes enough revenue. The revenue comes from priority fees. So we need stuff traded on the network and that stuff is tokens. So the hackathons the primary goal for them was to get and output companies that are investable by somebody like we didn't want to fund all of them. So the goal of the hackathon is to surface projects, teams that you can invest in that will eventually hopefully ship a working product and a token because that's how you effectively get some kind of revenue back in the ecosystem. Same thing with like standards.

I really want to focus on standards that unblock some products. So like token 22 is a standard for like real world assets and a whole bunch of other stuff. We had a customer, this was PayPal, that wanted these requirements. So for us to build as a one-off would have been like a waste of time, but we could capture their requirements and understand like, okay, this is a big fintech company that probably have similar concerns to everyone else. How do we generalize them and make it like a piece of open source software that everyone can reuse and give that away and hopefully accelerate their business development and stuff like that? So that was again thinking backwards from we need stuff on chain that generates revenue.

Was your choice for the uh Berkeley packet filter from your your time at Qualcomm? Just wanting to ship as fast as you could. Yeah, the alternatives were WASM or like thumb which is an ARM instruction set. The reason why we didn't go with WSM was I worked a bit with Google via Android and their teams rug you on tech. like they're not committed to a specific technology vision. They're committed to like Google's vision for generating ad revenue. So the Linux kernel guys like will say no to most features. So they're not going to rug us. They're not going to make BPF slower in some crazy weird way or add features that nobody needs. M so it was the smallest set that I felt

was stable, well understood, that was safe to run in ring zero which is like inside the kernel which is as close as we can get to smart contracts level of security. So, WASM is like, you know, you ship a feature, your browser crashes, you don't go to the website, nobody cares, right? Google's not going to have like a fire from that. But like you ship a BPF change that allows like a memory exception in the kernel. That's bad, right? There's just a lot of push back there. If Risk 5 was like stable at that time, we probably would have gone with that, but it was still like nobody was really using it. What do you think of Ethereum's last metallic post on switching the EVM to Risk 5? I don't

envy the engineers trying to make the backwards compatible. That'd be wild. Yeah, max maximum pain for like a dozen people I think for two years. That would be my guess, but it's doable like and probably should be done. I had a question about like Salana in the beginning was kind of hard to use and how did you prioritize teams that you support and I imagine the support was also being on a lot of call to them debugging sessions and like you just have limited resources so how did you basically did that is a weird way that it's like despite developers and projects being our number one customer

the number one customer is the end user. So if you think of priorities of whose problems we need to solve, it's the end user using the chain is the number one. Then it's the developers, then it's the validators, then it's our internal engineers at the bottom of the priority thing. This is what I tell my team is that you guys suffering right now is what unlocks users. You should suffer anytime you can like help a user. So developer pain is less important than user pain and user pain is high fees, slow confirmations, that kind of stuff.

So if we fix that decisively, the developers are willing to eat pain and sacrifice their own pain for their user. And this is why we were able to get developers to overcome the friction of getting on a new platform that was extremely raw. Like to build a smart contract on Salana at that time, you're like writing like a Linux kernel driver. So it was very painful but because it's software and developers are lazy they will solve the problem once and then write a library for it eventually like you kind of overcome those problems. So I wouldn't if you're building like a developer platform anytime you can like make devs suffer that helps the user you should make the dev suffer

cuz like the the hard problems we can solve any of those problems over a weekend. there's a developer that's blocked because they don't understand or build some API or whatever, I can code that up over the weekend. But if there is a a fee spike on the network due to like not enough capacity or some broken economic thing, that's a six months project. Like it's just impossible to solve those. So anytime you can prioritize those things and get the stuff that takes 6 months to fix out early, you should do that over anything you can fix over a weekend. It's like another way to think about it. What's your take on the evolving landscape of layer ones and competition from newcomers like Monot?

So, we were like the 2020 crash was actually a blessing cuz I didn't have enough runway to like delay. We just launched and we launched earlier than a lot of our competitors. Binet Smart Chain wasn't even out yet. So, we had this 3 4 months window to just get enough users and kind of establish Salana as a fast chain. And the difference between Ethereum and Salana was significant enough to where it could change user behavior. Like if you're an Ethereum user and then you tried the same, you know, memecoin trading on Salana, you're unlikely to go back to Ethereum. It just takes more to activate you to back. So now there's faster chains that are more optimized, but the confirmation time going from like 1

second to half a second, is that enough to change user behavior? And that's the big unknown. I don't think we've seen use cases where that's true yet. I think for trading, if you look at like E Trade or whatever and you actually go through the UX flow, it takes multiple seconds to actually go into the trade. You submit it, then it shows like cleared or whatever after a couple seconds. It's much faster than Ethereum, but it's not instant where the user is getting their trade filled right away. There's some applications that depend on that like I think like vector and stuff but that difference between one and half a second I feel like is important to backend providers like market makers and stuff like that which has impact on the prices that the users will pay at the spread

like these are like basis points so it's not I don't think it's enough to change user behavior but we'll see we need to see applications that really really only work in monode and unlock a new user change that drives people there. That is so much better that you can't do on Salana. And we need to see them fast enough in the market before Salana improves because basically every release Salana gets a little faster, the hardware gets faster, the block capacity goes up, the confirmation times go down.

Yeah. You had a question regarding I wanted to jump back on the pain ladder. So you have the pain of the users, you have the pain of the builders, the CEO is on the bottom of this. your opinion is that um but we're thinking a lot about that of like how can we actually onboard these die hard teams like the teams that are going to build day in day out even if they need to eat glass. So I'm very curious like how did you make sure that you could find these die hard teams to like evangelize them make sure that they are like very loyal to your protocol and they're going to actually build stuff even though it's really really hard because nowadays I feel there's like so many chains so many solutions they could say like oh it's too hard on yours I'm going to build somewhere else or there's

more money somewhere else I'm going to go there. I don't know if you can repeat this, but this worked for us in almost an on accident. Like I didn't have enough money to build a fast EVM. So, we would have had to use like a slower version of EVM if we had EVM support. And that meant that the stuff that we really were good at at optimizing just wouldn't be shown. Like it would just AMD's law like DVM would take such a huge part of the budget for all the stuff that like all these optimizations would be pointless. So we built something that we knew could be fast which was painful for devs because it was new like written in a very low low-level way but it unlocked something new for devs that could submit at that

time an infinite number of transactions that they could think of at like fractions of a penny. So they saw this as like a whole new playing field and the developers that cared about that were willing to eat glass to overcome that. So that was one thing is that we attracted a certain kind of developer that was looking for new capacity something new that this platform offered. two and this was unpredicted is that when Binance Smart Chain launched there was a lot of copycat projects that would literally copy the code on Ethereum like take the unis swap contract or the a contracts redeploy them on Binance and launch a token and that a code that they copied is as good as written by a right like it's as good

as technology there's no technical difference to it but this is a loweffort team that just kind of did like drive by product launch. The problem with those teams is they take space in the market and they attract users and now anyone that builds a lending protocol in your environment has to fight them for market share and it just sucks because you had to be a low-level C engineer to figure out anything about Salana. Those teams were filtered out. So they couldn't overcome the friction, the developer friction. They had to like go somewhere else. So it was like this weird self- selection that the difficulty of building on Salana created space for these really smart engineers

that were like, "Oh, I don't have a problem with Linux drivers. I can do this in my sleep to punch out a bunch of code for products that were like functionally equivalent to what's on Ethereum." It wasn't like a better AMM. It was just an AMM that was harder to build that was as good as the one on Ethereum, but it allowed that team to establish a brand like Radium is still around and is massively successful by all measurable metrics, but that was because they could overcome that friction and build something back in the early days. That was like really unpredictable for me as a CEO to like manufacture that. That was kind of like a lucky break, I would say.

But the key part there that I think you do have control over is that the platform did unlock something that was more than marginally better than everyone else. The speed and the cost. There was something about the hardcore ethos of everyone building. I was a little confused earlier when you mentioned that you don't see Ethereum as a competitor from the standpoint of is that you saying that you feel like there's enough space for many chains in the future or is that like a critique where you just don't take them seriously in the long run? We're not competing with Ethereum and settlement. I could care less if all the assets are issued on Ethereum but traded on Salana. We're competing with Ethereum for execution.

And this is when like Jolubin and Vitalic started talking about global settlement. It was just like great you're a DTCC like how many people can even name a single settlement company that does settlement? They do quadrillion worth of settlement per year and charge 2 basis points. So like to beat them as a technology company you have to be cheaper than them and better somehow. But settlement is the most boring simplest part of finance. So that that was really the the carve out like as soon as they went that direction it was just kind of okay great. It's like Google saying they no longer care about search.

Got it. Okay. And so then you know right now the industry is still very young. So it feels like there's a lot of infrastructure experiments going on as people are trying to find different niches. But as the conversation evolves and then we potentially get more into an application environment and this layer becomes commoditized at a certain level, do you see most of those experiments either being absorbed or failing and kind of going to a singularity of the infrastructure that is blockchain or do you see a future state where there's a market for many different purpose-built chains? So that's already happened actually. Like when you look at the last five years, this is like one of my controversial takes. There's maybe like five smart contracts that matter.

There's a token implementation, there's an NFT implementation, there's an AMM, a lending protocol, which kind of covers per and a bunch of other risk engines and I don't know a central limit like a more order book style market. So it's like a couple asset types and a couple market types and a couple leverage systems. risk engines. That's five or six things. There hasn't really been new contracts that have sprung up that have unlocked anything. So that side has already been commoditized. This is why like this weird thing on Salana is it's really hard to build interfaces. So people build a single implementation.

There's two token implementations that everyone uses. And in fact 99% of the tokens are the first token implementation that we built. there's no reason to create developer optionality there and even the contract level. So there's no reason to build another virtual machine, right? Like what set of new VM instructions in the ISA could open up new use cases when we can't even like figure out more more than six smart contracts. This is where like I think a lot of like stuff that people care about like solidity versus rust versus risk or whatever. I don't think any of those details matter. Where I find stuff that matters is like can you eliminate

business risk. So weirdly because there's no interfaces on Salana, you have a single token implementation that is the default one. The reason why memecoins took off on Salana is because if you're a memecoin marketplace, you have to validate the implementation that you're consuming, not the interface. Because you can build an implementation that steals user funds. So you can't surface it to your users until you validate it. On Salana, you don't have to do that because it's a standard implementation that everyone conforms to. So we removed developer optionality.

We made the system harder to code, harder to express yourself. But that reduced business risk and therefore pump took off and like they built 30 lines of code for the bonding curve. They didn't even build their own AMM or token standard. So like you kind of see that already and how it evolves in the future. It's hard to predict but I don't just don't see the need for 10 different virtual machines or you know like EVM is going to be around simply because of legacy stuff. I think what's more interesting is maybe like things like Hyperlquid where you have an application that has product market fit and you build the hooks to run code from users into that application in some way that

expands how that like the PMF for the app. So if you can start from there, right, you build an app that gets PMF and then you want to generalize it, you can then borrow stuff from SVM or EVM or whatever, but you're going to be driven by like product market fit there. And the decisions that you'll make will be very different than designing it from scratch like right now. In as much detail as you can muster, what do you imagine the space looking like 10 years from now? That's 10 years too far. I can think in like four to five year terms. I think we're going to get to a trillion dollars with the stable coins. Mhm.

Which is staggering if you think about it. Like we're at 250 billion, right? Over 200 billion now. So it's like very achievable. And then probably same amount in like real world assets mixed across a bunch of other stuff. And that is a massive amount of finance revenue to go find either through fees as a custodian or trading system or market or whatever. There's just so many places where you can build a real business with that much assets accessible to developers to users and stuff. I don't know of any other like high growth area outside of AI.

And how do you imagine all of that will change everyday people's experience? Well, my hope is that service fees go down for finance. I think the goal should be to build systems that ultimately reduce user fees. Otherwise, like we're wasting the world's time, right? But I don't know, finance is like 20% of the world's GDP. Half of that is about fees. That's 10 trillion of something per year or something like that. So, let's cut that down to one trillion and all those be on Salana, right? Amazing.

On that note, I think yeah, we can end here. Thank you very much. Thank you guys. [Music] [Music] Wow. Wow. Wow. Wow. Wow. Wow. Wow. Wow. Wow.