Solayer: Scaling Solana with a Hardware-Accelerated Chain

0:00 Welcome back to another episode of the Permissionless podcast, of course, brought to you by the team at Guardian. And as always, we're going deep with DeFi teams who are building on the edge and building some products that really push the limits of what the underlying hardware and architecture are able to do. and we're getting to see how they saw the opportunity that they're tackling today, what keeps them up at night, and how they see DeFi and web 3 and crypto going in the near future.

0:30 And of course, today we have a fascinating conversation with Jason from Solayer, which is a team that has gone all the way into the level of the actual hardware and the chips that are used on the devices that that act as as nodes on a network to be able to have an insanely scalable solution for blockchain technology.

0:54 And kind of as like a side hustle almost, they have added on a card program and a handful of other things that for for most teams would be a full-time undertaking. But, Jason goes into how they've been leveraging AI to build faster and and really how just having an average extremely high level of talent on the team allows them to move very quickly and accomplish these deeply complicated technical tasks in really what is a pretty short time frame.

1:23 So, of course, we've got a lot to get into with Jason, but of course, before we dive into that, my name is Owen, and almost four years ago at this point, I co-founded Guardian, and we started out on the premise that one day DeFi would house billions and hundreds of billions and trillions of dollars of the global financial systems economy.

1:43 And really, we set out to build the security solution that allowed builders to ship in that environment where you needed a level of assurance that was just a a step-wise increase over what was available on the market. And I'm happy to say that today at Guardian, we have achieved that level of scrutiny for really some of the world's largest institutions to be able to come on chain and ship new projects with the level of assurance that is necessary.

2:12 We use multiple auditing teams in our approach. We use some of the most advanced fuzzing techniques in the industry. And of course, we use some of the best security researchers in the world to give a level of assurance that is so high that we're able to put up our own funds as a bounty on the contracts on behalf of our clients when we give the green light to deploy to production.

2:37 And of course with that level of assurance now available, it's really up to DeFi to catch up. So of course now with all of that out of the way, let us get into this wonderful conversation with Jason from Solayer. First of all, thank you so much for taking the time to hop on. I think obviously we've got a lot to get to in terms of technical like what you guys have on the road map, what's coming out.

3:07 You know some some exciting stuff with the DevNet just getting released. But before we go into everything you guys have built so far and what you're building in the future, I'd love to just get an understanding of like how did you even first find your way into the Solana ecosystem? How did you first find your way into DeFi blockchain?

3:25 What is it that got you initially interested in in this area of tech?

3:30 Yeah, absolutely. So I'm also the co-founder for MPCVault which is a onchain B2B you know sort of a custody solutions most businesses are using it and you know and D5 funds we move about like $10 billion in weekly volume right now

3:43 Nice

3:44 And that's a sizable amount of volume

3:48 We did all the chain integrations and Solana appear to be one of the more interesting ones right so I'm personally I'm also doing chain integrations the ability to have multiple instructions in one single transaction signing is something that's very different from the Ethereum way of doing things. And the second thing is that you're able to simplify UX by a lot by packaging multiple steps and even interacting with different contracts in one transaction.

4:11 So that that caught my attention first and the original was solely was was very interesting because originally I was helping out a friend and then there was a you know team building it but ultimately I think people decided to do different stuff. So it's a it's it's a very fortunate thing that I became part of the Solayer like the you know initial helping friends and stuff got more traction and we build the protocol really quickly and now I'm leading all the technical stuff on the Solayer front as a co-founder.

4:39 So I think so that's how Solayer got started. So back then EigenLayer was really big when it comes to share security narrative on Ethereum. We just thought that if that's the future direction, you might want to have the base layer becoming a it be a more be a faster base layer.

4:54 Yeah,

4:55 Whatever worked on Ethereum is great, but it could work a lot better on Solana.

5:01 Yeah. And use shared security, use the same security fundamentals. Yeah.

5:05 Yeah. It's f like shared security part of shared security is that you have to move the stake from one person to another because it's dedicated proof of stake, right? So on Ethereum it's expensive because you're paying ETH and then the change throughput isn't that high and you have to do multiple instructions like Ethereum there's always to have this approve and then delegate or approve then swap stuff like that.

5:27 So we saw you know that opportunity you know going big with Solana and we we went right in right so that's that's how it started. I'm glad that you know it it turned out really well in terms of the nice property of Solana being able to complement the desired characteristics of of restaking.

5:45 Yeah. And obviously on the EVM side, you know, we've had a lot of technical ways to sort of build around that and like you know permit to work around this like a proven swap workflow. and then also like the multi call to like batch transactions in. But like you're right that you know this stuff not existing at the fundamental layer sort of I don't know made the dev experience sort of grow into this sort of thing with like things bolted on the side like this.

6:12 Like why do you think why do you think that hasn't really taken off and what makes that so much more approachable from the Solana side? I think Solana was just designed in a fundamentally different way. when it comes to VM and interaction design like Ethereum was always there interacting with one particular address. It has its upsides and downsides.

6:32 Downsides we've sort of we sort of talked about it. Upside is that it's very easy to set up permission access control because you can only talk to a particular address, right? And then the arguments are all laid out in a sense. It's key value pairs. So from that perspective, I think that there there's some upside whereas Solana Aptos and Sui these these later VM platforms are much more programlike.

6:56 Yeah.

6:56 As opposed to the Ethereum one which is more like you have to interact with one specific endpoint to do something. This is more about you sending a program the program executes itself. So it can does a lot it can it can do a lot of things. So I I think from a adoption perspective it it really makes sense.

7:12 I mean Solana wouldn't be able to compete with Ethereum if it were just to repeat the same footsteps but so I think the difference is good and one outcome here is that nobody on Solana is talking about account abstraction because it's just isn't right like it's natively there I can send a dollar like the wallet can choose to sponsor it right away.

7:30 You can just change the the sign the fee payer to a different address right and then the the wallet can just sponsor it. I think those are the so as the system gets more mature, we're seeing features converging to wider adoption of crypto that's are designed to help with wider adoption of crypto. Another thing which is you know for example whenever you want to do swaps on Ethereum going to be two steps and so so it's approve and then swap.

7:55 And if you are security sensitive like you're very paranoid about your security you would actually do it three steps. the third step being revoking the permission

8:06 Really unnecessary to some extent but that's because of a technical design choice made by Ethereum. You have ERC contract as a different thing, right? You can only interact with a contract as opposed to as opposed with a swap at the same time. So that's the that that's the fundamental difference or fundamental that that really drove the UX difference over there.

8:24 Yeah. And it almost feels like probably because it was that tokens were somewhat of an afterthought when designing this whole interaction procedure, but like you said on Solana, you know, the integrations can be a lot more dynamic. You can start to invoke, you know, lots of different contracts, lots of different functions, and it opens up like much easier pathways to interaction and define stuff like this.

