That was weird. Like I didn't expect NFTS to
take off. I didn't expect meme coins to
take off. I think the big innovation in
blockchain is actually that you can create programmatic market
makers through Amms and all these kind of clever curves that
eliminate a lot of the layers that you have in Trad 5 that are
necessary to get to run Trad 5 based trading.
My feeling with MEV was that we need to maximize competition so
users always have the option to go to the best source force for
their trade. Whether that means that
validator is maximum sandwiching and I'm giving everybody a
rebate, that could be one model that actually works.
If there's truly an exploit and you continue running the chain,
even if you allow like define liquidations to run, they're
mixed in with exploited transactions as as Ethereum
folks, I don't know if you're around for the Dow hack.
The only reason they were able to deal with the hard fork is
because it was locked. All that, all those funds were
locked up in the smart contract that connects it.
If they started getting mixed with a whole bunch of things
like it's just impossible to unravel.
You can't roll back the real world.
There's action that's taking in the real world based on the
chain state Circle is sending funds out based on like mint and
burns, right? I think once you have 4 clients,
you could say that the probability of a bug in three is
so much smaller than the probability in bug in two that
it's fine for one to be down. And then you can do this kind of
maintain some lightness while while one is down and and
rotate. Welcome to Epicenter, the show
which talks about the technologies, projects and
people driving decentralization and the blockchain revolution.
I'm Brian Crane and today I'm joined with my guest host,
Martin Krapplemann, who is the founder of Gnosis.
And we have a very special returning guest today, Anatoly,
the Co founder of Solana. Of course, Solana needs needs no
introduction. So we're excited today to talk,
you know, get into the wheeze a little bit of where Solana is
at, what's coming for Solana, some of the challenges.
So really excited for that. And now, just before we go into
it with Anatoly, I want to share a few words from our sponsors
this week. If you're looking to stake your
crypto with confidence, look no further than Course one.
More than 150,000 delegators, including institutions like Bit
Gold, Pantera Capital and Ledger.
Trust. Course one with the assets.
They support over 50 block chains and are leaders in
governance or networks like Cosmos, ensuring your stake is
responsibly managed. Thanks to the advanced MEV
research, you can also enjoy the highest staking rewards.
You can stake directly from your preferred wallet, set up a white
label note, restake your assets on Eigenia or Symbiotic, or use
the SDK for multi chain staking in your app.
Learn more at Chorus .1 and start staking today.
This episode is proudly brought to you by Gnosis, a collective
dedicated to advancing a decentralized future.
Gnosis leads innovation with Circles, Gnosis Pay and Metri
reshaping open banking and money.
With Hashi and Gnosis VPN, they're building a more
resilient, privacy focused Internet.
If you're looking for an L1 to launch your project, Gnosis
Chain offers the same development environment as
Ethereum with lower transaction fees.
It's supported by over 200,000 ballot errors, making Gnosis
Chain a reliable and credibly neutral foundation for your
applications. Gnosis Dow drives Gnosis
governance, where every voice matters.
Join the Gnosis community in the Gnosis Dow forum today.
Deploy on the EVM compatible Gnosis Chain or secure the
network with just one GNO and affordable hardware.
Start your decentralization journey today at gnosis dot IO.
Cool. Well, thanks so much for coming
on and totally, it's really great to have you back.
Yeah, thanks for having me. So I wanted to start off with,
so the original Solana vision right from, you know, now it's
like 7 years ago or so was to have blockchain at NASDAQ speed.
And you know, at the time, Solana was really pretty alone
in trying to do a blockchain, you know, a single chain, high
throughput, maximum performance speed, the time sharding was
like the hot thing when it came to how to scale blockchains and,
and you guys were kind of alone. Of course, today, you know,
Solana has gotten lots of traction and also the idea of
single throughput chain has is something that's gotten a lot
more traction with a lot of other companies pursuing
something similar. But just just sort of zooming
out, like when you think back to your vision at the beginning and
where it's at right now, how do you feel about it?
What do you think is are some things that you know happened
like you planned? What are some things that maybe
haven't worked out? Yeah.
I mean a lot of stuff kind of came true that I thought would,
but just in different order. Like the, the order was
unpredictable and the applications are also were
unpredictable. You know, we, we thought that
trading was going to be a really important use case, but we
didn't think it was going to be the most important use case.
I think to me that's pretty obvious that like execution of
and launching assets and execution of the trades between
them is what's driving most of the volumes and revenues for
across all the applications and block and, and layer ones and
layer twos. This is where all the fees come
from. And if you don't have revenues,
you can't, no matter how many tokens you launch, you can't
afford to pay all the all six engineers.
Somebody somewhere has to figure out how to, how to make
revenues. And I, I think that came true.
But what surprised me was that how slow Trat 5 was adopting
this stuff. I expected like stocks and all
of these things to be the main usage.
But right now it's basically like gaming.
Like it's an NFTS and meme coins are like, if you look at Twitch
streamers that are streaming trading it, it's exactly the
same content as when they're streaming mobile gaming or any
kind of game. It is effectively gaming.
It's just kind of PvP loot boxes.
This is what I kind of how I think of it.
That was weird. Like I didn't expect NF TS to
take off. I didn't expect meme coins to
take off, but they're using the same technology.
It's the same kind of escrow auction processes on chain.
I thought like central limit order books would be the killer
way to run markets on chain. But I think the big innovation
in blockchain is actually that you can create programmatic
market makers through Amms and all these kind of clever curves
that eliminate a lot of the layers that you have in
Stradfight that are necessary to get to run like tradfight based
trading. And that's pretty interesting.
And even if the Amms are less efficient, the cost that you
spent on professional market makers like citadels and jumps
are still large that you might actually as a early stage
company, you might be better off using an AM to be honest versus
like the the more professional Triadfi approach.
That was unexpected. And I think that's a legitimate
innovation. I think where you see the
explosion of assets and how they're traded, it's primarily
through automatic based kind of market making approaches like
curves and bonding curves and AM Ms. and stuff like that.
I I would like to jump in on a topic you you hinted at and I
think it's people have very different opinions about it.
What makes blockchain valuable? Where does or you, you mentioned
fees and said, yeah, somewhere there needs to be fees.
And I think at least in Ethereum land, there is kind of this,
this, this debate between should either be just money and somehow
that's where the value comes from or should should there be
transaction fees? Seems like you have a very clear
clear answer here. I'm traditional conservator.
You have, you know, discounted future cash flows that would
give stuff value. There's exceptions to that, but
I think they're the outliers. You can't engineer for them.
This is the problem that I have with like, oh, Bitcoin is so
successful, therefore we must build a better a better Bitcoin.
I don't understand the engineering reasons why Bitcoin
is successful. So therefore I cannot build a
better Bitcoin. So would it be fair to say the
number one or you could have one absolutely crucial success
metric for Solana is overall fees.
Yeah, I think the the network needs 7 of fees to pay for all
the engineering effort and the validators and all this stuff.
If it doesn't have that, I think they will eventually die that
that's kind of my belief. So where do you think fees will?
What will be the scarce thing that people will pay fees for?
So I mean, generally speaking there is, is it just general
block space or you would say block space in general will be
more or less free and it's specifically congestion block
space or congested block space or?
Yeah, I think what the value that these systems provide is
the F state that has an economic opportunity with cost and the
pre organization to access that state.
And this is where you can charge more than the, the hardware and
the bandwidth and all the, the nuts and bolts.
And if you're purely, purely selling hardware, you know, 1000
replicated amount of storage or whatever, you can only charge so
many more multiples off the cost of the hardware, like maybe 10X.
Otherwise a competitor will just underbid you and you will lose
this way because hardware just constantly keeps getting cheaper
and cheaper. And your dominant costs are
always going to be the people, right?
Like it's just the at the end of the day, it's the you got to pay
for the, all the, all the engineering stuff.
So this is where I think like probably again, why Solan is so
has such a different road map than Ethereum is that I, I think
that the network cannot survive without the execution layer also
paying for, for the all the cost to build the data availability
and all this other stuff. The execution layers where you
can charge real real fees based on content and everything else
has to support that. So the, I mean what you just
said kind of priority access to, to yeah, economically important
content kind of mev, right. Yeah, yeah, absolutely.
SO11 theory people have been discussing is that MEV was or
definitely in Ethereum for a while it was very much captured
by the chain and and by validators.
But to some extent now it seems to be moving more towards the
applications or in principle applications have the power to
yeah to kind of add extra rules on top and and kind of protect
their MEV. Do you see that as a as a danger
for Solana in that case? No, no.
I think it's the goal for Solana is to so there's designs for
application sequencing. I actually proposed 1A while
back called program writable accounts.
I don't know Brian, if you were involved as shooting down that's
empty. But basically the idea is that I
felt that it's important to for apps to be able to set the cost
to, to take a right lock on their state.
So that economically important state that's important to
access. If the application can say, hey,
to be able to write to the state cause access really means right
to modify it to take that offer. I want to set the fee and have
that fee be application specific and dynamic and controlled by
the business logic of the app that would eat into some of the
fees that the chain captures. But what's good for the goose is
good for the gander. Basically that system would
preserve atomic composition between applications and the
cross atomic all the arbitrage between all the apps that are
extremely profitable that you cannot remove, right.
If if each application then moves off chain and runs their
own L1 or L2 or whatever their own separate environment per
app, then you lose that atomic composition and you effectively
lose those revenues. So what I want to see is the L1
Solana, this giant, one giant atomic state machine, its
revenue to be mostly driven by this, the, the opportunities
that arise from having everything in one, one's giant
state machine that's synchronous, that's fast, that
that's as cheap as possible. And then give the application
the tools to capture whatever, whatever fees they want.
And they can tune them, set them higher, lower, distributed them
to the token holders, distributed to the makers
instead of takers, you know, prioritize cancels instead of
other orders. So a bunch of whatever they want
to do, I want to leave that to the application layer.
And this is I think where Max Resnick and I like really mind
melded because at a gut level, I, I thought that we need
multiple block producers at the same time to create a dynamic
market that's competitive for people to accept these
transactions. And he kind of came, came for a
from a more economics research angle where he saw that if you
don't have multiple proposers, then applications cannot really
build these value capturing systems at all because the
validator will be able to effectively censor.
And if you, if you're censoring all the inputs that are going
into this application specific sequencing thing, then you can
effectively control the fees that the app sets anyways.
So what you need is like you need both of those pieces.
You need the hooks and the system for apps to be able to
set their own fees. And you need the competition
between block producers. And I'm 100% on board with all
those changes, even though on the surface they seem to give up
some of the economics of the apps.
But the goal is if we have all the apps in one giant system,
the economics between all the cross application arbitrages are
going to be way more than enough.
So with regards to MEVI think you've always had, you know, in
many ecosystems people have been like, oh, MEV is a bad thing.
You need to minimize MEVI think you've always had a a more
positive view on MEV or like how do you view MEV and how do you
think ME VS going to develop with those changes in the
future? A market maker submitting their
cancel before everyone else is MEV.
They're they're getting priority access to state the head of
everyone else, they're paying for it to the exchange or to the
whoever right that is MEV. But that creates better markets
because then the market makers can have tighter spreads.
So my feeling with MEV was that we need to maximize competition
so users always have the option to go to the best source for
their trade. And whether that means that the
validator is maximum sandwiching and I'm giving everybody a
rebate, that could be one model that actually works.
That's fine as long as it's competitive and the users can
make that decision. And I suspect that each
individual users are likely to make that decision unless
they're pro. But like Phantom that wants to
serve the best possible blockchain to their users,
that's competing with Sol. Flare with Backpack will make
the informed decision to go with a particular solution for how
they route their transactions and stuff.
But we need competition for that, for all that to work out.
So my view is that like the stuff isn't all that different
than a you're I'm selling block space, I'm buying block space.
For me to get the best offer, I need a healthy market of buyers
and sellers that that's kind of the basics that we need.
So in Ethereum proposed a builder separation, right was
like chosen a few years ago and it's it's the state today.
What do you think about Solana? Do you think we will also end up
with proposed a builder separation and is is it
something desirable? I don't know if there's anything
we need to enshrine for that to work.
Like it's kind of happening right now.
I don't, I don't know if there's changes to the like if you need
like enshrined bundles, I don't have any objections to those.
What I do care about is concurrent block producers.
So multiple concurrent proposers or multiple concurrent leaders
that we have like 2 validators, 1 in Singapore, one in New York
that are running there that are both accepting transactions.
And the user can has the option, do I send to the closest one in
New York or maybe one that's further away that's offering a
better deal? And if I'm a market maker and I
need my cancel to to land, what that means is that I can send to
the one that isn't censoring and I can.
And the network the the actual enshrined protocol needs to
support an ordering mechanism where I can pay the network
within this block. I'm paying a fee to go first.
So does that make sense? Yeah, I think that's definitely
one of the topics. I know there's a huge focus for
you and and I think currently in the Solana developer thing is
this multiple concurrent proposer.
So for you, the main reason why you want that is because you
want competition between validators and you want
basically less ability for validators to kind of, you know,
gouge the users or like. It's also a beautiful thing
because this is a way for a truly decentralized global
blockchain to beat Stradfi, to beat NASDAQ on actual pricing.
And this is a very subtle thing that the changes here is that if
like the how like you think of the network or any exchange or
any of these systems as reflecting of the world state
and it has, there's an error between that state and the real
world. And constantly people are trying
to reduce the, that error by submitting trades.
They see something, a price that's offered, they have
information in the real world, they're trying to close that
that error. And if like some event happens
in Singapore and there's a local leader there in Singapore, the
latency for me to submit that trade is much, much shorter than
to send it all the way to New York.
So for Solana as a blockchain TQB with NASDAQ, we need a block
producer in every spot in the world that has any economic
activity. So then the user can submit that
transaction locally and cut that latency.
But. I, I, I, I want to understand
that because, because, or at least in, in Ethereum you have
for an upcoming block, you have exactly 1 proposal and, and that
one might sit in New York, they might sit in, in, in, in
Singapore. So in Solana it sounds different
or or is is it still the same? Now that right now that's that's
exactly how Solana works. But there's no reason why you
can't have two proposers or N. OK.
But then let's say, OK, so now on the same, yeah, slot height,
block height, you have now 2, one in New York, one in
Singapore. So now let's say they would have
two conflicting transactions here in one.
Then how? How is this merged or how is
this resolved this this conflict?
There's a deterministic merge, so we need that it has to have
that property. And two, if I want to go first,
I should burn some soul to be ahead of somebody else.
It this merge will be on on the whole block level or an
individual state? Probably.
I mean, probably. You you can think of it as a
block that is a chunk of data, right?
One MB, 2 megabytes, and the first half is written by
proposer A, the second-half is written by proposer B.
The network receives the entire block and then has runs a
deterministic merge to compute the results.
I see. But you can have any number of
these proposers. The main constraint is basically
we think we don't know until we test is how many shreds we can
propagate through the network, and shreds is our term for
erasure coded chunks of the block.
But, but it also means that if you if you hit, if the
transaction hits your local proposal at that moment, you do
not, you don't know exactly what happens.
You then need to wait for kind of some second round.
Or is the merge round essentially to to?
It's not. It's not a round once you
receive the data from the. Yeah, that's right.
Then you can locally. Yeah, I see.
Yeah. So the network could effectively
the latency there is isn't really lost because as soon as
the network receives the data, it can vote on confirming that
the data has landed. So as soon as you see the
confirmation, you can compute the results and you don't need
to wait for everybody to compute the results and confirm that
because that part is deterministic.
You obviously like, if you're a professional like system like
that's like a custodian or or a bridge, you might want to run
different boxes with different one fire dancer, one Anza.
Make sure all of them agree on the results.
Essentially. Essentially the blockchain would
then become a a deck, right? Or I mean that what is directed
a cyclic graph? No, it's different from a DAG.
Dags resolve their ordering based on the next, well producer
that then decides the ordering of the previous transactions.
This you have literally concurrent leaders.
It's no different. It it is like leader one writes
the first page, leader 2 writes the second page, and then you
mix them together. The the shuffling here is
enshrined and deterministic, and that's different from the tag.
It's not dependent on the next producer.
So if if you have these two proposers and let's say there's
some arbitrage opportunity and now people they've both
proposals put in transactions that both try to capture the
same arbitrage opportunity, then basically it will get merged and
then whichever is the first one actually gets executed.
Yep, so the highest burned one the the one with the highest
burned for fees will execute first.
OK, OK, OK. What's the?
Hardest thing about making multiple concurrent proposals
happen though. What?
What are the problems that you need to solve?
The stability of consensus basically like it's just the
implementation is like prone to outages I would say, but isn't.
I don't think it's design wise any worse for the worst case
because consensus mechanisms all deal with a single leader that
produces two different blocks. They all have to resolve that.
Even if you slash that leader right?
Do you still don't want to have an outage in case that you have
a bad leader? So the worst thing that you want
to do is have a, is have a performance segregation and
slashing for performance segregation is fine because then
you reduce them in practice. But you cannot, you still have
to deal with it no matter what. So in an environment where you
have two leaders, the the network will see four different
views potentially of the results of the block only leader A, only
leader B, neither or both. So and the deterministic shuffle
would be different for each one, right?
If you only see data from leader A, then you just stick leader
A's block. If you see both, then you
shuffle. If you see neither, then you
skip. And this is the complex part.
What you want to do is you want to make sure that there is no
partition in these views. So every time they vote, they
take the happy path. It doesn't matter what partition
they see, as long as everybody in the network sees the same
thing. If everybody sees that leader B
failed, that's great. It means that they all agree on
the vote and that you continue doing the on the happy path of,
of the consensus rules. And Solana, like we, we built
our consensus. It's very complicated and a pain
in the ass to work with, but the properties that it has that
previous systems didn't have is that it was bandwidth efficient,
that you have a block on every point in time, that there was no
stalls waiting for rounds to to finish before the next block
starts. You start.
We now see systems like I think Aptos and Zui have gotten that
to work with more modern consensus algorithms.
It's a whole team from Zurich optimizing and basically getting
rid of all my technical debt to to have like a a better version
of of consensus on Solana. And again, we can maintain a
bandwidth efficiency and we can deal with all the partitions.
Then talking about yeah, efficiencies, what are currently
the bottlenecks or yeah, what, what's currently the bottleneck
for scaling in Salon? It is basically you've seen like
I think like Eclipse and a bunch of other kind of Solana SVM base
layer twos to tune up the compute units.
So basically the the bottlenecks is making.
Sure that you need to you need to help me here so say again.
There's a whole bunch of not Solana layer twos, but layer
twos that use SVM. Some may even be Solana layer
twos. I don't even know what what the
marketing, I, I don't know. I don't know.
I I don't even know which state route they're looking at.
Is it Ethereums or Solanas? It doesn't matter.
I treat them all as competitors 'cause if the fees accrued, they
are not accruing on mainnet, they're not paying for mainnet
development. So and they're fine.
We're all, it's all, it's all good.
We're all building open source software.
So it's like Red Hat versus Ubuntu.
It's, it's healthy competition. But they've been able to
increase their block capacity, I think by factors of 5 to 10.
So it is basically the blockers are is just testing.
It's just making sure that when we, when ONS are in Fire Dancer,
increase the capacity that there isn't some, I call them like
they're denial of service attacks.
There isn't some metering problem in the VM or in the
block or whatever that an attacker can exploit and create
a block that takes 10 times more to process than normal.
But these are basically like the the the worst case kind of
scenarios that they're pain in the ass to find.
Let me just repeat because I'm not that deep into Solana.
So you're saying yes, there are. There are versions essentially
of Solana, the SVM, that already run at 5X capacity of what
Solana does right now, and it kind of works, but you are
slightly more conservative and and.
We have to be right. Those are not decentralized,
right? They're basically roll up like.
But even doesn't matter there earlier they can take more risk.
That's the difference. If if we if we were just
starting out, I would I would tune the network to 10X
performance and deal with the fires like that's the
difference. So I mean the other, the other
point you were making is that you would say kind of L2's are
not really interesting you would say to Solana from from from an
economic or fee perspective. So, so you're.
Interesting to me, yes, those people that they're interesting
too and that's fine. But what I want is mainland to
succeed, right? So to me what matters is
activity on mainland trading and mainland.
So essentially the whole idea that I kind of kind of the
Ethereum idea that somehow you would provide BLOB space or kind
of data availability or transaction ordering and then
other use it for other space that that you don't.
Ordering. If you could do ordering then
yes, but there isn't. I think the base roll up thing
is still not fully defined and if the chain is doing ordering
and DA the based roll up the only difference is then like a
different virtual machine or something like that.
I, I, I do very much agree with you.
So there. So I am also in the, I'm kind of
in the Etherium camp of if, if roll ups, then it, it should be
based roll ups because I feel like if Etherium is trying to
sell something, it cannot just be generic data availability
because that's a commodity. It needs to be specifically
transaction ordering. We we already have based roll
ups done like there's there's already like ZK proved Merkel
trees or like classically proved Merkel trees book leaves for for
spade. To me, the interesting thing
about based roll ups is that they kind of still have this
atomic composability. Or you can have atomic
transactions that touch A1 and A2 state.
And, and the advantage is I, I, I think it's fair.
It's fair to say, OK, you still have some validators that have
all the state. And then it almost doesn't
matter whether that's on the L2 or on the L1.
But if you care about being able to have lower performance or it
kind of have validators, I mean, well, here's my debt note
sitting next to me that runs Ethereum and I can still do this
from home. If you care about that, then it
does make sense to say OK, some state that kind of exists, but
it doesn't have to be available to anyone who's who's running a
validator on the other one. There's already sort of stuff
like that running on Solana. So Metaplex built this thing
called compression. I don't know if you saw this
terrible marketing name, I came off the bat, but it's basically
a Merkel. It's a Merkel root that's on
chain, and you can atomically prove the data exists in this
tree and another piece of data exists in a totally separate
tree, push them to the L1 state-run a computation on them
through a program like a token swap, and then push them back
into the trees. All of this in a single atomic
transaction. So the state that is effectively
cold can be offloaded and run programmatically in these Merkel
trees. And the primary thing that
they're used for is like NFT, like you, you mint your 20,000
NF TS. You can instantly like mint them
in one batch or one Merkel tree. And you just register the leaves
with the chain so wallets and stuff can pick him up.
And there's now ZK based approach to make the proof
smaller and and a bit more composable.
But that part is is like the easy part.
I think the based roll up is a bit more a a bigger piece of
technology than that. It involves developers defining
their virtual machine and the the state transition function
that connects their VM to the state root on the L1.
My problem with those is that there's just no need for that
many re amps like I'm sorry. Frankly, frankly, I, yeah,
frankly I I would also kind of for the base roll up say just do
EVM and. Kind of just what's the point to
have like a dozen different EVM based roll ups?
The the point might be to reduce to kind of still allow people
to, I mean run relatively lightweight L1 validators and
kind of say if you if you want to do the full thing, then you
run the L1 and and the L twos and have the full state
available. But how's that any any different
from like I have a like a program that has like a
dedicated circuit, like AZK circuit, and I just proved that
program like I don't need any VM general purpose CVMI have like
my my minimize whatever the like Lego piece of of a smart
contract. I just prove that smart contract
only. And now I have a way to route
data through that thing through the L1.
So you have your transaction approves the state calls the
contract, right with approve calls another one and then like
a a series and then it's done. So that's effectively like the
old stateless like design, right?
Like like what? What is the difference between
that and the base roll up? Like why?
Why aren't base roll ups just simply smart contracts?
I think you can view it as that. Yeah, then like those already in
fact kind of exist with some traction like they're useful for
I think like large like if you're trying to air drop to a
very large user base and that kind that kind of thing.
People have found tractions with that, but they haven't found
traction with like like what what I think is, is kind of
interesting that you see that works well is like Jupiter,
Radium, like even pump, all these things are all really,
really tied together and the execution and you can see in the
transaction that a single transaction will hit like 5
different markets all at the same time.
And we haven't seen like anyone be able to build AZK based or
something that is truly off chain that still plugs into the
atomic execution piece for trading.
So let's talk about fired answer and sort of Solana clients,
right? So fired answer's been in the
works for a long time aiming to, you know, speed up and remove a
lot of performance bottlenecks in the client.
What are your thoughts on, you know what the impact will be on
the network and you see in the future you want to see a bunch
of different clients running in maintenance at the same time?
Do we need a bunch? I think 4 is what people it's
like 4 or 5 is like you kind of need.
Technically you should have 5 for BFT so you can do
maintenance on one and then you still have reliability of 1
going down without a liveness failure.
That's like the dream, but the you just get an astronomical
improvement on safety when you have two like because it, it's
just such a, this is the, the thing that keeps me up at night
is like some bug that auditors and testing and all that stuff
missed. That's a critical vulnerability.
That's a zero day that could steal everyone's funds.
That's the scary part. You have two separate teams that
built the same code. It's very unlikely that they
would have the same bug in both code bases that can be executed
the same way at the same time. So you have some redundancy
there that that's just really, really critical for these
systems. But if fired answer now is, you
know can process more transactions then I mean I would
expect that all of the validators will switch to that,
no, because they will earn more fees so.
No, it's the the limits of set network wise to make sure that
both clients can can run it. And Agave is not a slow client.
He can actually just you can literally just remove our limits
and then run it at like 10X capacity.
Right now. There's no, the, the limits are
there to kind of slowly, like there's no fire to increase
block space because even like during the, the crazy, the worst
case day with like Trump coin launching the fees, the median
fee was like 15 cents a transaction.
And this is when the network is doing 40 billion.
Now that's high. And if that was sustained, they
would become fire. But that being the worst case,
you know, like peak demand, that was, you know, 10% of Nasdaq's
volume. That's actually really, really
good in terms of, in terms of fees.
So there isn't a fire. There is a like, there's a
reason to increase block space that I think is more long term.
And what I care more about is that like every release in bumps
block space by 2040% versus them getting 10X in two years.
Like as long as the developers are pushing themselves like,
hey, what is the, what is the bottleneck that is keeping them
up at night that could be exploited or whatever.
They write the test, they get comfortable with it, and then
they tune that parameter up. This is what I want to see more
so than like let's 10X and then see what breaks and have like a
bunch of weekends everyone has to go like fight fires.
You you mentioned the security improvements from having a
second client. So how would the network behave
in different scenarios? Let's say 10% of the validators
would run. Or let's say Fire Dance is new
and only 10% run it. We need more than 33% run by the
minority clients, so some it doesn't matter where it's but as
long as the the smallest client has more than 33% then the
network would halt. Right.
It would halt. OK, I see.
And that's OK. We're not at the area this.
Yeah, yeah. And you, you see this as
preferable. So you would say if, if, if
there is a buck, then it should halt.
Yeah. And people can quickly fix it
and it's a nega on everyone's face and it sucks and it should
never happen. And there's a lot of effort to
put in to make sure it never happens.
But if there is a exploit, then yeah, please halt like right
away. And then people can go fix it.
That that's the preferable outcome to anything else 'cause
like, I mean, if there's truly an exploit.
And you continue running the chain even if you allow like
define liquidations to run, they're mixed in with exploited
transactions. You fucking that state, the
resulting that state is a nightmare.
It's like it's worse than a 18 hour average or whatever.
Like as as Ethereum folks, I don't know if you're around for
the Dow hack. There was the only reason they
were able to deal with the the Dow with the state, like with a
hard fork is because it was locked.
All that all those funds were locked up in a smart contract
that couldn't exit once if they started getting mixed with a
whole bunch of things like it's just impossible to unravel.
You have like somebody launches a meme coin, the attacker
launches a meme coin, buys it with the funds it's mixed in
with a whole bunch of liquidity. Like you cannot like, really
untangle that in any sane way and.
You'd have to like actually. Roll back.
I think you know and reset from an earlier state probably.
Yeah, to me that is far worse than just a hard line is failure
because that like not you can't roll back the real world.
There's action that's taking in the real world based on the
chain state, like Circle is sending funds out or based on
like mints, like mint and burns, right?
You can't like tell them, hey, go rollback his transfers.
It's better to halt this. This is like I, I think in all
these cases, like it's basically better to halt.
I think once you have 4 clients, you could say that like the
probability of a bug in three is so much smaller than the
probability in, you know, bug in two that it's fine for one to be
down. And then you can do this kind of
maintain some lineness while while one is down and and
rotate. But yeah, the the terrifying
this is the this is like the worst nightmare.
Well, I, I, I want to, I want to ask another maybe a little bit
more on the scaling thing before we go to security.
What do you think is, is possible here?
Like if you think of like, I don't know, 5-10 years ahead,
where do you want to see Solana in terms of throughput?
And do you think it's feasible to basically have Solana scale
to such a level that it can absorb, you know, kind of like
or you can satisfy like all the demand of the world in terms of
block space? Our blocks right now are like 2
to 4 megabytes in size. The New York Times website is
like 20 megabytes, but my my very mediocre goal is to get
blocks to the size of the New York Times website.
Like you don't even need the crazy 2D erasure code sampling
for light clients when your blocks are the size of the New
York Times website. People can just download full
blocks to their phone and nobody like you.
You don't need these like next generation technologies yet.
So, and that would be like a 10X increase and is, is that enough
to handle the, the entire world? I think somewhere between 10:10
X to like my, my belief is that like you look at Google, they
when the their estimated searches per second is somewhere
like around 50,000 to 80,000. That's a fully globally scaled
web application that is fully permeated the entire world that
people use constantly and people use finance a lot less often
than not. So like 100,000 TPS in a single
O1 would cover the 99% of the most important financial
transactions for sure. So somewhere between like, you
know, 1-10 X and another 10 XI. Think that is actually probably
as far as crypto needs to scale. It sucks to put limits on it and
people feel like oh you're being so pessimistic but like I pray
that all my competitors are designing for infinite demand.
That is like the worst, worst engineering trap.
And I don't even tell lots of people to 10X the capacity.
What I tell them is like just two X at this year.
Just think incremental improvements a year that you can
ship confidently and then 2X it again next year.
And just like that, that's so you get to like the the scale
that isn't needed for demand. So 1, I know one project has
gotten a little bit of attention.
I think still, still very, very early, it's 00.
So where they're trying to create this, you know, private
fiber network, do you think that's going to be needed?
Yeah, it's not, it's not really fiber.
And this is maybe I can explain to folks why how it works and
why it's not scary. Basically there's there's
nothing you need to change about fiber.
The cables are all basically the same for like the last, you
know, 30 years and light is very fast.
What, what the differences are is the signal processing in each
hand. The switches that like handle
the, that load the way they're designed for throughput is with
big buffers and those buffers increase latency and finance and
US right, like effectively part of the, the finance world, we
want to have the lowest latency possible.
So what we need is different kinds of switches.
So every data center in the world, you can just go and tell
them, hey, give me this switch, I want a super low latency
switch. I want this dedicated lane and
somebody has to go do that work to go do those deals, talk to
the people and stuff. And but in and of itself, it can
be very decentralized. All these switches are in
different parts of the world and different data centers under
different ISPs. They can all be owned by
different providers or whatever. So that part could actually be
very decentralized. The fiber, no one's going to
change that. It's already laid.
So a, a bunch of the stuff is very much like in spirit of the
Internet and and crypto, I think, but it is one protocol.
And the goal is to use 00 as an overlay just to have a, if the
network is running in the fast happy path that all the messages
like when we need to send out votes that can all go through
the multicast super fast path for 00.
If that fails, they're still going to arrive over the
Internet, you know, 4500 milliseconds later.
But what we want is for the happy path when everything is
working, for things to be as fast as possible.
Cool. On the topic of then security,
so on Ethereum over the many years there have been, yeah,
kind of a number of of huge hacks and yeah, ways where
people lost money. How so far has this been on
Solana? What has been the biggest
security incidents? I think wormhole was the biggest
one and that was really unfortunate bug there was.
This bug didn't exist in World War One.
And then in the second version they introduced this bug where
you could fake the proof that there was a mint on the other
side and an attacker exploited it right when they posted the
fix for it in their public GitHub.
So the attacker was watching their GitHub and waiting for the
balances and wormhole to increase up to the mat.
You know, as as much as they could before they did the bug.
So this is like a professional attacker.
I don't remember for sure, but it might have been Lazarus Group
that sucks like this. This, this stuff sucks.
It's hard to really fix. There's formal verification
companies that I think similar. Similar approach to how they
formally verify stuff in Ethereum is typically you
recompile the code through LLVM and you can use the intermediate
output and run. There's formal provers that can
run on top about to to test some properties I have thought of
like adding like the. The nice thing about Solana is
the code is separated from state.
So you could actually load, in theory, separate programs that
implement the exact same state transition function, run them
both and then see if they disagree and then abort.
Do we need that level of redundancy?
So we have redundant implementations for smart
contracts too. And obviously the user will need
to pay for twice as much compute and stuff.
But like compute is one of the easiest, much easier to scale
than bandwidth. So like to me that that's almost
like a no brainer if it would help.
So that that's scary. I, I don't think Solana is any
safer than Ethereum for new code.
One advantage that that's kind of weird is that because of some
idiosynchronicies of SVM, people don't really write interfaces
for smart contracts. So there's no ERC 20 interface.
There's an implementation of the token program, and everybody
uses that program. So it's like as if you had one
canonical ERC 20. So that means that if you're a
default protocol and you only accept SPL tokens, there's no
way for the attacker to make to create a bad implementation of
your C20 and steal funds from your users.
So that has reduced a bunch of the kind of attacks that you see
sometimes with like pool exploits or like bugs in the the
RC 20s are legitimately like people making bad ERC 20s to
track to to trick users. And that has reduced I think a
lot of the composability friction because then like you
can build a company that doesn't write any smart contracts at
all. You simply just reuse all these
already pre built Lego pieces and they're all composable
because everyone accepts the exact same implementations.
And that's been interesting to see.
So I don't know if Pomp wrote their own bonding curve.
They might have, but they didn't build the AMM, they didn't write
the the token contract. All those have been standard.
Like I think they use the Radium AMM so that that's kind of like
one of the examples about. Yeah.
In Ethereum, I think we had seen first this class of our kind of
bunch of, well, smart contract hacks.
But very recently there was, yeah, kind of a new very, very
large hack that was not related to smart contracts directly, but
rather to, yeah, interfaces being compromised.
And because, I mean, the reality is if you interact with a
somewhat more complex program, then yeah, go to some interface,
it essentially triggers a transaction that kind of on the
interface promises you, you to do something.
But of course, unfortunately, if the website is the interface is
hacked in some form, it is absolutely or at least in
Ethereum. And I kind of would be curious.
About talking about buy bit. For example, yeah.
Or I mean, for sure, yeah, so. It was actually UI interface,
right? The user interface, not the
programmatic interface of the. Yeah, yeah.
It's the user interface. User interface shows you you're
doing transaction A, but to the wallet it's sending some
malicious payload. And the question is now do you
have any chance to understand in the wallet what, what the state
change of the transaction will be?
And yeah, kind of is. Is there a realistic chance to?
I don't actually think that this, I imagine this should be
possible to do on Ethereum, but maybe easier on Solana.
Is that like, because you know which accounts are token
accounts and the implementation of those tokens, they're all the
same. What I've been recommending
people and there's a project called Lighthouse Protocol is
they add guard instruction that aborts if the resulting state at
the end of the transaction is different than the user expects.
So this would also protect you from like the you write a do you
write a transaction? Do you think you're hitting an
AMM attacker does a program upgrade that just steals your
your coins, right? So they fake the simulation like
this is kind of like a classic attack.
You simulate your transaction looks fine, you submit it, but
then something, something changes in the in the chain
attacker sets a bit right? And it does something different.
So to protect against that, you can add that guard transaction
and then your like your cold storage system should have
effectively rules and policies in the cold implemented in the
cold storage. Not relying on the human to go
look at the trusted display and parse that string that actually
checks for that guard transaction and checks that the
spending limits and all the policies that you want are not
exceeded. This is what I have been like
pushing people to do. And if you can kind of get
there, I think with Keystone Wallet, they have a developer
API where you can programmatically sets and rules
sets and stuff. But yeah, this is I, I think
this particular UI hack issues are solvable through kind of
more robust security policies around cold signing and stuff.
I don't know if simulation is much more complicated than
Ethereum, but if you know this is a cold storage system, you
know that it should only be doing simple transfers.
You know the accounts passed to it should only be token
accounts. You can then add guard
transactions that assert all that and restrict the balances.
And then when you hit the chain, it'll abort.
Attacker did something or screwed up the thing aborts,
pager duty goes off. Everyone figures out that's like
what happened, right? I think that that is solvable
with technology. I think stuff that's really
hard, I think it's just smart contracts in general because the
the more interesting ones are like risk systems like Ave. or
Perps or any of these systems that are not just purely
trading, they're managing risk. They have a lot of inputs like
oracles and the attack vectors there are not obvious, right?
You have like there's latency games and exit games between the
liquidity bots and the capital and the contracts.
Those are those are very, very hard to get right and proving
systems can't help there. But I, I think that these kind
of high level smart contracts that manage risk, if they can
scale, they're probably the most destructive part to traditional
finance because this is the entire function of any bank or
any, any fund or anything is managing risk.
If you can automate it, you've and you can scale it up, I think
that's very, very disruptive and and very valuable.
So with regards to smart contract security, I think today
in Solana a lot of smart contracts are upgradable and
it's also pretty common for smart contracts to be closed
source. What do you?
Follow those, just don't use them.
Still do it. You have the power as a user to
not use those. But if you do have to use them,
there's a difference between being an LP into a closed source
smart contract versus trading in it.
If you're trading in it, then use Lite protocol which will
guard your transaction. If that closed source contract
does something wacky, whereas there's or there's an upgrade
that happens in the middle of your transaction, you can
actually protect yourself against that.
If you're an LP, you are moving your funds into that thing and
you're letting in custody your funds.
You should know what who the hell you're giving your funds
to. Don't do that.
Look for open source contracts, look for formally verified smart
contracts. Look for like multi sigs with
time locks. If they have to have a multi sig
for upgrade to make sure there's time locks on on those things.
Like, there's a whole bunch of things you can do to defend
yourself, and you should ask the companies that provide these
services to go do that and advertise what they are.
But yeah, like, I think that part sucks.
And the part of it is I think developers being lazy or
probably not lazy. They're just, you know, limited
runway, limited time trying to get traction.
But I think as protocols mature like I think you really need to
demand for them to kind of put in the work to to level up their
OPSEC and the security that and the rest they expose their users
to do. You think there's anything that
can be done, I don't know from your side or the OR you know
like what can be done to try to accelerate this and try to get
more open source immutable contracts or is it just a user
demand type thing that you know, it's hopefully comes with time
maturity. It'd be good if there were like
groups in the ecosystem that could kind of make a list of all
the all the best practices who's following them.
Neodime tried this with like security dot TXT and the and the
and the GitHub and that that had some some limited positive
impact. Yeah, it's probably should be
like a group ecosystem effort. It's hard to maintain those
systems and and like keep them up to date.
So it needs, I think, like input from a lot of folks.
So we we talked about economics a little bit before, but you
know, right now I feel like we've seen actually the most
vibrant sort of governance discussion that at least I'm
aware of in Solana with this SIMT 228, right?
That multi coin proposed change to the inflation, which would
make it dependent on how much is being staked.
Because I think right now, right, we've had this inflation
that kind of gradually, slowly goes down with time.
What are your thoughts first of all on on this specific
proposal? Yeah.
So I think the perfect way to have inflation is that like the
network needs to get some stakers to run boxes and pay for
the boxes running. And the only thing that the
network can really sell is more tokens.
So this is what the inflation piece.
So if you were to run an auction, you can take the top
best bids that are sufficient for you to to run a secure
network. And you don't know what those
are, you kind of guess what that number is.
But effectively you can kind of run this algorithm.
You start with 50%, you take the top best 50% bids to stake and
only those and you offer everybody the same price to run
like a Dutch auction. And if that price is below 0,
because people can bid a negative interest rate that
they're willing to burn some of their tokens for the right to
make blocks, you then increase the amount of stake that you
want. So you're targeting zero.
And if the bid is above 0, then you decrease within some limits
that at a high level people think are safe.
We've seen Ethereum run at like 20 to 30% stake without any
problems at all, like in the security side.
So I think having the lowest limit of 20 would be reasonable.
And I don't, I don't see any marginal benefit above like 80%.
So between 20 and 80%, right. This thing is bouncing around
and people are bidding those bids have actually create a
curve that looks very similar to the curve proposed in 228.
Now there's an error there because the curve in 228 is
fixed. There is this curve that you
know, Max and a bunch of other smart people thought would be
the best approximation. But that error between the
market rate in all these dynamic environments and the proposed
curve is going to show up as the network over paying for steak.
It's much, much smaller than the current setup.
So my view is that like running these auctions and the
complexity of telling users, oh, you need to pick a price and
maybe you need to pick a negative price because there's a
lot of block rewards. It's just so complicated that
there's no way to really scale it up outside of like a few
small professionals. And it's a pain in the ass to
run. Imagine you as a validator that
your stakers constantly have to bid, like every epoch no matter
how long it is right, Every 10. Months you could be the
validator was bidding. Sure, could be the validator's
bidding, but it's still like a pain and pain to run and manage
that. I think my view is like, don't
let the perfect be the enemy of the good.
This curve is a the proposed curve is a pretty good
approximation of that process, and it's much, much simpler to
implement. There's no auction.
There's no like auctions themselves have a whole bunch of
complexity that's gnarly and running them is gnarly.
So in general, I'm I'm very supportive to 228.
What I want to emphasize is that like Solana has never been a
money like the the point of soul is to disincentivize spam.
If that we have another 97% negative downturn in the market
and it's the bottom of the bear and this curve is not working
out, people will change it. That's OK like that, right?
I think people need to understand that there isn't like
this Bitcoin ask we, we don't care about our grandfather.
The sense of our grandfather don't bother us.
Like it doesn't matter what Bitcoin did in their monetary
policy. Solana can do a whole bunch of
stuff that I think Ethereum is still stuck on in this trying to
be money and and like compete with Bitcoin that the Solana
ecosystem is not. So I think this curve is an
improvement and I'm supportive and I'm, I'm encouraging people
to vote for it and I think it'll reduce emissions And emissions
are in a perfect world, emissions don't matter because
the, there is no taxes and there's no middle men that can
take a cut. But in the reality, you know,
like you look at fees from custodians and centralized
exchanges on the rewards, it's just like a huge subsidy.
And that's not even counting the the average global tax rate on
on those earnings. Maybe, maybe on this note, would
would you agree with with with the statement to say emissions
are a tax on on everyone who's not staking?
Oh yeah, the the emissions themselves, it's just money
moving around the black box. But it's not like the group of
users that are staking and not staking are different people.
You can literally be both at the same.
Time, right. Well, yeah, certainly in in
Ethereum there are some people that that have a strong feeling
there should be reasons for ESA to not be staked and just be
held in ESA and they see kind of staked ESA potentially as a
threat to the whatever money Ness of those.
So things again you don't really care about or yeah.
So would, would would you say 90 or even close to 100% Solana
staked or or be be in the form of some stake Solana or
something like that took a nice stake Solana that you wouldn't
see as an issue? If there's like UX issues around
it like that's what I would care more I think.
I I don't like when things hit the limit like it it seems like
there's a bug somewhere incentives wise like it did.
You don't need 100% stakes. Sure, yeah.
Yeah, you don't need it, but but the question is, wouldn't it be
rational or if, if if staked kind of a tokenized stake
version is just so easy to access, then why not get the
addition of the 1% essentially or whatever it is?
Well then why isn't the rate negative would be my question?
Like if it's at 100% then people should be then somebody's
overpaying, right? So to me it bugs my market like
free market thing more than like whether it's usable as money or
not. It's like it seems like the
whatever curve you picked, it has a bug in it and has caused
the IT to hit the limit point, right?
So that's what you want to avoid.
You want the parameters to be set somewhere where you're not
at 0 or 100%. But like, if in general, like I
don't, I don't think there's any threat to the muddiness of it.
And I don't really care if Seoul is used as money.
If, you know, if there's ten billion per day volume of ETH
versus everything else on Solana, it's great we hit PMF.
There's real activity. Like why?
Why would anyone be upset? Shade, Maury, I don't care.
Cool. I think you started, you started
with with saying that, yeah, some things came as expected.
Other things specifically the use cases did not came as
expected. So maybe making an outlook for
yeah the next couple of years, do you, do you think that those
finance use cases that you initially expected or what are
the blockers there and how how do you see that or are too
difficult to guess? These unexpected use cases
surfaced a lot of problems that I think are real.
I think there's like I, I think we need multiple concurrent
leaders and like the, the ability for applications to
prioritize market maker cancels before takers, like all that
stuff that needs to be implemented before Tradfi really
takes the system seriously. Because the like not even like
the the launches themselves. Like I think are like Abd
problem. Like you've seen a lot of like
really extractive launches launched by like terrible people
that should all be nude from orbit.
Like that stuff I feel like is is like business development.
You just need more robust platforms that have better
enforcement and stuff like that. But on the network layer itself,
there's a whole bunch of microstructure problems with the
way that transaction land and how MEV works that I think need
to be fixed and addressed for me to feel comfortable with like
people's 401 KS running in these things like that.
That's like, I think with meme coins and NFTS, it's like the
stakes are medium. Like the volumes are real and
the numbers are real, and there's real, real money at
stake and people really need to take it seriously.
But we're not yet like, dealing with like people's savings,
right? And I want the network to be so
robust that I can tell, like you should, you know, don't trade on
NASDAQ, trade on Solana. Like it's going to be better
pricing for people. It's more fair and more
transparent that that's the ultimate goal.
Because but like, there's a whole I was more, I was more and
I, I thought it would take four years ago, I would have said
we're ready in the year. Now I'm like, shit, this is
going to take five years to fix. Just those problems are are so
hard. Then maybe just one more push
back on the on the on the on the thesis of it needs to be faster
and it needs to be. I have an alternative thesis
that they I think there is pretty good literature that
shows that at some point, yeah, faster, faster systems do not
lead to to more efficiency, but that there are alternative
market structures, namely batch auctions or or yeah, micro batch
auctions. And to me that seems like a very
interesting approach. That has been the approach that
I have always been pushing for blockchain because if you have a
block, then in a way that is kind of you can see it as a
batch and you can try to do things like single price
clearing in this in in, in this block.
So that is in my view kind of a counter grout to this.
We just need to be faster to to to solve things.
I actually agree with you, but I think my batch auction is 100
milliseconds not not fair. Not, not, not 12 seconds, Yeah,
but I mean, I mean, I think my my counterpoint would be how
many real world events really happen in in in in 12 seconds.
So I mean a thesis theoretical argument that that if if.
Well, to be NASDAQ, I think we need like the latency to be
basically the round trip around the world and for the inclusion
latency to be shorter. So local block producers that
are concurrently within this 120 millisecond auction.
I think at that point you can reasonably argue that it's as
good as price discovery, assuming there's no like MEV
extraction. We solve that.
Throw some salt over a knock on wood.
If we solve those problems, I think it's very hard to argue
that a faster system is more than marginally better.
I think at 12 seconds you have like this information games that
are that are still harder to solve because you literally can
go to NASDAQ, take the trade and then Arby against the chain and
like that that's the opportunity that I wanna like.
Once you eliminate that for the most part, then trader that sees
that newswire and Bloomberg, they look at the chain price or
NASDAQ price, it's the same price.
Then it's as good, you know, but like I I agree with you.
You don't need to go to like below that latency for a global
system because the world's you still have like the event that
happens in Singapore still has to go travel to New York, right?
So you have still these embedded latencies that are on the order
of, you know, round trip time around the world.
Yeah. And I mean, I think the, with
regards to the whole, you know, finance coming on chain and
stuff, I, I, I, I do think there's a huge upside even with
all of this, you know, mean coin defy stuff is that, you know, in
the end, a lot of the, the infrastructure, right, the
applications, the ability to compose different protocols to
collateralize one thing and the other.
And I think there's just so much happening there and so much
progress there. And then I think once you plug
in more traditional financial assets in there, you'll just
have a very powerful system. Yeah, on the on the plus side,
your if your risk engine survives meme coins and crypto,
it can deal with like field world assets that are much more
stable. But that's the the hope, at
least. Is it fair to say for you
blockchain means financial applications or do you see other
things? It's a good question.
I think like I think this, it is like kind of melted with the
Internet. Like if you have truly globally,
global payments with no friction, every, everyone can
pay every, everywhere. That's very different than the
the the way the Internet works now, because you effectively,
because you don't have money on the Internet, you have all these
subscriptions and all this kind of friction that created the
silos and. Around ads.
Ads as a business model instead of just yeah.
So like, and that model silos everything, right?
YouTube wants its own silo, like Facebook wants its own silo and
they're very, they're fighting each other right to for market
share. You still have some of that, but
I I feel like just making it easy to pay everywhere and
everyone could start unraveling it in in a more open way.
And I like the web. I like the idea of like, you
know, minimize the cost of publishing and like let the free
world's free market figure it out, right?
Like I, I think that that's cool and, and kind of a, a really
cool, beautiful thing. I think the finance will unlock
a lot of other use cases, but I'm hoping are are disruptive to
the big kind of big tech monopolies.
But we'll see. Cool, you want to share anything
else that's like on your mind at the moment?
It's a lot of mobile's coming out soon, so stay tuned.
Oh yeah, the. The Seeker.
The phone. Yeah, Seeker.
We'll try to disrupt the duopoly.
What's your hope for the phone on like how what?
What do you see as the role of the phone?
So the goal is to get enough crypto people in the same
ecosystem to where developers have like a distribution channel
and there's like 150,000 pre-orders.
That's a reasonably sized group for a crypto app that's actually
like 50,000 daily active users is huge.
So if we have the, if we were able to capture the right kind
of audience and there's a high probability that we were because
people have to pay 500 bucks for a crypto phone.
Those are kind of the users that you want as a developer in
crypto. So they have money and they're
already crypto native. If you can build apps for them
that keep their attention and they're like super cool, you're
saving money on the 20 to 30% rake that Apple and Google
charge. You know, we talk about
disrupting finance. They charge basis points.
Apple and Google charge thousands of basis points.
What is that like 3000 basis points, right or whatever.
It's absurd rake. It's just crazy that for like
20, you know, 20 years now that they been able to get away with
it. So to me that like massive,
massive rake that they take seems like an opportunity
because if devs have can't distribute to crypto users and
there's enough high spending users in that distribution
channel, they will actually look at their like top 1% users that
are the spendiest users in iOS or Android.
I'll literally give them a the phone for free or like offer
them incentives like through air drops or whatever.
That that's the hope that we can get that flywheel work working.
If it if it works, then that's like a huge opportunity.
How how strong will be the connection between the phone and
the chain? I mean I assume there will be by
default wallet on the on the phone.
Yeah, there's there's an embedded wallet and an enclave
to run the seed phrase and there's a bunch of work to kind
of unify the experience so people don't have to switch UI.
It's more like Apple Pay that that's the goal.
I'm actually not like opposed to adding Ethereum support or
anything else in the future. It's just these are like
iteration times with hardware so long.
So it seems like we've been at it for a while, but this is just
like the second release. It's in got it to keep the team
focused and and ship, you know. And I assume technically it's
it's it's based on Android or. Yeah, it's Android.
Yeah, vanilla Android with the enclave kind of wallet signing
feature at it. Yeah, I know.
I mean, good luck with this initiative.
Certainly think the reserves, yeah, should get more
competition. If we lose because they compress
their fees, then that's the beauty of capitalism.
Then that worked, right? Like a competitor was able to
change the equilibrium in the market and that that's an
awesome outcome. Cool.
Well, thank you so much for coming on and totally it was
really great to have you and super excited about the Solana
Road map and the pace at which the ecosystem is moving and you
know all of the things that are ahead.
Thanks for having me, this was super fun.