8:47 So, I mean, it sounds like Solayer was a project even before you ended up joining it. What was the original like at the very beginning like what what did that look like and obviously you guys have pivoted a lot or you know I think so you've pivoted a lot since then so I guess what what was the initial like sort of vision for so air

9:05 Yeah I wouldn't say we pivoted a lot not just because I want to frame it in a certain perspective but more like so at at the start so when we were analyzing restaking we built all the primitives but we didn't really think that restaking was we think it was a good opportunity but we didn't think that restaking could immediately take off in a way that you know people are starting to pay fees such that the protocol itself becomes super profitable like a like a DeFi lending borrowing protocol like it it just doesn't make sense right like you have to have a long term you know sort of roadmap and also building marketing and getting devs in in order for that to happen so so but as a smaller protocol we have to hatch against such

9:47 Risks right so what we can't say that there's step one and well there's a token, you build it and that's done, right? So, we have to continue pushing our product. so the continuation of a restaking primitive on Solana is actually the InfiniSVM chain, right? So, we got inspiration from oh for Ethereum there's like Arbitrum, but what's there for Solana?

10:08 There's always going to be the use case of people wanting instant confirmations.

10:12 Mhm.

10:12 AntiMev sort of basic MEV protection and antiMev mechanisms, right? If you look at Arbitrum's mega sequencer design, they call it sequencer based design. We call it mega sequencer. There's a technical difference. So that's why I'm using the term, but you see that user experience getting much much better and we're able to push the TPS transaction per second to close to like a quarter of a minute right now.

10:34 So we think that's just technically very interesting. We also feel that there's a market demand. There are people going to you know do L1 transactions no problem. But there are also people who are going to do real-time transactions in a sense that it's like I send a HTTP call I get a response as opposed to this asynchronous polling based mechanism.

10:51 Yeah. because it wait it needs to await for confirmation by the chain right so we just think that sequencer preconfirmation if we can somehow manage that it's very important and then the second thing is I spoke about Solana having the ability of having multiple instructions in a single transaction and that effectively could take the steps to bridge away

11:13 From what you're seeing in in Ethereum right so I can just have DAP install an SDK user sign one transaction that's it and I think that's something really powerful because you don't even know you're using Solayer InfiniSVM. It's also it can make use of the primitives that we built for restaking. I mean restaking is a gi is a big word but what it does is just the primitives removing the stake for accounting the state right it's not really a big deal so that's something that we're super interested in and then we saw it as a natural extension and there is this third component which is the card right Solayer visa card so that's because we just want to be able to power we want to build the first application right when you have a

11:50 Chains like yeah you can choose to builders to come but it's a it's a it's a battle we have to fight in the longer term but in the short term once we have the user we noticed that there's a need why don't we just do something that's pretty easy so we deployed you know one and a half engineers on average right maintaining probably less to the card program and I think scoring growing really well and we're able to power a lot of the expand spend use cases on sol on Solana using Solayer InfiniSVM so I think we want to put the chain chain to real tests have it power some of the financial use cases and then if there is none at the moment just because you know things haven't started, the chain hasn't started,

12:29 The GTM for builder ecosystem hasn't started. Why don't we do something just low handing fruits? This is like a strategy perspective. It's just something why we chose to do.

12:38 Yeah. And then you have like a case study for, you know, hey, this is real use case, real world demand where we were able to support like, you know, x number of transactions per second. I am interested to to see if you guys have any benchmarks on like I think you guys have listed like a million transactions per second.

12:53 That does seem like a a pretty crazy to think about number. So we'll definitely talk about that. But yeah, I mean even goes back to what you said with like reststaking it. It kind of like that entire model only really works if you boom immediately have all of the things in the ecosystem and you're able to be paying for validators and it's not purely just like inflationary just you know paying them for the sake of paying them out of your own treasury.

13:17 So yeah it is I I think it is one of these problems that's like it is very hard to solve. So I think going and becoming the first user of the chain yourself and sort of like dog fooding your own infrastructure and building a go to market machine on top of it is I mean probably the best way to get that 0ero to one moment and then you've got all these users on the chain you've got you know hopefully some liquidity and you know network usage and then the builders will come and then you know it makes sense to sort of decentralize and and use some shared security.

13:46 So, and I think it's also important to distinctualize that you mentioned, you know, there's some parallels between like the arbitrum like L2, you know, sort of interaction between ETH mainnet and Arbitrum and and you guys in Solana, but I think it's it's important to distinctualize like you guys are not an L2. You guys are your own layer one, right?

14:04 Yeah, correct. Because you can't really do an L2 on Solana. That's the reason why like technically I'm we're calling it an L1 because of the trust assumption like I mean the difference is between how you want to do the trust assumption and whether your chain state would be affected by L1 reorg if you have your own voting setup that's effective in L1 but we still run on so right because we don't expect people to have layer from day one and and and I mean it's one thing to say that I'm Aptos I'm Sui I have like a couple hundred million dollars raised I don't care I want to start this way right I want to help a new entire VM even though it's moved I can just change it.

14:40 It's a it's another thing. Oh, we just have to contextualize it with what we have already right so like for this we think it makes the best sense if we can make the bridging or you know the connection between Solayer and Solana almost seamless it's best that users don't even notice it that that's sort of our goal in terms of outcome we want to achieve.

14:59 Yeah. And that that part was very interesting to me because I mean the that bridging experience is actually very different than the bridging experience between like arbitrum and and ETH mainnet. I mean if you talk about the actual native bridge between Arbitrum and ethnet that'll take like 7 days. Well at least to go from the L2 to the L1.

15:16 Yeah. If you

15:17 Yours is very much opposite like you have like an insurance fund that allows certain threshold transactions to just happen immediately with you know some level of of guarantee for economic security. there. Does that enable you? I assume it only goes one way. It only goes when you're going onto the L2. Is there some kind of a delay when you're going off

15:37 From two because there are some risks over there.

15:40 Yeah.

15:40 Because sequencer like for in the arbitrum case because the roll up isn't instantaneous, right? There's every set period. So effectively, you are able to prevent or stop some kind of attacks if you notice that the deposits are bad. But the withdrawals is where you lose control completely and therefore they need this challenge period.

16:00 Yep. Okay. So you guys still have some kind of a challenge period associated.

16:05 The the bridge itself doesn't have that but the bridge itself is a guardian based model at the moment. I mean when I say guardian based this is then the number of nodes wouldn't be that much because it it's there's like communication between two chains and there are some a lot of risks when it comes to how like what's the thing called because everyone's using quick no everyone's using alchemy everyone's using nobody's running their own node right like effectively unless you want to put in the money to do that but but that's that's because economy of specialization would that there's power concentration.

16:42 If one holds, the other would hold also. But from a security perspective, leaning on just one or two providers wouldn't be that you know good. So a bridge design is very very sensitive. We do have a period where we want to hold the funds to you know basically for a longer period if it's a large amount.

16:58 Yeah. Yeah. And of course so you guys haven't gone fully to the other end of the spectrum where you have complete shared security and you're you know having folks restake to secure you know whatever kind of you might use. So what is like the current state of I think you have like proof of authority and stake. What is the state of decentralization there?

17:16 Are you just running you know all of the validators yourself currently what's where are you guys at in the process?

17:23 Yeah I think that's a good question right so when it comes to I think for decentralized systems what we want to achieve in terms of properties is that there is transparency.

17:32 Yeah. in a sense that you can see how things are changing, right? And we also want correctness for sure, right?

17:41 Yeah.

17:41 But we don't so there there's this property that Ethereum has and we don't have which is the the broadly speaking liveness property also includes you know transaction censorship. So that's the property you know just because of the model we're going with we wouldn't be able to have that right but but where but the trade-off is that the chain is instant confirmation.

18:00 Yeah.

18:00 Chain is super low latency. it has high TPS because the leader does not rotate. So the from a physical network and bandwidth perspective, the chain is able to sustain that much, right? Like the system is able to sustain them sustain that much. So so that's sort of the model we're going with. We're not trying to compete with Ethereum when it comes to decentralization, right?

18:20 If you want to have some kind of money that your government doesn't want you to have and you want to move it anytime you like, probably Bitcoin or Ethereum are the best, right? We're not trying to compete in that regard. We're trying to compete when it comes to how can we have a platform that enable future finance to make sure that we're able to support thousands of transactions per second for people want to build dabs even prior to institutions coming in and what kind of experience do the end users want.

18:44 So that's the sort of things that we are able to target. And now the last thing is the the last thing is like so what trust model do we have? First of all, we have mega sequencer continuously outputting the sequence of events and then the chain update and there's a group of decentralized verifiers who needs to attest to that by running the entire thing themselves.

19:05 So it's like Solana but there's no rotation of leader. there's still a volt network that that's required

19:11 And then with the okay so obviously you guys have gone you know 100% into the end of the spectrum where we're just going to specialize in maximum scale maximum and and also keep composability which is something really exciting as well. What is it that made you go towards this end of the extreme and say like we need to support this?

19:29 What kind of applications? What kind of a need was there anything that you were implementing you know maybe on the vault that you were previously a co-founder of like what kind of applications is this built for?

19:39 I think it could be a range of applications. it's just that we don't want to have a a riding the meter approach like get midcurve in

19:48 You a funny way of putting this like we don't want we want to build a midcurve product where we have this a little bit we have that a little bit and we don't really positioning is if you look at most of the decentralization decentralized system out there I would argue that decentralization is actually very hard to achieve

20:03 And the same thing goes for Ethereum because 90% of the blocks are actually built by two builders one is beer one is Titan right so

20:11 The The reason why decentralization is very difficult is because of economies of scale. This is the natural laws that it's very hard to go against. Some people are just good at doing one thing, they do it super well because it's profit driven and by that nature you would have power law distribution for market power.

20:27 So I would say you know decentralization first of all is really hard to achieve and Ethereum is doing it very well to a certain extent right not as well as many people have you know thought they're doing. My second thing I want to say is that most of the systems out there are extremely centralized. and and I'm saying that you know apart from the big four five you know public blockchains if you look into who is actually running them who is actually you know using them they're extremely centralized right but they are using the centralized approach.

20:57 So with a decentralized technology, what that means is that there are certain additional risks they're actually taking on. If we design a system with the assumption that and also trade-off they're not gaining, right? If you are designing a system for for you know really to empower lots of use cases to have maximum composability just got to rethink about how we're going to design a system, right?

21:18 There's nothing wrong with a mega sequencer. The only thing we can do like and it's provable is that we're censoring transactions. You can prove that we're censoring transactions, but the foundation actually doesn't have any incentives to do evil.

21:30 Absolutely.

21:31 Like I'm I'm gonna drop 20% of user transactions for no reason.

21:35 Yeah. Just network value.

21:38 Yeah. It's weird, right? It's like nobody wants to do that. So the the only time when it could happen is the government gives the court order and say they you can't do this, right? But how many cases are there that this would actually happen in the entire history of of blockchain? they might as well just ban centralized exchange accounts, right?

21:55 So, so I think for the DeFi, for the decentralization, maxis, absolute total control, absolute self ownership, go Bitcoin. I think that's the best you can ever possibly find. We're not in that game. But most people who have a usability perspective, they they they don't care. If I want to build a VMOish transfer transfer application, I would choose sole because it's much easier.

22:15 I want to give my user the instant confirmation feature such that when I send, did you receive it? And you say yes. I don't want the other end of of the user to be wait no I'm not seeing it.

22:26 Just just wait for a few blocks. Yeah.

22:28 Yeah. Okay. Refresh. Refresh. Okay. Like that's not the right experience, right? folks folks are not trying to do that. So So that's sort of our take.

22:36 Yeah. Absolutely. And I think well I mean regardless it's always going to be way way way way way less you know counterparty risk compared to any kind of a centralized exchange or anything like that obviously. and and I think a lot of people they look at decentralization and they try to just underwrite stuff based on how decentralized it is.

22:56 And I think that's almost a misnomer. I think a lot of people what what you really actually care about is just counterparty risk. It's like who are my counterparties and understanding that and then also understanding their incentives. Like I think obviously in like in this case for example like obviously you're not incentivized to like censor their transactions and it's also understanding what they can do like you can censor transactions you know can you without I mean I I guess if you assume that any validator you could push new code updates to if you got all the validators together I mean if you look at something like Sui but yeah I think it's a lot more powerful to look at okay what is the actual counterparty risk that I'm taking on on this network and then

23:34 Understanding it that way and then obviously incentives and for some applications, you're right, like it's just you don't need to have the ultimate decentralized ethos, but for some applications and for some users, that's going to be, you know, an exact product market fit. And I think like I mean it it's it is kind of empowering to just say like, okay, you know, we understand that's great.

23:54 That's going to appeal to this subsection of users. They're not for us. We are going to focus on this subsection of users and we're going to build exactly for that. And that probably gives you maybe a bit of an advantage over those teams that are trying to sort of appeal to everything and and have it all in one.

24:09 You guys are able to basically just focus on very very distinctly the the few things that are going to make this application and and this infrastructure layer actually applicable to a lot of the use cases you guys are trying to to bring on. But I mean I want to talk about actually technically how we achieve it. So, I mean, of course, you're you're starting off with the card program, which, you know, probably it it will start to benefit a lot more from the transactions per second once you know, I imagine we get many many users.

24:37 But let's talk

24:40 Yeah.

24:40 Yeah. because I mean a million transactions per second. That's like what what is the I don't know the statistic. Maybe you know it off the top of your head. What is like the Visa transactions per second? They always like put it up if

24:51 I'm not wrong. There's not even 10,000 people.

24:53 Yeah. Yeah. Yeah. So, but I'm interested like what okay, what were the biggest like bang for your buck changes in terms of infrastructure and obviously there's all these different bottlenecks and like the consensus and the hardware layer which I I really haven't seen many teams go into but like where did you guys get the biggest bang for your buck in terms of throughput

25:12 Architecture so if you don't have a rotating leaders and you have a mega specialized leader you can do a lot of hardware software code design like for sequencing machines I don't really need it to run on consumer hardwares. I mean Solana is getting to the point where you need dedicated hardware to in a say dedicated I mean there are certain spec you would have to do it right for for most people who want to run a Solana node they won't be able to have it run the first you know 10 fries at least going to take a couple of weeks or days for them to learn and pick up the knowledge well that's the specific CPU I want I want a certain frequency right it's a DDR4 DDR5 you start to get into all that

25:50 So in that sense I think you know the hardware requirement is going it's it's there for Solana already. So because we have the latitude of doing whatever hardware we want. So actually our sequencing cluster has multiple machines not just the single machine. So Solana's you know transaction pipeline is pretty serial like there's you know verification of signatures and you know signature dduplication verify and then to the to the sort of a sequencing stage accounts update and then pushing the stream out.

26:19 We just have different machines for everything and most of the machines can do fully in memory specialized.

26:24 Yeah. And so long they have to do a count fetch in a sense that I can't assume that you have let's say one terabytes of memory. but we can assume that we have one terabytes of memory even two terabytes of DDR5 memory. Right. So it's it's just that being able to have that economies of scale. I think sequencing is where you can have a lot more economies of scale.

26:42 So that that's where I say that the you know most of the current improvements are coming on. And now looking to the future, right? If you want to achieve a million TPS per second, there are still bottlenecks. Now the bottlenecks aren't seek verify dduplication because DDG get a lot more locks contentions state access contentions coming up. So you know the hardware part of it could be that you know I have a dedicated chip that has ARM cortex on it and with direct memory access to the memory and then it runs by itself as opposed to going through all the kernel operating system and a bunch of other stuff.

27:17 So that's where we really really see the benefits of scaling if it's a single and a composable single compos state and of course you can say that oh let's not do a single composable state as long as your separate states can talk to each other seamlessly like sharding right it's mostly a UX problem to be honest right Ethereum has shard one shard two shard three and then there was this chain I think it's u that actually implemented this and then every time you do a transfer you have to select which shard they're on

27:44 So it's technically yes you can increase the throughput, but people want single state machines. There's a very beautiful way of marrying the two states together most likely. And then getting balance is like you're going to get balance across multiple clusters, multiple shards, one, two, three. So it's a it's a hard UX problem to solve. So we're not going with that route.

28:03 We're just taking Solana to like 10, you know, actually 100x bigger.

28:07 Yeah. Yeah. And well, I mean, I'm always of the opinion that, you know, the more simplicity that you can bake into it at a base layer, the more you'll be able to actually scale that architecture because, you know, when things get too complex. I mean, when it gets to the point that one person can't even keep in their mind the entire architecture, it's just that is a recipe for for disaster and security issues and everything that goes with that.

28:29 But, I mean, of course, you guys can only do these kinds of things if you accept that decentralization is not your priority. And so I think that gives you guys a power to do stuff that obviously Ethereum cannot compete with the the throughput and you know all these modifications that that you guys are are making because you distinctly decided that from the outset.

28:49 Yeah, I wouldn't say decentralization is not a priority. I would say decentralized block building or rotating block building is not a priority for us because once you have that you have me and I would rather just say that I have a mega leader sequencer. I'm not going to commit any sort of me from running to steal your order flow then to say that we want to have decentralization come and me my users right I I just don't think that is the right approach but but from a decentralization perspective you had a you had a good sort of a comparison over there but I just want to say that I think most DAPs are not as decentralized I think in so far

29:26 Yeah like in so far as you know there is one person or a C a so-called CEO the face whatever of the company having control over the DAP even even the Amazon services where it's deployed you know on

29:39 Or or you giving feedback that he can actually take and change the product is not decentralized I think the true decentralization is just Bitcoin like you shot into the boy nobody cares and it doesn't change it just goes on life goes on like it doesn't change right no matter how many criticism or no matter whatever like nobody's responsible for that but it's still wrong right so I think that to me I think that's true decentraliz ization.

30:02 But again, like I I don't think we need to sort of I mean it's not what we're we're not here just for the narrative play. So that's why I think from the outright if you want to try if you want to stay on the market, you know, in a sense that we survive all the bull bust cycles, have real product market fit, we got to be realistic and practical about where the demand is.

30:22 How can we drive differentiations? We can't do you know whatever new thing plus chain like robotics chain. I think you'll see that coming up a lot in the future like AI chain. I don't even know what AI chain does. Yes, we're going back to the more boring stuff about talking about the consensus and TPS requirements. But I think this is where the world and you know the industry would see fundamental improvements because that's actually the base layer like the base layer is where general compute is is what you know like everyone needs.

30:48 Yeah. I mean well first of all I think you're absolutely right. I think 90% of DeFi would be shocked if they understood how many DeFi applications could be technically controlled by Jeff Bezos or at the very least some level of like DOS from from Amazon. They could probably shut down like most DeFi applications.

31:05 Like anyone who has control over CDN delivery can steal money right away.

31:09 It's actually pretty wild to to think about how much you think you're trusting the network which the app is built on back and you're just trusting Amazon for a lot of this. Especially a lot of these like off-chain systems, a lot of these new applications are like 90% offchain and then they just settle to the blockchain. But yeah, anyways, I I I want to talk about like obviously so we've got the infrastructure and and I'm how many years at this point have you guys put into all your work on the infrastructure and the hardware side

31:35 From for Solayer or

31:37 I mean Solayer is pretty new, right? So we started I think we launched April 2024 and now it's like June 2025.

31:47 Yes. Everyone on the team has a lot of experience building decentralized systems like there's like we we acquired a team you know it's a it's a good friend that I met you know while working on MPC cha like Fland and they've hacked so many different so so we we are deep into the space and we know not just EVM but move language like we're big on Sui as well we have other me operations and then Solana as well so we just know a lot of stuff

32:15 Very interesting so at which point did you guys decide that it would be the right decision to launch your own sort of consumerf facing product and use your underlying infrastructure to kind of get a case study going and and obviously also bootstrap some initial network liquidity with the emerald card was that always from the outset a part of the vision where did that come into the picture

32:41 Yeah it's it's something for fun like so developers are building you know a chain right we need something that the marketing the ops can still work on. So it's still a time fielder but it's also very successful like like yeah we're we're close to $100 million in annualized volume.

32:57 Wow. Wow. On the card. So what is like the go to market for the card who is this targeting?

33:02 So any crypto you know holding you know anyone with crypto holding like if you have USDC on Solana you have the card you're able to spend it like spend the money right away. It's just like that's just what we do. We see it as a it's a fun thing to do. It's it's revenue positive, right? It's a fun thing to do and then people want to take a, you know, run at it.

33:22 Just go ahead. I think that's that's how I think about it. It's not a core product for Solayer, right? But it's a it's a pillar that we want to be able to try and just have more touch points with our customers. If you think about like from a chain perspective, yeah, you know, if we can continue drive the attention, you know, post TGE that's great, right?

33:41 But but realistically, how many projects can actually drive retention post DG? So you got to have more ways to stay in touch with the your customers.

33:50 Yeah.

33:50 And have them, you know, somehow engaging with you on on a constant basis. Like there's a high retention, you know, product you need to have. So that's why we we thought of the card.

33:59 Yeah. And I think at the end of the day, having that relationship directly with a lot of the end users is very powerful. So I think a lot of the value will acrue to those individuals and those companies that have like the audience directly and I think as an infrastructure company that will become increasingly important because I mean the last thing you would want to to have happen is like become commoditized against other solutions

34:22 And you know not have any kind of a unique distribution. I mean of course you're differentiated in the hardware and the technical capabilities but

34:30 Like having before other people catch up right so like cement that sort of differential competitive advantage I think there needs to be work to be done I think we see it if you take a web two lens to at so layer or any crypto layer 1 project right it's like a B2B and B2C business so which makes it extra hard right there's like this art of the deal to borrow that language Yeah,

34:55 With the B2B folks, there's also this consumer stuff you have to do, you know, like marketing and positioning. So, I it's interesting, but but I I would say that, you know, you have to do both things to maximize or to increase, right, the chance of success at this stage in crypto. It's not like, you know, the markets are actively looking for a new L1, right?

35:18 It's like the markets are no, that's another one. So, so we we know that and so we just want to be practical.

35:26 Yeah. And speaking of the the B2B side of things, like I think the B TOC side is pretty pretty straightforward, but who are some, you know, design partners or people utilizing Solayer that we may or may not know about?

35:36 Yeah. There are a couple people building like for example Daxes on Solayer already, but I can't disclose their names. I think the marketing would u but the marketing would be very mad if I if I just say that. I think so. But they're testing it out. But the value proposition there is that you click on swap and it's done.

35:54 So that's that's you know the experience and people want to

35:57 Easy enough. Yeah. There we go. So you mentioned kind of assembling or getting started I think April of of last year. How big is the team right now and who do you have working on the project?

36:06 Yeah we have like about 10 people engineers and non-engineers included. Most folks are here based in the Bay Area. So most of ours are based in West Bay cuz like you know I I went to school over here and then some of our most of our teammates on the engineering side also went to school here. So we're just living in this area.

36:23 Yeah, that's pretty much it. Like and we have a couple folks on marketing, design, and operations.

36:29 Nice. Yeah. The reason I asked is before we started recording, we kind of talked about nowadays having a leaner team can almost be more effective, especially in this age of AI. I think it'd be really interesting to talk about you know like what's your set of using AI to you know build up the product.

36:44 Yeah. let me address your first point. I think a linear team the reason why like for a linear team to work one person has to take a lot of load and be comfortable the load right. I think engineering is where you see not just one 2x of the difference in output and efficiency. You sometimes see 10x and 20x or even 100x right because they're just problems that some you know one you know one engineer couldn't solve but this other guy could just solve it in in a day or something.

37:13 It's like this final question on you know this exam papers that nobody know how to solve but this one guy in class right so so the job there is actually to find a Zambo such a team that each can that you know where each person can take a massive amount of load but by massive I mean to any outsider who doesn't work

37:33 Sure yeah

37:34 Might be a lot but to them it's like it's okay because it's not very hard so there's like a lead code you know I have a lot of friends you know we just know friends who are of that caliber just because this like it's very close to the bigger companies like all the you know top five 10 global internet companies so we're just drawing talent from that pool and I think that's a prerequisite to have a leaner team and by having a leaner team it also means that each person knows a lot of things just they have to because they worked on it right so it's much easier for problem solving right so assuming that your product person not only knows the card and the ins and outs of it but also knows the chains

38:13 Things and alphabet even though he doesn't code about it codes you know write the code for it but he understands it and he also understands go to market the stats you can do data analytics dashboard and that's the product person we have actually so it's very easy to coordinate stuff you don't have to have even the third person in the meeting to coordinate so I think that's you know and ideation is much faster so I think the quality stuff is you know when you have condensed you know sort of like a lot of talent here that that would just naturally get executed much faster.

38:42 If you think about an internet company, right, we actually don't have to scale when it comes to man power because we're not a let's construction site because you have now especially when you have AI which is what what I'm about to get in very soon but you have a lot of sort of power to scale vertically each person.

39:00 It's not like you have to actually lay the bricks and you have to hire a thousand people to do it. No, it's like writing the code most of the time. Most code bases are written by you know a couple people. you just need a couple to be there, right? So, I think that's sort of the difference. And now with AI, it's most programmers spend a lot of time on debugging stuff like when it comes to, oh, maybe this doesn't get right and looking up documentation, how to use this, how to use that because I forgot about it, right?

39:24 When you use a new library and now with AI, you have to spend time on that. So, you can literally write code at the speed of thought and that's very interesting because when you think about it, like it comes down, right? This is like the power of you. Think about like how much a programmer can contribute it contribute if he has a holistic picture of everything.

39:43 He just thinks about it and then the code appears right. I'm exaggerating a little bit but you get an idea of why their output fast.

39:50 Yeah absolutely. It's almost not even an exaggeration like as every day goes on and especially with those like thousandx engineers you mentioned you know if they're staying on top of it too it's just unstoppable. One thing I was thinking about is on Twitter or X you know you see people build these web two applications. Maybe they're more simple, but they literally just oneshot it with AI.

40:08 Do you think there's any different considerations when you're building like more complex, you know, blockchain infrastructure where AI might not live up to the same par as, you know, building some web 2 infrastructure or differences there?

40:19 So, I I didn't get your question. Are you are you saying that writing code for web 3 applications using AI, is it going to be more sensitive? from a security standoint,

40:26 Is it going to be more difficult or will the AI have less context? you know, have a harder time putting it together. More, you know, engineer interaction needed.

40:34 All our code are pretty Web to systems code like network quick throughput and database write ahead logging and we do our own version of writer hat logging. It's very it's fairly well established in the in the you know traditional industry. So there's nothing that we're doing that's the AI doesn't know right and I think but to build on that point I think you need engineers who can harness the power of AI and it's difficult because you need to understand more like AI is like from my perspective help you do the exact and specific thing give it and say please write the Solayer chain it can't do that but what it can do is that write me a receiver for a QUIC connection and find ways to optimize ize this bandwidth, the maximum bandwidth speed or

41:21 And have proper retry logic and it's the programmer's responsibility to consider all the corner cases and to have a master road map for the the chain like the codebase. Okay, here's the connection part of it and then under that part of it one of it is quick right you have proper interfacing between the two and so the programmer is actually doing the architecturing on the fly I mean you know before before you write the code you do some proper architecturing as well doing a lot of that on the fly and being able to just have that you know clarity as you're making wishes to the AI is very important.

41:56 Yeah.

41:57 Yeah. Absolutely. Super important. Okay. So I guess maybe taking a step back from from AI with with everything you've built so far and are you know still building obviously what have been some of maybe the most unique or tough technical problems so far?

42:10 Technical problems I I think everything is within the bounds of our expectation. I think really came sort of unexpected so far. I mean there are a couple things we have to resolve, right? First is the figure out the consensus piece of it. And by consensus I mean how do you get the decentralized network to vote as fast as we possibly can, right?

42:32 And then there is this broadcast piece. How can you broadcast that much of a data to everyone in the entire world? Right? What if we don't get it? Right? What's the protocol over there? And then there's this mega sequencer piece where how can you get it to run and sequence as fast as you possibly can. there's like kernel level optimizations but but you you get you know it's basically pretty standard like I I don't think we're the reason why we ship I think relatively faster at least from my perspective for the chain as well because the test net is already live at 100,000 action per second consistently right cons you can send a transaction in there it just gets indexed as well right indexing is also a big problem if you ever have that output

43:12 That is like no it's really hard to set up especially indexing but I guess what I'm trying to say is that we have a I think our engineers are quite experienced so we're not experimenting almost I mean we do experiments with tool sets right but we're not experimenting with like like we're not trying to figure out how to do something like we always have ideas that these are the one two three ways of approaching it like let's see like one is promising let's do one first if it doesn't work let's have a meeting and then everybody has the full context so I think that that's that's sort of a going back maybe to the team question I think that that's how it helps right Yeah, I mean I think that's a fundamental in business which

43:49 Is that you move as fast as your smallest tightest bottleneck. And if you have all members who have they haven't built the whole thing entirely themselves before, but you assemble the people that have built this piece and this piece and this piece and they've scaled each of those individual pieces to, you know, 100 million and beyond, then the speed at which you're going to move when you bring all those people together is you're just going to move up to wherever the the lowest bottleneck is across all those pieces.

44:14 So I mean obviously yeah if you've assembled everybody who has all the context and all the individual architecture layers and all this stuff you will you will immediately like everybody just knows like okay we need this and then you guys all just work in parallel and they're like the chain is all done and we're ready to go to DevNet like you guys have have just recently and it I mean 100,000 transactions per second on DevNet that's that's pretty wild.

44:38 Have you guys like pushed it to its limit?

44:40 A limit is about a quarter of a million. Yeah,

44:42 You you can you can stress test it. It will go up to 200,000. Yeah.

44:47 What is it? What is it that starts to break?

44:49 Sorry.

44:49 What is it that starts to break at like that 200,000 limit?

44:54 I think the link is a bit lossy like did you say what sets the brakes at 200,000?

44:59 Oh yeah, I think we're I think we're back now. But yeah. So what is what is it that starts to break? Like as you hit 200,000 transactions per second and you try to go beyond what what starts to break?

45:10 Yeah. It's just that the transaction wouldn't get included because the scheduleuler is

45:14 Yeah, definitely.

45:15 Yeah. Just latency.

45:16 So, it's like Solana where you sending a transaction, you don't get a response.

45:20 Yeah.

45:20 Yeah. And then I think also with like on the topic of shipping faster at least, you know, noticeably, and of course, all of this is relative, but would you say that AI has sped you guys up relative to if you guys didn't have AI?

45:33 Oh, for sure. There are so we have backgrounds in computer systems, operating system, networks, but we don't write code in those modules from a day-to-day basis.

45:42 Yeah.

45:43 So let's say you want to write a QUIC connection receiver, give it to AI to write it.

45:48 Yeah. They know the library and all this stuff.

45:49 Yeah. There are ways to handle retry packet sizes that AI knows better than we do.

45:55 So, so I think that's definitely the the sort of where AI has helped. And then the second thing is we know I think a good thing is that we know what we don't know or we're not very clear about. So we can always ask AI the precise question to get the answers that we want. I think that's very important.

46:12 Yeah. Because you can't say how to make a chain faster like like

46:18 Yeah I wish

46:19 You get what I mean right? I have to ask like this particular let's let's just use quick for example and QUIC connections doing one Gbits per second in some circumstances that's doing 20 Gbits per second here are the differences what do you think is the most likely factor that contributed to this difference you know this is like more educated guess stuff I think is very helpful because it's doing its lookup based on the heristics and it's very important

46:44 Yeah I mean it's just like Google how you know of course you had the information of the world at your fingertips but you had to know exactly the right way to query it. And I think AI it it gives you a UX to query something with way more context and way more nuance than Google ever could. and I I think even you know it's it's it's almost yeah it's like the productivity gains.

47:08 It's not like the bottleneck on writing software was how fast you could type the code. I think it was all those smaller finer details like oh you have to you know the arguments to this function in this library are like this and oh if you put zero here it actually means this and with AI I think it really just abstracts the job of an engineer to like you said like the highle things that I want to have done but not so high level where it's like make the change

47:36 And you know what will be interesting is to see how that changes over the years like does it start to rise and I I think there's kind of an interesting parallel here because you can almost measure the level of talent of like an engineer in the same sort of way which is at what level of abstraction can I direct you with?

47:53 So like you have a principal level engineer you can say like hey I want you to go make make a chain that's super fast and that's the instruction and then they go and they build solair right there's a level of talent that can do that and that's like superstar level talent versus an intern where it's like you know the type of instruction you might give them is hey I want you can you go write these unit tests for this thing and you know maybe they need more finer grained instruction but it'll be interesting to see like can AI sort of progress up that that ladder maybe with agents and stuff like this, it will continue to move up.

48:25 But yeah, it's interesting. We'll we'll see what what happens. But I think at the very least, even with just the sort of abstraction gains that, you know, we're able to get right now, it makes the engineers who are already good, I wouldn't say probably not 10x better, but it just saves you, I don't know, you're able to just move way faster.

48:46 And then it also has the information availability for people that don't even know how to use these libraries and maybe they're not that experienced. I don't know what that means for the future of these really big engineering organizations. But I mean the fact that I mean you guys have just have like 10 people and I'm sure not even all of those are engineers.

49:03 Yeah. Not

49:05 Yeah. So I mean and and you're you guys have been able to cover a you know really wide array of you know across multiple stacks. Yeah. I mean I I wonder if this is like the future of of engineering organizations is more just having people that know almost everything about their distinct vertical and then they can go and use AI to do a lot of the implementation because they know exactly what they need you know and then just kind of have a feedback loop to to get it right.

49:32 Yeah and then

49:33 For smaller teams I recommend that but I think for larger larger systems it's really hard to achieve this state just because the incentives are misaligned and then the and when I say incentives I mean that there are lots of people in the organization for whatever reason and they might not be fully dedicated to the work that they have.

49:52 They might have some there's stuff they're taking on right so I think it's pretty difficult. Yeah. And it's also the context. I think it especially as systems continue to grow, it's like there is this level of maintenance that is needed. It's like counter kind of counterintuitive to the idea of software, but it's like as you know, if you've scaled any kind of a software company to a certain extent.

50:11 It's like it's not like the software is not just like, oh, we have the software now. It's like, okay, we don't need engineers anymore. The software is already built. It's very much like a hands-on. So, I think there is a level of surface area. Maybe there's some kind of like mathematical a lot of this, but where you do just need an ambient number of engineers to be able to have context on everything or at least be able to figure it out in a relatively short period of time.

50:34 Stuff does inevitably break somehow. But yeah, so I think a lot of that will start to start to get rewritten as AI gets more powerful. So interesting to see how that how that evolves. But I mean, no doubt for the teams that are on the smaller side, it gives you guys superpowers. you guys are able to ship like you have, you know, maybe 50 engineers, which is which is pretty exciting.

50:56 But I mean, speaking of that, let's let's talk about the DevNet. It seems like you guys got the DevNet up in a year roughly.

51:02 Just a couple months.

51:04 Just a couple of months.

51:05 Okay. So, what have you guys seen on on the DevNet? What is filling those 100,000 transactions per second? What what kind of applications are already there? And and who's I think you said you've got some dexes and stuff like testing it out. Maybe you can't say who they are, but like what's the activity on on the network so far?

51:24 It's pretty good. We get sporadic activities. I don't want to exaggerate when there isn't a thing, right? Cuz like devnet, nobody really cares about devnet unless people are really interested in testing it out and building. So you get folks who are testing it out from our explorer page. There's like sample swap people can use, right? It also streams the real-time price data over.

51:43 You also have developers who are deploying programs swap, right? They want to build front end interface. There's like Telegram bots, you know, build some meme related and there we saw them testing. And then there are also people who want to DOS Solayer. so they sending a lot of RPC costs to try to make the chain go down, right?

52:02 It's I mean you saw that with most of the you know other dev net launches. So that's what you see so far. I think it's pretty it's very stable and then we've not gone down. So that's the doing better than as far as like that's all we see.

52:19 And then when is I mean obviously you probably don't want to give any exact timelines but when is mainnet sort of planned? Are you guys just sort of seeing how DevNet is is rolling out and stability there? How long until we actually go live?

52:33 September and October.

52:34 Okay.

52:36 Wow. That's pretty soon.

52:37 Yeah. We we don't want to make a promise and deliver in 10 years or in many cases never delivered. I just we we think this is interesting like to us you know even peing this direction is as much it is about a business you know justifiable case for business as it is interesting personally right this is just like super fun and I think it's fortunate that we got the marriage of the two but that's really how folks are thinking about it internally and and so I I think they'll ship very fast

53:07 Absolutely yeah it makes it so easy to to work on it and just have an insane amount of progress happen in a short period of time because it's a thing that you're thinking about even when you're like not sitting at your desk. If you're taking a shower and you're like thinking about technical problems and stuff like that, like you can guarantee that you're going to move faster than somebody who's not because I mean really that's what it takes with a lot of these new fundamental like architectures.

53:30 I mean there's just so much thought that does have to go into to be able to get it to production and actually proven out.

53:35 Yeah. And sometimes just spontaneous, you know, thinking or ideas that just came to mind and or epiphany, right, as people call it. It's like you can't really plan it like, you know, I'm working from 8:00 to 6:00. That's when I think and outside of that, I don't think I don't think that that ever exists.

53:52 Oh, ideas work.

53:53 Yeah.

53:54 Right. Either either people are thinking about it all the time or they just don't think about it and they always keep delaying. I think there's no like in the middle option.

54:02 Absolutely. You cannot prepare for the spontaneous ideas. It will come to you in in you know while you're sleeping at night or something like this. You truly do enjoy it. Yeah. But I mean and you guys are also launching with I think like a yieldbearing stable cocoin. Is that right as well?

54:16 That's also a side hustle. But yes,

54:18 Side hustle. Another side hustle.

54:20 Restaking I did ETH, right? So and we completed the ETH one pretty f sorry Solana one. So pretty fast and our so has a higher yield. So we have a base layer assets that's much higher yield and now I mean we'll continue to build the community and marketing as do many other projects but we're just thinking there's something else we can build.

54:42 Yeah.

54:43 So we we we picked this angle where we worked with OpenEden. I think they're also going to launch

54:48 Their whatever tokens very soon or the protocol governance. So we're building it on top of them as the actual T-bill custodian because they're regulated in Singapore. like we kind of checked all this stuff. So, and then we don't handle redemption and maintaining but we're we're in charge of the liquidity provisioning the actual redemption and the maintaining protocol like what we're pro writing the protocol such that RWA assets redemption and maintaining can be a a primary transaction as opposed to a swap transaction.

55:17 So for Solayer sUSD you can swap in sorry you can m $10 million of USDC there's no slippage zero.

55:25 Yeah. And then obviously,

55:27 Yeah,

55:27 Obviously you guys don't have to take on all the overhead. I was because I was thinking like, man, that must be a lot of like you've got to build now this whole like offchain custodian to have like T bills and invest in T bills and then have a vehicle to make that liquid when people want to redeem and all this stuff.

55:41 But yeah, that makes a lot more sense.

55:43 It's too much.

55:44 Yeah.

55:45 Yeah. We picked a very special angle that where one smart contract would do the work and there's also external parties that we engage with that does the liquidity provisioning but it's on a orderbook basis. So you put in $10 million they give you $10 million worth of that there's no slippage.

56:02 Yeah. And I so I mean all of these things that you guys are shipping and it seems like at you know insane speeds I think probably underlying because of a lot of the decisions that you've made in terms of like how to how to build it and how to ship it. What is the bottleneck for you guys to get to?

56:20 Let's say you know you want to have mainnet out and you want to have you know how many ever billions of dollars of of TVL. What's the bottleneck? what's the main thing that's standing between where you are now and that you know I don't want to say final goal but you know let's say a milestone like that

56:36 Yeah so there is this consensus part that we need to test it at a larger scale and there are also you want to hire more people right so that's you know just to be in charge of the devnet like there needs to be dev rail there needs to be you know constant load testing synthetic load generator there's different components right and RPC is also a big one we need to have people who are dedicated to RPC because all the indexing is real time.

57:01 It's a large volume. If you're running at a million transaction per second, that's 10 gigabits per second. Even if we reduce it to just 100,000, the rate we're running,

57:11 The ingestion pipelines one gigabits per second.

57:15 Yeah.

57:16 So that's about 120 megabytes of data to be indexed

57:21 And in store, right? excluding the indexing part of it. The lookup table itself is going to add another 10 20% of the workload and it's going to be a distributed cluster of machines and that's just to key value lookup. And we're not just doing key value lookup. There are composite RPC calls that would require us to actually assemble the data from multiple locations just and and provisioning and data replication.

57:45 It's it's a lot of u you know things to get right.

57:48 Yeah. Yeah. a lot of engineering bandwidth and a lot of it comes down to just the quality of decisions that you guys make and like how fast you sort of like are able to test that and then iterate on it and ultimately end up

58:01 One good thing is that the experience from our past to be able to pinpoint exactly what the problem is. So we notice something we probably know where the solution is and we're just familiar with it. For example, there's like this transmission data synchronization issue on the surface just like it's falling out of sync. We know very quickly what to test and we know by our experience if that number seems right.

58:25 So that's that's the I think where it really helped in in in in the past. And there just not just one person, it's many people on the team who can make that judgment call and would ultimately lead to fast resolution of

58:38 Of problems.

58:39 Absolutely. because I think you can get stuck in this loop where like you said if you don't have a benchmark for a lot of these numbers and it gets hard to figure out where the actual bottleneck is and you could it's dangerous because you could spend all of your time trying to fix this one segment but it's like really that's like actually already pretty optimal and there's like just not much to be done about that but it's really something you know downstream of that over here which is the actual problem which you know you wouldn't even know if if you didn't have the experience and that's where the huge efficiency gains come from.

59:08 Yeah, absolutely. And that is not something folks can rely on AI about.

59:13 Yeah.

59:14 AI doesn't have the holistic architecture of what the system and also doesn't have the benefit of the conversation of what happened before and the vision, right? So, I think it's it's really it comes down to the people and and I do agree with you. That's the biggest time saving. You can have a team working on something because they're actually not working on it actively.

59:31 They're just like thinking what they can do. That's most of the time you know what is happening or there's a bug that you just getting stuck and then that like you can't even solve it right like even if it's a mouth went went past it still can't solve it.

59:44 Yeah.

59:45 Yeah. And on that side of things I mean I I can imagine finding new engineers who kind of meet that standard and have the relevant experience to match the existing team members that you have is got to be a challenge. So like what's what's your approach on that side?

59:58 Yeah. So generally there are three things right from a company perspective we wanted to have experience we want that person to have to be a fast learner

1:00:09 Y self-motivated blah blah blah the desire qualities and companies also want that person to be cheap

1:00:15 Right it's impossible dilemma

1:00:20 I don't think you can ever get many folks that at meet all right

1:00:25 So I think either h so we either hire people who have proven to have a lot of experience and they can contribute to in a certain segment just because they have done a lot of work right yeah either you're writing Linux kernel you've been doing database for a long time you kind of understand all the ins and outs of operating systems you kind of have the hunch of what what went wrong right and what magnitudes are or we hire you know on the inexpensive side right so we take that we take that box and we we do you know fresh grads but they have to be super smart and they're fast learner I don't think it's very difficult to learn and computer science is a very interesting area where if you have the passion to

1:01:04 Do it, you can do it and you can do it super fast. So I think it's a it's a very clear if somebody is a fit for the job.

1:01:11 Yeah, I think that's one of the largest sort of like arbitrage opportunities in business in general. It's just, you know, maybe it's a little bit counterintuitive, but being willing to spend top of market to get the people who already have the experience and are going to ultimately give you returns that are, you know, maybe 5x more, but you might only be paying them like 30% more than than market average to be in the top 90th top 10 top 10 percentile of of pay.

1:01:42 And especially I think that goes especially true for a lot of these like very focused like hard technical problems, hard infrastructural problems for the people who have worked with these types of systems before and you know may have like this deep experience cuz I I will say for stuff like where it's a new grad and you guys have probably seen this and and positioned yourselves accordingly but like the new grad is probably going to have a little bit of a harder time trying to figure out like a new consensus mechanisms where you know you can completely remove the bottleneck but they can you pick up a new codebase and start to contribute to an existing codebase and and build out some of these other features at a way faster rate.

1:02:18 So I think it's kind of interesting there's different kinds of problems where it just feels an outsider's turn to be able to go and be willing to expend.

1:02:26 Even if we do a consulting approach, I think that also makes perfect sense, right? Like even they charge let's say $1,000 per hour, right? Which is you know most lawyer charge that amount and they don't really speak very in a very u productive way. But I think if you go with anybody who's technical and they charge that rate, it's going to be super it's consistent that output.

1:02:47 Yeah.

1:02:47 Because you're only going to get that response from people who have experience and I think it's it's a good deal, right? So I think I think that's also another approach that one could consider if there is no immediate resource available.

1:02:58 Yeah. And now with AI, you can even leverage that, right? Like your most expensive employees become that much better of a deal because they can have even more output just off the back of that. But yeah, so I mean amongst all the things that you guys are shipping, you know, sUSD, the Emerald Card, DevNet is is now live.

1:03:14 What else, if anything, is is on the horizon that maybe we should push folks towards? I mean, obviously we can we can send them to your guys' Twitter and website, but is there anything coming up that folks should know about and and probably go and check out?

1:03:25 Yeah, our our focus is the chain devnet and I think they should check out the DevNet to see how faster it actually people don't really experience the throughput. Yeah,

1:03:35 One million doesn't really matter. What what people do experience is the latency when you try to do something and instantly gets confirmed. I think that's the thing that we're trying to push for. and I think that's that's just a very different experience because I used Arbitrum the first time was like, wow. And and I think we want to be able to recreate that sort of experience.

1:03:53 Yes, the trust assumptions have changed a little bit, right? Basically, we're trusting Arbitrum, but for this we actually relaxed the trust assumptions to to be more decentralized in this case. So we would definitely be more focused on this. The the other solutions are very useful. They are sort of sort of the product suites built around the DevNet launch.

1:04:12 We'll continue to invest in those because they're growing as well. But the core product for Solayer Labs is definitely going to be layer two. Sorry, not layer two, the the Solayer InfiniSVM or layer one. I mean, we don't call it layer one. It's just hard to characterize. Sometimes they call layer two because easier.

1:04:28 Well, you know. Yeah.

1:04:30 The mental model of it. Yeah. Yeah. Yeah. No, I definitely remember I mean similarly like interacting with I think it was like Phantom back in the day. The UX of the Phantom blockchain was just like a stepwise better than of course like Polygon especially Ethereum. yeah and even some of these other chains and I think even other some chains still haven't even caught up to that UX today.

1:04:51 But yeah, so I I think if folks can just go and and see that and interact with it, I think they'll start to see like, hey, blockchain doesn't have to be this clunky. And yeah, it's it's all about the feedback loop. So, first of all, of course, we'll we'll have the the links to the Solayer Twitter down below.

1:05:08 Of course, we'll we'll link the website and everything like this so folks can can go and check out, go and see some of the DevNet applications and there's a UI up that they can start to use. But yeah, I mean other than that, just want to say first of all, Jason, thanks so much for taking the time to hop on, dude, and and discuss everything about Solayer and what way you guys have built so far.

1:05:26 Yeah, thanks Jason.

1:05:26 All right, thank you for the opportunity. It's great. It's been great chatting with you guys.